Remote Control turn from account B silently executes against account A usage

What version of the Codex App are you using (From “About Codex” dialog)?

26.810.52044 (build 6662); bundled codex-cli 0.148.0-alpha.9

What subscription do you have?

Unknown. This reproduction used account A with exhausted Codex usage and account B with remaining usage.

What platform is your computer?

Controller: Darwin 24.6.0 arm64 arm

Remote host: Apple-silicon Mac mini, macOS 26.5.2

What issue are you seeing?

A user signed into account B on the controlling Mac can submit a new message to an existing Remote Control task that was created under account A on the remote host. The request reaches the remote task, but the sampling request executes with the remote host task's existing account A authentication and fails against account A's usage limit.

The controller gives no indication that sending from account B will execute against account A's quota.

Sanitized remote-host log sequence from one reproduction:

13:31:51.190 session handler accepted UserInput for the existing remote thread
13:31:51.550 run_sampling_request model=gpt-5.6-sol auth_mode=Chatgpt
13:31:51.844 Turn error: You've hit your usage limit

The persisted task transcript records the user message and marks the turn complete roughly 300 ms later, with no assistant response or tool call. A later thread/resume also logged that configuration and developer-instruction overrides were ignored because the thread was already loaded.

Account B had remaining usage at the time; account A did not.

What steps can reproduce the bug?

1. Sign into account A on a remote Mac host and start a Codex task.
2. Exhaust account A's Codex usage while leaving the task and Remote Control enrollment intact.
3. On a separate controlling Mac, sign out of account A and sign into account B, which has remaining usage.
4. Open the historical remote task and submit a new message.
5. Observe that the remote host accepts the message.
6. Inspect the remote host log and observe that the turn uses the loaded thread's account A authentication and fails on account A's usage limit.

What is the expected behavior?

Desktop should make the execution identity explicit and consistent. Safe options include:

• rebind the new turn to the controller's active account B after explicit confirmation;
• keep the task bound to account A but block account B from sending and explain why; or
• expose the bound account/usage state before submission.

It should not accept a submission from account B while silently executing it against account A's quota.

Additional information

Related reports include #32173 (active threads retain account A after switching to B), #29904 (remote and controller usage state disagreement), and #8310 (resume behavior after a usage limit). This report adds a concrete Remote Control, cross-account reproduction where the controller and execution host are different Macs.

The report intentionally omits account IDs, request IDs, hostnames, environment IDs, cookies, and task contents.

Reproduce the cross-account Remote Control flow using the session handler, run_sampling_request, and thread/resume events described in the report. Trace how the controller identity and loaded remote thread authentication are selected, then define and test behavior that makes the execution account explicit or blocks mismatched submissions without silently using the remote account's quota.