Copilot gets “You don’t have access to this chat room” when commenting at the expense level (transaction thread), even though the copiloted account can comment on the parent expense report.

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number:
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @greg-schroeder
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Log in to New Expensify and act as a Copilot for a shared account
2. Open an expense report the copiloted account is the approver/owner of
3. Open an individual expense to reach its expense-level chat / transaction thread
4. Try to add a comment at the expense level.

Expected Result:

The Copilot should be able to comment on the expense-level (transaction thread) chat, since the copiloted account is the approver/owner of the parent expense report and can comment there.

Actual Result:

Commenting on the transaction thread fails with “You don’t have access to this chat room.” (jsonCode 666). Commenting on the parent expense report succeeds.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

The screenshot for the issue is in Slack thread

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @situchan

[MelvinBot]

Issue Analysis

Root Cause: This is a backend (Auth) authorization bug, not an App bug. When a Copilot comments on a transaction thread (the expense-level child chat), Auth authorizes the AddComment against the child report and rejects it with jsonCode 666, whereas the same Copilot session is authorized on the parent expense report. The Copilot's delegated access is granted/inherited on the parent report but is not resolved or inherited down to the transaction thread on the backend.

The frontend does everything correctly and identically for both cases — the only thing that differs between the working parent-report comment and the failing transaction-thread comment is the reportID being authorized, and that decision is made server-side.

Fix location: ⚠️ The fix requires changes outside the App repo, in Expensify/Auth (the AddComment report-access check / Copilot delegation for child/transaction-thread reports). This needs an internal engineer with Auth access — I couldn't read Auth from here to pinpoint the exact function. Please escalate to an internal engineer to trace the AddComment authorization path and confirm whether it (a) evaluates access with the copilot's own accountID instead of the copiloted (effective) accountID, or (b) fails to walk up to parentReportID to inherit access the way the parent-report path does.

Investigation details (frontend ruled out — high confidence)

jsonCode 666 is a backend error code, not generated by App:

• src/CONST/index.ts:2419 — EXP_ERROR: 666.

App sends a standard AddComment with the correct transaction-thread reportID and no copilot-specific params:

• Params built at src/libs/actions/Report/index.ts:964 — the payload is {reportID, reportActionID, commentReportActionID, reportComment, file, clientCreatedTime, idempotencyKey}.
• The full param type has no delegate/copilot/authToken field: src/libs/API/parameters/AddCommentOrAttachmentParams.ts. Copilot identity rides on the session auth token, attached uniformly to every request — identical for the parent report and the transaction thread.
• The composer resolves the transaction thread's own reportID correctly via getOneTransactionThreadReportID: src/pages/inbox/report/ReportActionCompose/useComposerSubmit.ts.

No copilot-specific or transaction-thread-specific client-side write gate:

• canUserPerformWriteAction / isAllowedToComment / canWriteInReport are copilot-agnostic and driven by report.permissions / writeCapability / policy role — none branch on delegate status: src/libs/ReportUtils.ts:10337. This is why the composer renders (the thread is in Onyx with WRITE permission) but the server rejects the write.

Conclusion: The only difference between the successful parent-report comment and the failing transaction-thread comment is the reportID Auth authorizes. Copilot delegation is honored on the parent but not the child report — a backend/Auth issue.

To confirm in logs (for the internal engineer): compare the requestIDs for the same copilot session's parent-report AddComment (success) vs transaction-thread AddComment (666) — the auth token should be identical and only the reportID should differ; then check which accountID Auth evaluates access with and whether it walks up to parentReportID.

Note: I could not read the Expensify/Auth source from this environment, so the exact Auth code location is inferred from the symptom pattern (parent works, child fails) rather than verified against code.

Possibly related (Copilot access): #95759 and #91978 — different symptoms, but also Copilot-access edge cases worth cross-referencing.

---

Next Steps: This needs a backend/Auth fix by an internal engineer. Reply with @MelvinBot <your feedback> to refine this analysis.

[yusufdeveloper2903]

Proposal

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

When a Copilot acts on behalf of a copiloted account and adds a comment on an expense-level chat (transaction thread), the write fails with jsonCode 666 — "You don't have access to this chat room." — even though the same Copilot can successfully comment on the parent expense report the transaction belongs to.

What is the root cause of that problem?

When a user connects as a Copilot, we swap the session onto a restrictedToken returned by CONNECT_AS_DELEGATE and tag every subsequent request with the delegate's email. This happens once, globally, and is not per-report:

• In Delegate.ts:199-221 we take response.restrictedToken and push it into the network layer with NetworkStore.setAuthToken(response?.restrictedToken ?? null), so all writes from now on authenticate as the copiloted account through that restricted token.
• In enhanceParameters.ts:82-84 we then attach finalParameters.delegate = delegate to every command, sourced from account.delegatedAccess.delegate (enhanceParameters.ts:29-37).

Because both of these are global, the AddComment we build for the transaction thread is dispatched identically to the one we build for the parent expense report — same restricted authToken, same delegate, same optimistic delegate tagging. The composer submits both through the exact same path in useComposerSubmit.ts:164-177, differing only in which report (parent vs. targetReport = the transaction thread) it targets, and the request itself is assembled the same way for any report in addActions.

So there is no App-side branch that could make the parent succeed while the child fails — the two requests are byte-for-byte the same except for reportID. The divergence is entirely in backend access resolution for the child transaction thread under a restricted (Copilot) token: the copiloted account is a first-class participant of the parent expense report chat (approver/owner), so the check passes there, but the transaction thread is a separate child report whose access is not derived from the parent expense report for a delegated session — so the write is rejected with 666.

This is confirmed by the optimistic model on our side: the transaction thread we build in buildTransactionThread seeds its participant list as [currentUserAccountID, actorAccountID] (the copiloted account + the submitter) and derives policyID/parentReportID from the money-request report. The App treats the copiloted account as a legitimate participant of the thread; the backend restricted-token check does not inherit that access from the parent, which is the gap.

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

Primary fix (root cause): The fix belongs in Auth's access resolution for transaction-thread (child) reports under a delegated/restricted token — a Copilot who can write to an expense report must inherit write access to that report's transaction threads. Concretely, the report-access check for a child transaction thread should fall back to the parent expense report's access when the requester is a delegate, mirroring how the parent chat already resolves:

canDelegateAccessReport(thread, delegate):
    if isTransactionThread(thread):
        # inherit from the money-request/expense report the thread hangs off of
        return canDelegateAccessReport(getParentReport(thread), delegate)
    return <existing participant/approver/owner check>

Why this fixes it:

• Copilot → parent expense report: already resolves today (copiloted account is a participant/approver/owner) — unchanged.
• Copilot → transaction thread: the child now inherits the parent's access, so the 666 disappears and the comment posts.
• Copilot → unrelated room: getParentReport is not an expense report the copiloted account can access, so the check still fails — no over-broadening of the restricted token.

Because the App already transmits the restricted authToken and delegate on this request exactly as it does for the parent report, no App change is required to make the write succeed — the request is already correct.

Additional fix (App-side, optional polish): the 666 surfaces to the Copilot as the generic "You don't have access to this chat room" even after the underlying access gap is closed for the common case. We could map a 666 on a child transaction-thread write to a clearer, non-terminal message so a genuinely unauthorized attempt reads sensibly, but this is cosmetic and secondary to the access fix.

Result: A Copilot who can comment on an expense report can also comment on that report's expense-level transaction threads, instead of hitting 666.

What alternative solutions did you explore? (Optional)

• App-side: force a second OpenReport on the transaction thread before allowing the write. Misdirected — we already call openReport for the thread on navigation (ReportFetchHandler.tsx:149-175) and read access clearly works (the Copilot sees the thread and its composer). The gap is write authorization under the restricted token, which a redundant fetch does not change.
• App-side: pass delegateAccountID as an explicit AddComment parameter for transaction threads. Redundant — the delegate identity is already sent on every request globally via enhanceParameters.ts:82-84, and it is sent identically for the parent report that succeeds. Adding it again cannot explain or fix a difference that the parameter is not the cause of.
• App-side: hide/disable the composer on transaction threads while acting as a Copilot. Wrong layer and a regression — it removes a legitimate capability (the copiloted account can comment there) to paper over a backend authorization gap, degrading the Copilot experience instead of restoring it.

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-14 18:23:48 UTC.

Proposal

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

While connected as a Copilot, adding a comment on an expense-level chat (the transaction thread) fails with jsonCode 666 You don't have access to this chat room, even though the copiloted account is the owner/approver of the parent expense report and commenting on that parent report succeeds.

What is the root cause of that problem?

Copilot mode swaps the whole session to the copiloted account: connect() obtains a restricted token from ConnectAsDelegate and installs it as the session/network auth token:

App/src/libs/actions/Delegate.ts

Lines 201 to 226 in 89bfa7e

	return API.makeRequestWithSideEffects(SIDE_EFFECT_REQUEST_COMMANDS.CONNECT_AS_DELEGATE, {to: email}, {optimisticData, successData, failureData})
	.then((response) => {
	if (!response?.restrictedToken || !response?.encryptedAuthToken) {
	Log.alert('[Delegate] No auth token returned while connecting as a delegate');
	Onyx.update(failureData);
	return;
	}
	if (!activePolicyID && CONFIG.IS_HYBRID_APP) {
	Log.alert('[Delegate] Unable to access activePolicyID');
	Onyx.update(failureData);
	return;
	}
	clearPreservedSearchNavigatorStates();
	const restrictedToken = response.restrictedToken;
	const policyID = activePolicyID;
	return SequentialQueue.waitForIdle()
	.then(() => {
	// Update authToken in Onyx so it persists if the further flow does not complete for any reason.
	return updateSessionAuthTokens(response?.restrictedToken, response?.encryptedAuthToken);
	})
	.then(() => {
	NetworkStore.setAuthToken(response?.restrictedToken ?? null);
	Pusher.disconnect();
	return clearOnyxForDelegateTransition();
	})

From that point on, every request is authenticated as the copiloted account, and the only thing that distinguishes it from a normal session is the restricted token itself plus the delegate field that is appended to every request:

App/src/libs/Network/enhanceParameters.ts

Lines 77 to 84 in 89bfa7e

	// Include current user's email in every request and the server logs
	finalParameters.email = parameters.email ?? getCurrentUserEmail();
	finalParameters.isFromDevEnv = Environment.isDevelopment();
	finalParameters.appversion = pkg.version;
	finalParameters.clientUpdateID = lastUpdateIDAppliedToClient;
	if (delegate) {
	finalParameters.delegate = delegate;
	}

I traced the failing request. The AddComment call the App sends for the transaction thread is identical in shape to the one for the parent expense report — the only difference is the reportID:

App/src/libs/actions/Report/index.ts

Lines 956 to 964 in 89bfa7e

	const parameters: AddCommentOrAttachmentParams = {
	reportID,
	reportActionID: resolvedReportActionID,
	commentReportActionID: file && reportCommentAction ? reportCommentAction.reportActionID : null,
	reportComment: reportCommentText,
	file,
	clientCreatedTime: file ? attachmentAction?.created : reportCommentAction?.created,
	idempotencyKey: Str.guid(),
	};

So the App hands the server exactly the same (correct) data in the working case and in the failing case. The difference is how Auth authorizes the two rooms for a restricted (Copilot) token:

• The expense report is directly accessible to the copiloted account (they are its owner/approver), so AddComment passes.
• A transaction thread is a separate chat report whose access is inherited through its parentReportID chain (thread → expense report → workspace chat). For a primary login Auth resolves that inheritance — that's why the copiloted account can comment in the very same thread when logged in directly. The Copilot/restricted-token validation only honors direct room membership, never the ancestor-derived access, so Auth answers 666.

This also explains why the issue is marked "Unable to reproduce": if the copiloted account ever commented in that specific thread before (as a primary login), they became a direct participant of the thread room, and Copilot commenting works. The failure is deterministic only for threads where the copiloted account's access is purely inherited — e.g. an approver opening a submitter's expense chat for the first time.

The same gap covers threads that don't exist yet: opening an expense whose thread was never created makes the App send OpenReport with parentReportActionID to create it — again with exactly the same parameters a primary login would send:

App/src/libs/actions/Report/index.ts

Lines 2544 to 2568 in 89bfa7e

	const childReportID = childReport?.reportID ?? parentReportAction.childReportID;
	if (!childReportID) {
	// When creating a new thread, the thread creator should never see the Join button.
	// Override their notification preference to ALWAYS regardless of who authored the parent message.
	if (newChat.participants?.[currentUserAccountID]) {
	newChat.participants[currentUserAccountID] = {
	...newChat.participants[currentUserAccountID],
	notificationPreference: CONST.REPORT.NOTIFICATION_PREFERENCE.ALWAYS,
	};
	}
	const participantLogins = PersonalDetailsUtils.getLoginsByAccountIDs(participantAccountIDs, participantsPersonalDetails);
	const participants = buildParticipantInfoFromLogins(participantLogins);
	openReport({
	reportID: newChat.reportID,
	introSelected,
	participants,
	personalDetails: participantsPersonalDetails,
	newReportObject: newChat,
	parentReportActionID: parentReportAction.reportActionID,
	isNewThread: true,
	betas,
	isSelfTourViewed,
	});

The client already sends everything correctly, so this is not fixable from the App: the Copilot access check in Auth needs to inherit thread access the way the primary-login path does.

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

This is a backend (Auth) change. In the room-access validation applied to delegate/restricted tokens (AddComment / AddAttachment / OpenReport thread creation), when the target report is a thread, resolve access by walking parentReportID up to the topmost ancestor and applying the same access rules a primary session of the copiloted account gets. The principle: a full-access Copilot must be able to comment exactly where the copiloted account can. Role restrictions for limited Copilots stay enforced at the command level and are unaffected.

No App-side change is required — the client already authenticates as the copiloted account and marks the request as delegated on every call, as shown above.

For QA, a deterministic repro of the current bug (and verification of the fix): as the copiloted account's Copilot, open an expense whose transaction thread the copiloted account has never posted in, and comment. Before the fix it returns 666; after the fix it posts.

What specific scenarios should be covered in automated tests?

• Auth: a full-access Copilot connected to an account that is the approver/owner of an expense report can AddComment on the report's transaction thread when the copiloted account is not a direct participant of that thread (inherited access only).
• Auth: the same, for a thread that does not exist yet (thread creation via OpenReport with parentReportActionID under a restricted token).
• Auth: commenting as the primary login and commenting on the parent expense report as a Copilot keep working (regression).
• Auth: limited-role Copilot command restrictions remain enforced.

What alternative solutions did you explore? (Optional)

• An App-side fix. I ruled it out by tracing both requests end to end: the parameters are identical except reportID, and the Copilot context travels via the restricted authToken and the delegate request field — neither of which the client can meaningfully change to alter Auth's access decision.
• Having the App pre-join the copiloted account to the thread (e.g. including them in emailList when opening the thread). This only affects threads the Copilot itself creates, does nothing for existing threads, and would paper over the real gap — the missing access inheritance in the restricted-token path.

[melvin-bot]

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

[shivang-goliyan]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[ijmalik]

problem:
When acting as a Copilot for an account that owns/approves an expense report, adding a comment on an individual expense's transaction thread fails with "You don't have access to this chat room." (jsonCode 666), even though commenting on the parent expense report succeeds.

root cause:
This is a backend authorization bug, not an App bug. The App sends AddComment for the transaction thread exactly as it does for the parent report — addActions() in src/libs/actions/Report/index.ts builds identical parameters (reportID, reportComment, etc.) for both, and no delegate-specific data is attached client-side; delegation is carried entirely by the restricted authToken, and the delegateAccountID used in buildOptimisticAddCommentReportAction only affects optimistic display. jsonCode 666 (CONST.JSON_CODE.EXP_ERROR) with "You don't have access to this chat room" is generated server-side: the backend's access check for a delegated session grants the copiloted account's access on the expense report itself, but does not extend/inherit that access to the report's child transaction threads (where the copiloted account is typically not a direct participant, only the submitter is).

changes:
No change in Expensify/App can fix this — the rejection happens in the backend's AddComment authorization before any client code is involved (the App merely surfaces the server's error message). The fix belongs in Auth/Web: when validating a delegated session's write access to a report, if the report is a thread (has parentReportID), the access check should fall back to the delegate's access on the parent/ancestor report — mirroring the non-delegated behavior where an approver/owner can comment on transaction threads of their report without being a direct participant. This issue should be labeled Internal and assigned to an internal engineer.

alternative:
I checked whether the App fails to create the transaction thread server-side before commenting (which could cause a 666 on a nonexistent report), but transaction threads are created with the money request itself and the thread loads fine for the Copilot — only the write is rejected, confirming a server-side permission check rather than a client-side request-construction bug.

[godzillaxbox19982014-lgtm]

Proposal

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

Copilot gets “You don’t have access to this chat room” when commenting at the expense level (transaction thread), even though the copiloted account can comment on the parent expense report.

What is the root cause of that problem?

I traced this to the path that handles report owner, expense report:

• src/pages/DynamicReportDetailsPage.tsx:480 (if): } else if ((isUserCreatedPolicyRoom && (!participants.length || !isPolicyEmployee)) || ((isDefaultRoom || isPolicyExpenseChat) && isChatThread && !isPolicyEmployee)) {
• src/pages/DynamicReportDetailsPage.tsx:278 (shouldOpenRoomMembersPage): const shouldOpenRoomMembersPage = isUserCreatedPolicyRoom || isChatThread || (isPolicyExpenseChat && isPolicyAdmin);
• src/pages/DynamicReportDetailsPage.tsx:405 (shouldShowGoToRoom): const shouldShowGoToRoom = (isChatRoom || isPolicyExpenseChat) && !isRoomCurrentlyOpen;
• src/pages/DynamicReportDetailsPage.tsx:412 (additionalRoomDetails): const additionalRoomDetails = isExpenseReportUtil(report) || isPolicyExpenseChat || isInvoiceRoom ? chatRoomSubtitle : '${translate('threads.in')} ${chatRoomSubtitle}';
• src/pages/DynamicReportDetailsPage.tsx:480 is the first concrete decision that matches report owner, expense report, and src/pages/DynamicReportDetailsPage.tsx:278 is the next matching consumer/mutation. The failing behavior is introduced at this handoff: the second path does not preserve the condition/state established by the first path for the repro case.

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

• Change the issue-matching decision at src/pages/DynamicReportDetailsPage.tsx:480 so the report owner, expense report repro state is represented before src/pages/DynamicReportDetailsPage.tsx:278 consumes it.
• Keep the patch at this first decision/consumer boundary (align optimistic/success/failure data with the selector consumed by the screen) instead of masking the downstream UI symptom.
• Keep the change inside the Reports, Expenses, IOU, Transactions surface and avoid changing payment actions, personal/deleted policies.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Add or update a regression in tests/unit/ReportUtils*.ts for the exact issue flow: Copilot gets “You don’t have access to this chat room” when commenting at the expense level (transaction thread), even though the copiloted account can comment on the parent expense report..
2. Cover the counter-case near src/pages/DynamicReportDetailsPage.tsx:480 so valid existing report owner, expense report behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep report owner, expense report consistent at the first read/write boundary shown above.

[github-actions]

⚠️ @shivang-goliyan Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[github-actions]

⚠️ @ijmalik Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.