[$250] [Exploratory] 92014 Agents - Error shows up when copilot edits custom instructions

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.89-5
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #90823
Email or phone of affected tester (no customers): applausetester+sdjosinjdo1@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: User Settings

Action Performed:

Precondition:

• Log in with Expensifail account.
• User A adds User B as copilot.
• User A has created an agent on Account > Agents.
• Perform the steps below as User B.

1. Go to staging.new.expensify.com
2. Go to Account.
3. Open account switcher.
4. Select User A account.
5. Go to Account > Agents.
6. Click Edit button on the agent.
7. Click Write custom instructions.
8. Edit the custom instructions and save it.

Expected Result:

No error will show up.

Actual Result:

Error shows up when copilot edits custom instructions.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7167969_1780246204512.1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7167969

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022078168444385077013
• Upwork Job ID: 2078168444385077013
• Last Price Increase: 2026-07-17

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/5112b776f69ed0de1112ef0e95ef03f868bdba431d2a67f56c873570480dba0f

[MelvinBot]

Issue Analysis

Root Cause: "Write custom instructions" edits the agent's prompt, which fires the UPDATE_AGENT_PROMPT API command with no client-side gating. When the editor is a copilot acting on the owner's account, the server rejects the write, and the App surfaces the generic agentsPage.error.updatePrompt failure message from the command's failureData. The owner editing their own agent directly works fine — the error only appears in the copilot (delegate) context.

Why it's likely server-side: The App fires the command unconditionally — there's no copilot/delegate check in the edit flow (EditPromptPage.handleSubmit → updateAgentPrompt), so the error text is purely a relay of a failed API response. Confirming why the command is rejected in the copilot context requires looking at the backend UpdateAgentPrompt command, which lives outside this repo. This needs a separate internal investigation to decide the intended behavior.

Two possible resolutions (internal decision required):

• If copilots should be able to edit an owner's agent → the fix is server-side (allow the write in the copilot/delegate context). No App change.
• If copilots should not be able to edit → the App should gate the action gracefully (e.g. a DelegateNoAccessModal, as other account settings already do) instead of firing the command and showing a generic error.

Investigation details

Repro flow (from the issue): User B is a copilot of User A → switches into User A's account → Account > Agents > Edit > Write custom instructions > Save → error.

Evidence chain:

• EditPromptPage calls updateAgentPrompt(accountID, prompt, originalPrompt) on submit — no delegate/role check. (EditPromptPage.tsx:45-46)
• updateAgentPrompt issues write(WRITE_COMMANDS.UPDATE_AGENT_PROMPT, …) and, on failure, writes promptErrors: agentsPage.error.updatePrompt — the message the copilot sees. (Agent.ts:174-200)
• The whole Agents feature is built on copilot/delegate relationships (switchToDelegator, "Copilot into account"), and per the createAgent comment a personal agent is itself "a full co-pilot of the creator." A copilot editing an owner's agent is therefore a nested copilot scenario, which is the most plausible place for a server-side authorization gap.

Alternative explanations considered: A pure client bug (e.g. wrong accountID) is unlikely — the same page works for the owner and there's no copilot-specific branch in the edit code. A generic delegate-write regression would affect all delegate writes, not just agent prompt edits.

Note on regression source: PR #90823 (linked in the report) added the agent's own Profile AI Prompt section (copilot into the agent), which is a different entry point than Account > Agents > Edit used here.

---

Next Steps for Contributor+ team:
This is likely a backend authorization issue rather than an App code fix. An internal engineer should confirm whether copilots are intended to edit an owner's agents:

• Backend fix (allow the write) — escalate internally; no App change needed.
• App gate (block copilots gracefully) — reply @MelvinBot implement this to have me add a DelegateNoAccessModal gate to the agent-edit flow.
• To refine: @MelvinBot <your feedback>

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @ahmedGaber93 (External)

[wildan-m]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a user who is acting as a copilot (delegate) of another account opens Account > Agents, edits an agent and saves the custom instructions, an error is shown. The expected behaviour is that no error appears.

What is the root cause of that problem?

All of the Agents settings screens are wrapped with the withAgentAccessDenied higher-order component. That guard only blocks the agent accounts themselves — it returns the access-denied view exclusively when isAgentEmail(sessionEmail) is true (an agent_<id>@expensify.ai address). It does nothing for a user who is currently connected as a copilot/delegate of another account.

App/src/libs/Navigation/AppNavigator/withAgentAccessDenied.tsx

Lines 17 to 43 in 187d32f

	ProtectedComponent = (props) => {
	const [sessionEmail] = useOnyx(ONYXKEYS.SESSION, {selector: sessionEmailSelector});
	const isAgent = isAgentEmail(sessionEmail);
	const isAlreadyOnRedirectTarget = Navigation.isActiveRoute(ROUTES.SETTINGS_PROFILE.route);
	const shouldRedirect = isAgent && !isAlreadyOnRedirectTarget;
	useEffect(() => {
	if (!shouldRedirect) {
	return;
	}
	Navigation.navigate(ROUTES.SETTINGS_PROFILE.getRoute());
	}, [shouldRedirect]);
	if (shouldRedirect) {
	return null;
	}
	if (isAgent) {
	return (
	<FullPageNotFoundView
	shouldShow
	titleKey="delegate.notAllowed"
	subtitleKey="delegate.noAccessMessage"
	shouldShowLink={false}
	/>
	);
	}
	return <Component {...props} />;

Because there is no delegate guard, a copilot can open the edit-prompt screen and submit. On save, EditPromptPage's submit handler calls updateAgentPrompt, which fires the UPDATE_AGENT_PROMPT write under the delegate session:

App/src/pages/settings/Agents/Fields/EditPromptPage.tsx

Lines 39 to 42 in 187d32f

	const handleSubmit = (values: FormOnyxValues<typeof ONYXKEYS.FORMS.EDIT_AGENT_PROMPT_FORM>) => {
	updateAgentPrompt(accountID, values[INPUT_IDS.PROMPT].trim(), agentPrompt?.prompt ?? '');
	Navigation.goBack();
	};

Managing another user's agents is an owner-only operation, so the request made under the delegate token is rejected. The action's failureData then writes promptErrors with the agentsPage.error.updatePrompt message, which is what surfaces as the red-brick-road error the tester sees:

App/src/libs/actions/Agent.ts

Lines 215 to 242 in 187d32f

	function updateAgentPrompt(accountID: number, prompt: string, originalPrompt: string) {
	const onyxKey = `${ONYXKEYS.COLLECTION.SHARED_NVP_AGENT_PROMPT}${accountID}`;
	const optimisticData: AnyOnyxUpdate[] = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: onyxKey,
	value: {prompt, pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE, errors: null},
	},
	];
	const successData: AnyOnyxUpdate[] = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: onyxKey,
	value: {pendingAction: null, promptErrors: null},
	},
	];
	const failureData: AnyOnyxUpdate[] = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: onyxKey,
	value: {prompt: originalPrompt, pendingAction: null, promptErrors: getMicroSecondOnyxErrorWithTranslationKey('agentsPage.error.updatePrompt')},
	},
	];
	write(WRITE_COMMANDS.UPDATE_AGENT_PROMPT, {agentAccountID: accountID, prompt}, {optimisticData, successData, failureData});
	}

In short: the agent edit entry points never check whether the current user is acting as a delegate, so the copilot is allowed to trigger a write that then fails. This is inconsistent with the rest of the app, where delegate-restricted writes are blocked up-front with the DelegateNoAccessModal instead of being attempted and failing.

What changes do you think we should make in order to solve the problem?

Guard the agent management actions against delegate access using the existing DelegateNoAccessModalProvider, exactly the way money-request, hold and payment actions already do it (read isActingAsDelegate from useDelegateNoAccessState, and showDelegateNoAccessModal from useDelegateNoAccessActions):

App/src/components/DelegateNoAccessModalProvider/index.tsx

Lines 21 to 46 in 187d32f

	const {translate} = useLocalize();
	const styles = useThemeStyles();
	const [isModalOpen, setIsModalOpen] = useState(false);
	const currentUserDetails = useCurrentUserPersonalDetails();
	const delegatorEmail = currentUserDetails?.login ?? '';
	const [account] = useOnyx(ONYXKEYS.ACCOUNT);
	const isActingAsDelegate = !!account?.delegatedAccess?.delegate;
	const isDelegateAccessRestricted = isActingAsDelegate && AccountUtils.isDelegateOnlySubmitter(account);
	const delegateNoAccessPrompt = (
	<View style={[styles.renderHTML, styles.flexRow]}>
	<RenderHTML html={translate('delegate.notAllowedMessage', delegatorEmail)} />
	</View>
	);
	const stateValue = {
	isActingAsDelegate,
	isDelegateAccessRestricted,
	};
	const showDelegateNoAccessModal = () => setIsModalOpen(true);
	const actionsValue = {
	showDelegateNoAccessModal,
	};

Concretely, when the current user is acting as a copilot the agent edit/add/delete entry points should show the no-access modal and return early instead of navigating into the edit field or firing the write:

• In EditAgentPage, gate the action handlers — handleEditPromptPress, handleEditNamePress, handleEditAvatarPress and handleDeletePress — so that when isActingAsDelegate is true they call showDelegateNoAccessModal() and return, rather than navigating to the field page or deleting.

App/src/pages/settings/Agents/EditAgentPage.tsx

Lines 44 to 70 in 187d32f

	const handleBackPress = () => Navigation.goBack();
	const handleEditAvatarPress = () => Navigation.navigate(ROUTES.SETTINGS_AGENTS_EDIT_AVATAR.getRoute(accountID));
	const handleEditNamePress = () => Navigation.navigate(ROUTES.SETTINGS_AGENTS_EDIT_NAME.getRoute(accountID));
	const handleEditPromptPress = () => Navigation.navigate(ROUTES.SETTINGS_AGENTS_EDIT_PROMPT.getRoute(accountID));
	const handleDeletePress = async () => {
	const result = await showConfirmModal({
	title: translate('editAgentPage.deleteAgentTitle'),
	prompt: translate('editAgentPage.deleteAgentMessage'),
	confirmText: translate('common.delete'),
	cancelText: translate('common.cancel'),
	danger: true,
	shouldHandleNavigationBack: false,
	});
	if (result.action !== ModalActions.CONFIRM) {
	return;
	}
	deleteAgent(accountID);
	};
	const agentLogin = personalDetails?.login ?? '';
	const isPendingAddOrDelete = agent?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD || agent?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE;
	const areActionsDisabled = isPendingAddOrDelete || accountID <= 0 || !agentLogin;
	const handleChatPress = () => {
	chatWithAgent(accountID);
	};
	const handleCopilotPress = () => {
	switchToDelegator(agentLogin);
	};

• In EditPromptPage (and the other field pages, EditNamePage / EditAgentAvatarPage), add the same guard to the submit handler as a safety net, so a save can never reach updateAgentPrompt while acting as a delegate.

App/src/pages/settings/Agents/Fields/EditPromptPage.tsx

Lines 39 to 42 in 187d32f

	const handleSubmit = (values: FormOnyxValues<typeof ONYXKEYS.FORMS.EDIT_AGENT_PROMPT_FORM>) => {
	updateAgentPrompt(accountID, values[INPUT_IDS.PROMPT].trim(), agentPrompt?.prompt ?? '');
	Navigation.goBack();
	};

• In AgentsPage, gate the "New agent" button the same way so a copilot cannot start the add flow either.

App/src/pages/settings/Agents/AgentsPage.tsx

Lines 111 to 118 in 187d32f

	const newAgentButton = (
	<Button
	success
	icon={icons.Plus}
	text={translate('agentsPage.newAgent')}
	onPress={() => Navigation.navigate(ROUTES.SETTINGS_AGENTS_ADD.getRoute())}
	/>
	);

With these guards, a copilot who taps an agent edit action sees the standard "you don't have access" modal and no write is sent, so the failing request — and therefore the error — never occurs.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/92160-guard-agent-edits-delegate?expand=1

What alternative solutions did you explore? (Optional)

Extend withAgentAccessDenied so that it also treats "acting as a delegate" as denied (in addition to the existing isAgentEmail check), redirecting copilots away from every agent screen. This keeps the gating in a single place, but it changes navigation behaviour and presents a full-page blocking view rather than the standard delegate "no access" modal that the rest of the app uses for restricted actions, so it is a less consistent user experience than guarding the individual actions.