[OpenAI/Codex] K12 denial under detail.code is misclassified and cross-account thread switching returns 403

[jojodat]

Client or integration

Codex App

Provider or upstream service

OpenAI/Codex (K12)

OpenCodex version

2.24.1

Endpoint or capability

Authentication and account/thread routing

Current behaviour

The published denial classifier recognizes structured codes only at the top level or under error.code. The observed response shape is:

{"detail":{"code":"codex_workspace_access_denied","message":"..."}}

A local regression test returned denial = null before the patch. Adding an own-property check for detail.code returned denial = "workspace", and the incorrect needs-reauth state disappeared.

A fresh task bound exactly to the K12 selector completed with HTTP 200 and was routed to the K12 pool account. Switching an existing Plus-bound task to the same exact K12 selector produced four reproducible HTTP 403 responses without fallback.

Expected behaviour

K12 should continue to work in clean tasks, and workspace denials nested under own-property detail.code must be classified as workspace denials rather than credential failures.

When an existing Plus-bound thread is switched to an exact K12 selector, OpenCodex must either start clean/remove incompatible thread metadata or return a clear thread/account incompatibility. It must never mark the account needs-reauth for this case.

Minimal redacted request or reproduction

1. Reauthenticate a valid K12 account and verify the upstream plan is K12.
2. Start a fresh task explicitly bound to that K12 account and select `k12test/gpt-5.6-sol`; observe HTTP 200.
3. Start a task under Plus, then switch that existing task to the same exact K12 selector.
4. Observe reproducible HTTP 403 responses with no fallback.
5. Unit-test denial classification with `{ detail: { code: "codex_workspace_access_denied" } }`; current result is `null` instead of `workspace`.

Actual response or error

Fresh exact-K12 task: HTTP 200.

Existing Plus-bound task switched to exact K12: four reproducible HTTP 403 responses, no fallback. The nested denial envelope is:


{"detail":{"code":"codex_workspace_access_denied","message":"..."}}


OpenCodex incorrectly transitions to `needs-reauth` unless `detail.code` is handled.

Upstream documentation

No public upstream specification appears to document this private WHAM denial envelope. The concrete client requirement is established by the observed response shape, successful clean-task routing, and the reproducible cross-account/thread case.

Suggested mapping or implementation notes

Extend structured denial extraction to accept own-property detail.code, alongside the existing top-level and error.code paths. Add a regression test: an existing Plus-bound thread switched to an exact K12 selector must either shed incompatible metadata/start clean or return an explicit thread/account incompatibility, never needs-reauth.

Additional context and attachments

Follow-up to #1789. Reauthentication succeeded, credentials were valid, and the authenticated upstream check returned HTTP 200 with the K12 plan. This confirms that K12 works through OpenCodex in a clean task; the remaining failure is specific to cross-account/thread metadata.

No additional private data should be necessary. If maintainers need a diagnostic build tested, I can offer one anonymized K12 run.

Checks

• I searched existing provider and compatibility issues.
• The request and response were redacted.
• The expected behaviour is based on an upstream specification or a concrete client requirement.

[Ingwannu]

Confirmed on current dev. structuredDenialCode currently accepts an own string code only at the document root or under error; the reported own-property detail.code shape therefore falls through and a 403 is misclassified as a credential failure.

I will fix the classifier narrowly to accept only an ordinary object-valued detail with an own string code, add positive and fail-closed regressions, and verify that the routing outcome preserves the credential/account binding instead of marking it for reauthentication.

The existing-thread 403 is a separate compatibility boundary: the classifier fix can stop the false reauthentication state, but it cannot invent upstream workspace access. I will keep that part open until the exact thread metadata carried across the Plus-to-K12 switch is identified rather than guessing at a destructive thread reset.

[Ingwannu]

Implemented the verified classifier fix in #2055.

The PR accepts only exact own string codes under object-valued detail, preserves the existing fail-closed behavior for malformed or ambiguous bodies, and adds positive workspace/entitlement plus negative non-string coverage. Focused tests (166), typecheck, privacy scan, and the exact-range security diff review passed.

I am leaving this issue open for the second reported behavior: identifying which upstream thread/workspace metadata makes an existing Plus-bound thread incompatible after an exact K12 switch. #2055 intentionally does not reset or discard thread state without that evidence.

[yzxcj797]

Fixed the classification half — structuredDenialCode now performs the own-property code lookup at the top level, under error, and under detail (the envelope K12 actually sends: {"detail":{"code":"codex_workspace_access_denied",...}}). Regression tests pin the detail-nested workspace and entitlement denials, plus a detail object carrying a non-denial code still reading denial = null (fail-closed preserved).

The cross-account thread-switching half (Plus-bound task switched to an exact K12 selector → 403 without fallback) is not included: that's a thread-metadata/account-affinity design decision — whether to start clean on incompatible switch or return a clear incompatibility error — which the maintainers should weigh in on before I guess.

[lidge-jun]

Classification half is now on dev: #2055 merged as 2648ffa. detail.code workspace/entitlement denials are classified fail-closed and no longer flip accounts to needs-reauth.

Remaining half of this issue — the cross-account thread-switch 403 (Plus-bound thread switched to an exact K12 selector gets four 403s with no fallback or clear incompatibility signal) — is not addressed by #2055 and stays open here.

[jojodat]

Additional reproduction on OpenCodex 2.26.0:

Clarification: k12test is only the arbitrary local OpenCodex account namespace for the authenticated K12 account; gpt-5.6-sol is the actual model ID. It is not a custom provider or model. An account-qualified selector such as k12test/gpt-5.6-sol pins routing to that account, whereas a plain model ID uses Pool mode and may fail over to Plus.

• An existing K12-origin task remains exact-bound to k12test/gpt-5.6-sol and continues to complete with HTTP 200.
• Five recent fresh-task launches, plus one isolated control run, used a plain model in Pool mode. OpenCodex selected K12 first; K12 returned one or two HTTP 403 permission_denied responses, after which the same launch fell back to Plus and completed with HTTP 200.
• The isolated control reproduced this while the existing exact-K12 task continued succeeding concurrently.

This narrows the remaining behavior: a newly created Codex task is not necessarily “clean” at the upstream account/thread-affinity level. The evidence suggests that the new task already carries metadata compatible with Plus before OpenCodex selects K12 from the pool. K12 rejects that metadata, while the Plus fallback succeeds. A plain model masks the incompatibility through pool failover; an exact K12 selector cannot.

Please add a regression covering a newly created Codex task whose first request is pool-selected to K12. The task/thread metadata should be compatible with the selected account; otherwise OpenCodex should skip K12 for that task or return a clear account/thread incompatibility.

No further private data should be necessary. I can run one anonymized diagnostic build if needed.

[lidge-jun]

리뷰 · 우선순위 46 / 80

K12 403이 {detail:{code:"codex_workspace_access_denied"}} 모양이면 분류기가 못 읽고 needs-reauth로 떨어졌다. 새 태스크를 K12 셀렉터에 묶으면 200이고, Plus로 시작한 태스크를 같은 K12 셀렉터로 바꾸면 403이 네 번 나고 폴백이 없다. 자격 있는 계정 재로그인을 강요하는 쪽이라 46이다. 기본 설치 직후 사고는 아니고, 계정 전환/워크스페이스 거절 호환이다.

분류기 일부는 현재 dev에서 이미 넓혀져 있다. src/codex/quota-rejection.ts의 structuredDenialCode()는 최상위 code 다음에 own-property error와 detail을 본다. {detail:{code:"codex_workspace_access_denied"}}는 이제 workspace가 되어야 한다. WORKSPACE_DENIAL_CODES에 그 문자열이 있다. src/codex/routing.ts의 classifyCodexUpstreamOutcome()는 403+denial이면 credential이 아니라 workspace다. 2.24.1에서 denial = null이던 단위 테스트는 dev에서 다시 돌려야 한다.

스레드 전환 403은 분류기와 다른 층이다. Plus 태스크에 묶인 스레드 메타데이터(워크스페이스/스레드 id)를 K12 계정이 받아 거절하는 모양이다. 코드에서 “Plus 스레드를 K12로 바꿀 때 메타를 지운다”는 함수는 찾지 못했다. 패치 위치를 새로 짓지 않는다. 새 태스크가 200인 것과 맞으면, 기존 스레드를 재사용하지 말고 명확한 불일치 에러를 주는 쪽이 안전하다.

needs-reauth로 올리면 유효한 K12 자격 증명을 폐기한다. #1789 주석이 그 루프를 경고한다. 분류기가 workspace를 주면 재로그인 루프는 닫혀야 한다. 그래도 403이 폴백 없이 네 번이면, 분류 다음의 재시도/스레드 바인딩이 워크스페이스 거절을 소모성 재시도로 취급하는지를 봐야 한다.

해결방안

분류기 회귀 테스트로 {detail:{code:"codex_workspace_access_denied"}} → denial: "workspace"를 dev에서 확인한다. 이미 structuredDenialCode()가 그 경로를 보면 분류기 패치는 중복이다. 남은 건 Plus-bound 스레드를 정확 K12 셀렉터로 바꿀 때다. 호환되지 않는 스레드 메타를 지우거나, 계정 불일치를 명시하고 needs-reauth를 쓰지 않는다. 그 변환 함수 이름은 추측하지 않는다. 새 태스크 정확 바인딩 200은 유지한다. 계정 id·토큰·스레드 id는 로그에 남기지 말고 상태 코드와 detail.code만 남긴다.

이 댓글은 grok-bot이 작성했습니다

[lidge-jun]

리뷰 · 우선순위 66 / 80 · 유지

점수 정정임. 46 → 66. K12가 {"detail":{"code":"codex_workspace_access_denied"}} 로 거절하는데, 분류기가 top-level/error.code만 봐서 denial = null → needs-reauth로 감. 새 작업은 200. Plus 스레드를 K12로 바꾸면 403 네 번, 폴백 없음. 계정은 멀쩡함 (#1789 후속).

유지함. 자격 만료가 아닌데 재로그인으로 몰면 풀이 죽음. #2047(숏윈도우 쿼타 드롭)이랑 이웃. draft #2063이 detail.code 쪽.

해결방안: own-property detail.code도 workspace denial로. Plus→K12 전환은 메타 버리거나 명시 비호환. needs-reauth로 가지 말 것.

이 댓글은 grok-bot이 작성했습니다

[jojodat]

Additional evidence from OpenCodex 2.28.0:

• A fresh ephemeral Codex task started directly with the exact selector k12test/gpt-5.6-sol completed with HTTP 200 on the first attempt. The routing record shows explicit-account, the K12 account namespace, and no fallback.
• An existing task whose first successful response came from Plus was then switched to the same exact K12 selector. It produced six reproducible HTTP 403 workspace denials without fallback, while the K12 account remained usable and was not marked needs-reauth.
• A concurrently running K12-origin task continued returning HTTP 200.

This separates the cases more clearly: fresh exact-K12 routing works; the failure appears after Plus has successfully handled the task.

I also tested several possible causes independently. A standalone session_id, prompt_cache_key, x-codex-parent-thread-id, and replay of the stored Plus continuation items were each accepted by K12. None is sufficient by itself to reproduce the denial.

The strongest remaining code-level candidate is the combined forwarded affinity metadata:

• FORWARD_HEADERS includes session_id, thread-id, x-codex-parent-thread-id, x-codex-turn-metadata, x-codex-turn-state, window/installation headers, and other caller metadata.
• materializeCodexUpstreamAuth copies those headers first and, for a selected pool account, replaces only authorization and chatgpt-account-id.
• Current Codex turn metadata contains fields including session_id, thread_id, parent_thread_id, and forked_from_thread_id.

Therefore a Plus-to-K12 switch changes the credentials/account header while potentially retaining the original task's complete thread/turn affinity envelope. Header presence alone is not the problem—working and failing requests both carry turn metadata—but the retained account-bound values or their combination are a concrete target for instrumentation.

Suggested regression:

1. Let Plus successfully handle a task.
2. Switch that same task to an exact K12 selector.
3. Verify that OpenCodex either removes/rewrites incompatible account-affinity metadata before the upstream request or fails locally with a clear thread/account incompatibility.
4. A workspace denial must not be retried six times, must not trigger fallback for an exact selector, and must never mark valid credentials for reauthentication.

A diagnostic build could safely log only the presence and stable hashes of individual affinity fields before and after account substitution. No raw IDs, metadata values, credentials, or other private data are needed. I can run one anonymized K12 diagnostic test if useful.

[Ingwannu]

Thank you — the 2.28.0 result rules out the four obvious single-field explanations. I also verified the current implementation: materializeCodexUpstreamAuth() copies the complete curated FORWARD_HEADERS set first, then replaces only authorization and chatgpt-account-id for the selected account. The remaining boundary is therefore the combined affinity envelope or provenance, not the mere presence of one of the four fields you tested.

I do not want to “fix” this by deleting all turn metadata. That would be destructive, could break valid continuation/subagent behavior, and the current evidence does not justify it.

I am taking you up on the anonymized diagnostic run. The diagnostic must be opt-in and observational only:

• no raw authorization, account IDs, thread/session IDs, turn metadata, request bodies, or continuation items;
• a fresh in-memory random HMAC key per OCX process, so values can be compared within one run but cannot be correlated across restarts or dictionary-reversed from a durable unsalted hash;
• presence plus keyed digests for each forwarded affinity header before and after account substitution;
• bounded top-level key presence/digests for JSON turn metadata, with malformed/oversized values reported only as a category;
• the selected route/account mode and denial class, but no account identity;
• no header stripping, replay, fallback, account switching, or automatic thread reset.

The useful capture is one Plus-success turn followed by the failing exact-K12 turn in the same OCX process. That will tell us which affinity values remain bound across the credential substitution without exposing their contents. I am keeping this open and will link the diagnostic change here; the eventual production fix will be limited to the field combination the capture actually proves.