[Bug]: Mid-thread model switch from a native ChatGPT model to a routed provider dies with unreadable_encrypted_agent_task; agentTaskRecovery never runs because it is gated on threadSpawn

[practical-tools-lab]

Area

Proxy and routing

What happened

Switching a live Codex Desktop thread from a native ChatGPT model (gpt-6-astra) to a routed provider model (anthropic/claude-fable-5-1) breaks the thread permanently with:

Routed V2 worker task is encrypted for the native ChatGPT backend and cannot be read by
the selected provider. Use plaintext V2 agent-message delivery or select a native ChatGPT model.

A thread that is started on the routed model never hits this. Only threads whose history already contains a backend-minted encrypted_content agent message do, and once present, every later turn replays it, so the thread can never be continued on the routed model.

The important part: agentTaskRecovery is enabled and still never runs on this path. Recovery is gated on isThreadSpawnRequest(req.headers), and a mid-thread model switch is not a thread spawn, so the request fails closed without any recovery attempt.

Reproduction (no auth, loopback only)

Two identical requests to a running proxy, differing only by the spawn header. The body is one agent_message carrying a routing header plus a structurally valid Fernet-shaped encrypted_content slot, targeting a routed provider.

# A) no spawn header  -> mid-thread model switch shape
curl -sS -X POST http://127.0.0.1:10100/v1/responses \
  -H 'Content-Type: application/json' -H 'originator: codex_cli_rs' \
  --data @probe.json

# B) same body + spawn header
curl -sS -X POST http://127.0.0.1:10100/v1/responses \
  -H 'Content-Type: application/json' -H 'originator: codex_cli_rs' \
  -H 'x-openai-subagent: collab_spawn' \
  --data @probe.json

Observed:

// A) no recovery_reason field at all -> recovery was never attempted
{"error":{"message":"Routed V2 worker task is encrypted ...","type":"invalid_request_error",
  "code":"unreadable_encrypted_agent_task"}}

// B) recovery_reason present -> recovery WAS attempted
{"error":{"message":"Routed V2 worker task is encrypted ...","type":"invalid_request_error",
  "code":"unreadable_encrypted_agent_task","recovery_reason":"unsupported_envelope"}}

The presence or absence of recovery_reason is the discriminator. unsupported_envelope in (B) only reflects the synthetic envelope used for the probe; the point is that (B) entered the recovery path and (A) did not.

Code pointers

• src/server/responses/core.ts — the direct (non-combo) recovery block is gated on threadSpawn:
  inboundWire === "responses" && threadSpawn && agentTaskRecovery && !isCanonicalOpenAiForwardProvider(route.provider) && ...
• src/server/effort-policy.ts — isThreadSpawnRequest() is true only for x-openai-subagent: collab_spawn or turn metadata subagent_kind === "thread_spawn".
• src/server/responses/core.ts — canPassThroughEncryptedV2AgentTask() requires authMode === "key" plus allowEncryptedV2AgentTasks and an openai-responses wire, so an OAuth-mode routed provider has no passthrough option either.

Expected

A thread that can be continued should be continuable. Either the recovery path should be reachable for non-spawn requests that carry an unreadable encrypted agent task, or the client should be told the switch is impossible before the thread is bricked.

Suggested direction

1. Let agentTaskRecovery run for any request whose input contains an unreadable encrypted agent envelope, not only thread-spawn requests. The admission checks in recoveryAdmission() (native ChatGPT bearer, matching chatgpt-account-id, Codex originator, no inbound API key) already bound the trust surface; threadSpawn looks like an additional narrowing rather than the security boundary.
2. Alternatively, expose the failure earlier: when a thread's history contains backend-minted ciphertext, reject or warn on the model switch itself instead of failing every subsequent turn.
3. restoreCachedEncryptedAgentTasks() is similarly gated today, so a proxy restart also loses any chance of reusing a previously recovered plaintext for that thread.

Environment

• @bitkyc08/opencodex 2.48.0
• macOS, Codex Desktop, routed provider is an OAuth-mode Anthropic-adapter provider on loopback
• agentTaskRecovery = {"enabled": true, "model": "gpt-5.6-sol", "timeoutMs": 45000, "cacheEntries": 200}, verified live via the startup warning

Related

• unreadable_encrypted_agent_task intermittently fails routed V2 subagent dispatch (strict recovery envelope; no retry during chatgpt.com 5xx windows) #3661 — spawn-path recovery failures (same error, different trigger)
• Feature: opt-in plaintext V2 collaboration rewrite for native-to-routed sub-agents #2495 — opt-in plaintext rewrite for native-to-routed sub-agents (spawn-scoped)
• V2 cross-provider sub-agent loses NEW_TASK body in encrypted_content #92, [Bug]: Fresh Astra to Grok 4.6 subagent fails with unreadable_encrypted_agent_task #3757 — cross-provider encrypted NEW_TASK loss

This report is about the non-spawn, same-thread model-switch path, which none of the above cover.

Workaround

Do not switch a native-model thread to a routed provider. Start a new thread on the routed model instead.

[lidge-jun]

@/home/box/developer/review-comments/issue-4089.md

[lidge-jun]

리뷰 · 우선순위 74 / 80

이 이슈는 Codex Desktop에서 이미 native ChatGPT로 쌓인 스레드를 routed provider(예: anthropic/claude-fable-5-1)로 바꾸는 순간 unreadable_encrypted_agent_task로 스레드가 영구히 막히는 보고입니다. 지금 dev HEAD 4b379b9ec(package 2.49.0)의 src/server/responses/core.ts를 보면 직접(non-combo) recovery 블록이 이렇게 잠겨 있습니다: inboundWire === "responses" && threadSpawn && agentTaskRecovery && !isCanonicalOpenAiForwardProvider(...) && !canPassThroughEncryptedV2AgentTask(...). threadSpawn은 src/server/effort-policy.ts의 isThreadSpawnRequest로, x-openai-subagent: collab_spawn 또는 turn metadata subagent_kind === "thread_spawn"일 때만 true입니다. 같은 스레드 모델 전환은 spawn이 아니라서 recovery가 아예 시도되지 않고, 응답에 recovery_reason도 없습니다. 제보자가 loopback curl로 A(무헤더)·B(spawn 헤더)를 나눠 보여 준 차이가 코드와 일치합니다. 스레드를 routed로 처음부터 시작하면 ciphertext가 없어 문제가 없고, 한 번 native agent_message ciphertext가 쌓이면 이후 turn마다 재현됩니다. canPassThroughEncryptedV2AgentTask는 key-auth + allowEncryptedV2AgentTasks + openai-responses라 OAuth routed에는 passthrough도 없습니다. 관련 #3661/#2495/#92/#3757은 spawn·서브에이전트 쪽이 중심이고, 이 이슈는 non-spawn mid-thread switch라 별도 트랙이 맞습니다. Combo encrypted recovery invariant(#3754)와도 맞닿지만, 게이트가 threadSpawn인 점이 핵심 버그입니다.

라인 src/server/responses/core.ts · 3506-3514 - recovery 진입 조건에 threadSpawn이 들어가 mid-thread switch를 막습니다. 제보 재현과 동일합니다.
라인 src/server/effort-policy.ts · isThreadSpawnRequest - collab_spawn / thread_spawn만 true입니다. 모델 전환 요청은 여기 안 걸립니다.
경로 restoreCachedEncryptedAgentTasks - 같은 게이트 안이라 프록시 재시작 후에도 이전 평문 캐시를 못 씁니다. 제보 suggested direction 3번과 맞습니다.
경로 제품 영향 - 스레드가 “전환 순간”에 벽돌이 되고 워크어라운드가 새 스레드뿐이라 실사용 우선순위가 높습니다.
경로 보안 - recoveryAdmission(native bearer, chatgpt-account-id, Codex originator, no inbound API key)이 이미 trust boundary라면, threadSpawn은 추가 축소로 보는 제보 해석이 타당해 보입니다. 다만 범위를 넓히면 spawn-only였던 공격면을 다시 검토해야 합니다.

메인테이너의 판단이 필요한 지점

• recovery를 “unreadable encrypted envelope가 있으면”으로 넓힐지, spawn 가드를 유지한 채 클라이언트에 조기 거절/경고만 줄지
• mid-thread native→routed switch를 제품적으로 지원할지, 명시적으로 금지하고 UX로 막을지
• Feature: opt-in plaintext V2 collaboration rewrite for native-to-routed sub-agents #2495 plaintext rewrite / #3661과 한 열차로 묶을지, 이 non-spawn 경로만 먼저 고칠지
• OAuth routed에 encrypted passthrough를 열 계획이 있는지(지금은 없음)

너의 추천
2.49 백로그에서 상단으로 두세요. 최소 수정은 recovery 게이트에서 threadSpawn 조건을 빼고 admission 가드에 맡기거나, switch 시점에 “이 스레드는 native ciphertext가 있어 routed로 못 간다”를 먼저 거절하는 쪽입니다. 보안 리뷰 없이 threadSpawn만 조용히 지우지는 말고, 재현 curl·recovery_reason 유무를 회귀 테스트로 잠근 뒤 패치 PR을 받으세요. #4086(routed replay)과는 다른 축이라 병렬로 진행해도 됩니다.

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