[bug] org-sourced tokens.account_id breaks every request on Codex CLI >= 0.156.0 ("selected workspace missing from routing discovery")

[justinbuzzni]

Summary

Codex CLI 0.156.0 introduced a "workspace routing discovery" step. It treats tokens.account_id in ~/.codex/auth.json as the selected workspace and verifies it against the workspaces that discovery returns for the ChatGPT account derived from the token claims. codex-multi-auth writes the org id into that field for accounts whose accountIdSource is org, so discovery cannot find it and every request fails — regardless of which model is requested. Codex 0.154.0 is unaffected, because it did not perform this lookup.

This is not a model-specific or account-specific problem: on my machine 7 of 8 managed accounts are affected, and the only unaffected one is the single account whose stored accountId happens to equal its token's chatgpt_account_id claim.

I want to flag up front that writing the org id looks deliberate in the current design — resolveRequestAccountId is documented as "Preserves explicit org/manual selections; only token/id_token sources auto-follow token changes." So this is a semantics change on the Codex CLI side that the current design predates, not a simple coding slip. That is also why I am not sending a patch blindly: the right fix depends on how you want workspace selection expressed under the new contract (see "Possible direction" below).

Reproduction

1. Add a ChatGPT account and select an org/team workspace, so the stored account has accountIdSource: "org" and accountId: "org-…".
2. Let codex-multi-auth sync the selection into ~/.codex/auth.json (the written file contains codexMultiAuthSyncVersion and tokens.account_id = "org-…").
3. Install Codex CLI 0.156.0 or 0.157.0-alpha.10.
4. Run any request against the official binary, e.g. codex exec --skip-git-repo-check "reply with exactly: OK".

Expected Behavior

The request succeeds, as it does on Codex CLI 0.154.0 with the exact same auth.json.

Actual Behavior

warning: Falling back from WebSockets to HTTPS transport. selected workspace missing from routing discovery
ERROR: Reconnecting... 1/5
...
ERROR: selected workspace missing from routing discovery

Reproduced with the default model and with explicitly selected models; the model is irrelevant. Running the older 0.154.0 binary directly against the same auth.json succeeds immediately.

Evidence

Comparing the codex-multi-auth-written auth.json with one written by a native codex login (values redacted, shapes preserved):

	tokens.account_id	chatgpt_account_id claim in tokens.id_token	result
codex-multi-auth synced	org-XXXXXXXX… (org id)	<uuid>	fails
native codex login	<uuid>	<uuid> (same value)	works

Decoding each stored account's accessToken claims and comparing them with the stored accountId:

• 7 of 8 accounts: stored accountId is org-…, token claim chatgpt_account_id is a UUID → mismatch
• 1 of 8 accounts: accountIdSource: "token", both values identical → match, and this is the only account that works

Relevant code on main (2.16.0):

• lib/codex-cli/writer.ts:454 — nextTokens.account_id = selection.accountId.trim(); writes the stored id verbatim, org ids included.
• lib/auth/token-utils.ts:361-384 — shouldUpdateAccountIdFromToken / resolveRequestAccountId intentionally keep org-sourced ids instead of following the token claim.

What I could not verify: I wanted to run the decisive single-variable A/B (same credentials, only tokens.account_id swapped from the org id to the token's chatgpt_account_id). The native codex login I ran to recover my machine invalidated the previously active account's refresh token (token_revoked / refresh_token_invalidated), so the backed-up credentials were dead before I could run it, and the stored accounts carry no id_token to rebuild a valid auth.json from. So the causal link is inferred from the structural correlation plus the error semantics, not from a controlled experiment. If you can run that swap on a live org-selected account, it should settle it in one step.

Possible direction (for discussion, not a proposal I have validated)

Codex 0.157.0-alpha.10 ships a forced_chatgpt_workspace_id config.toml key, and its own validation message shows UUID-shaped workspace ids:

forced_chatgpt_workspace_id must be a single workspace ID string or a TOML list of strings; comma-separated strings are not supported. Use `forced_chatgpt_workspace_id = ["123e4567-e89b-42d3-a456-426614174000", …]` instead.

That suggests the new contract splits the two concerns that tokens.account_id used to carry:

• tokens.account_id → the ChatGPT account id (must match the token claim)
• workspace/org pinning → forced_chatgpt_workspace_id

If that reading is right, preserving today's behavior under new Codex versions would mean writing the claim-derived account id into auth.json and expressing the org selection through the workspace key instead. Two things I do not know and did not want to guess at:

1. whether forced_chatgpt_workspace_id accepts org-… ids or only the UUID workspace ids, and
2. whether the change needs to be conditional on the detected Codex CLI version, since 0.154.0 and earlier appear to rely on the old meaning.

Happy to prepare a PR once you indicate the direction you prefer.

Environment

• codex --version: codex-cli 0.157.0-alpha.10 (also reproduced on 0.156.0; 0.154.0 unaffected)
• codex-multi-auth: failure observed on 2.15.0; code references above are from main / 2.16.0
• codex-multi-auth status / check / report --json / doctor --json: intentionally omitted — my machine is currently on a native codex login that works, and I did not want to run commands that may re-sync auth.json and break it again. I can collect them on request in a throwaway CODEX_HOME.
• OS: macOS 26.5.1 (arm64)
• Node.js: v22.22.3

Compliance Confirmation

• I am using this project for personal development workflows.
• This report does not request policy bypasses or prohibited usage.
• I removed any secrets/tokens from this report.

[justinbuzzni]

Correction and hard evidence

I captured the actual HTTP exchange, and it changes my earlier reading of this issue in two ways. Correcting both.

The mechanism, confirmed

The routing discovery step is GET /backend-api/wham/accounts/check. Codex sends the account it intends to act as in the chatgpt-account-id header and validates it against the response. With an org-selected account:

GET https://chatgpt.com/backend-api/wham/accounts/check
  authorization: Bearer <redacted>
  chatgpt-account-id: org-XXXXXXXX          <- what codex-multi-auth persisted

<< HTTP/2.0 200 OK
{
  "account_ordering": ["<uuid>"],
  "accounts": [
    { "id": "<uuid>", "structure": "personal", "plan_type": "prolite",
      "account_user_role": "account-owner", "can_access_with_session": true, ... }
  ],
  "default_account_id": "<uuid>"
}

The call itself succeeds (200). The backend simply reports one usable account — the personal identity — and the org id is not in it. Codex finds its selected account missing from that list and fails with selected workspace missing from routing discovery. Codex 0.154.0 never made this call, which is why the same auth.json works there.

Controlled experiment (the one I could not run before)

I reproduced it in an isolated CODEX_HOME and flipped one field, nothing else:

tokens.account_id	result
org-XXXXXXXX (as written by codex-multi-auth)	❌ selected workspace missing from routing discovery
<uuid> (the token's own chatgpt_account_id)	✅ request succeeds
reverted to org-XXXXXXXX	❌ fails again

So the causal link is now established, not inferred.

Correction 1: my forced_chatgpt_workspace_id suggestion was wrong

I suggested that key as the new home for workspace pinning. It is not. Setting forced_chatgpt_workspace_id = "org-XXXXXXXX" makes codex log the account out:

Login is restricted to workspace(s) org-XXXXXXXX, but current credentials belong to <uuid>. Logging out.

It is a login restriction gate, not a workspace selector. Please disregard that part of the original report.

Correction 2: the token's organizations claim is not authorization

This is the part I think matters most for this project. The id_token for that same login does list the org:

id_token  → organizations: ["org-XXXXXXXX", "org-YYYYYYYY"],  chatgpt_account_id: "<uuid>"
access_token → organizations claim absent,  poid: "org-YYYYYYYY",  scp: [openid, profile, email, offline_access]

So getAccountIdCandidates / selectBestAccountCandidate faithfully surface an org the claims advertise — but the live wham/accounts/check answer for those same credentials authorizes only the personal identity. The claims are advertising membership, not live authorization for the CLI to act as that workspace. That gap is what produces a persisted account id that every subsequent request rejects.

On my machine 7 of 8 saved accounts sit in exactly this state (stored accountId is org-… while the token's chatgpt_account_id is a uuid); the single account where the two agree is the only one that works.

Suggested fix (implemented, PR to follow)

Ask the same question the CLI asks, before persisting. In the automatic-selection path of login only:

1. GET /backend-api/wham/accounts/check with the fresh access token.
2. If the resolved accountIdOverride is absent from accounts[], fall back to default_account_id and warn the user that the workspace is not authorized for these credentials.
3. Fail open on any error (non-200, network, unparseable body, no default offered) — keep the current behavior so an advisory check can never break a login.

Deliberately not applied to login --org (explicit user intent) or to a targeted re-authentication of a saved row (persistAccountPool's expectedAccount guard would reject a rewritten id as an identity mismatch).

This does not restore the ability to use an org workspace — that appears to need a grant the CLI's OAuth flow does not currently obtain for these accounts, which is upstream of this project. It does stop codex-multi-auth from persisting an id that is known-unusable, and tells the user why.

Environment: codex-cli 0.157.0-alpha.10 (also reproduced on 0.156.0; 0.154.0 unaffected), codex-multi-auth main/2.16.0, macOS 26.5.1 arm64, Node v22.22.3.