[Bug]: a conversation carrying uploaded files should pin to its issuing account instead of being refused after rotation #4778

Client or integration

Codex CLI

Area

Authentication and account pool

Summary

#4710 is now fail-closed: an account change that would orphan an uploaded file is refused with 409 account_change_file_scope instead of forwarding a reference the new account cannot read. That stops the invalid request, but it does not restore the conversation.

The refusal is a middle step, not the final shape. The real answer is to pin a conversation that carries uploaded files to its issuing account, so the rotation that causes the problem never happens.

The cost of leaving it at refusal is specific and falls entirely on pool users. A file reference stays in the conversation's history, so once rotation has moved a conversation carrying an attachment, every later turn presents the same reference and is refused the same way. The conversation is effectively blocked. The error text says this and names the two escapes (re-upload under the serving account, or start a new conversation), but both of those ask the user to absorb a routing decision they never made and cannot see.

Pool rotation is automatic and repeated, so this is not a rare shape: any conversation with an attachment is one rotation away from being blocked.

Reproduction

1. Run a Codex pool with two or more accounts.
2. Start a conversation and attach a file, so the request carries file_id and the file is issued by account A.
3. Let routing move the conversation to account B, for example by crossing autoSwitchThreshold or through quota-driven rotation.
4. Every subsequent turn is refused with 409 account_change_file_scope, because the reference remains in history.

Suggested direction

Treat "this conversation carries uploaded files" as a binding constraint in src/codex/routing.ts affinity selection, so the issuing account is retained while such references are live. conversationCarriesUploadedFiles in src/server/responses/account-change-state.ts already answers that question from the body alone and is consulted before an alternate is resolved, so the predicate exists; what is missing is the routing layer honouring it when it chooses.

Open questions for whoever picks this up: what happens when the issuing account genuinely cannot serve (exhausted, paused, needs reauth) and the conversation carries files -- pinning and availability conflict there, and refusing is probably still correct in that corner; and whether the pin should expire with the affinity record or with the file references themselves.

The refusal from #4710 should stay regardless. Pinning reduces how often it fires; it cannot be the only guard, because an account can always become unusable.

Version

2.57.0 (dev @ 3070d64)

Operating system

macOS 15.5

Logs or error output

409 account_change_file_scope (refused before dispatch; no upstream send)

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.