unreadable_encrypted_agent_task intermittently fails routed V2 subagent dispatch (strict recovery envelope; no retry during chatgpt.com 5xx windows)

[Hu9956]

Bounded failure reasons landed; recovery gaps remain open

#3794 (eff908e0fb) exposes bounded recovery refusal reasons. MESSAGE support was already present. Multipart reconstruction and more precise failure attribution remain outside this delivery; an unavailable result does not prove an upstream attempt.

Verified against dev 5759d9ea2f1e7281cdc01eb9628f2e0a123fb59c. Original report by @Hu9956. The attribution record was added in #3811.

Client or integration

Codex App (ChatGPT.app bundled codex 0.153.1); same behavior verified via Codex CLI codex exec.

Area

Proxy and routing

Summary

Native ChatGPT main models dispatching V2 subagents to routed providers intermittently fail with 400 unreadable_encrypted_agent_task ("Routed V2 worker task is encrypted for the native ChatGPT backend and cannot be read by the selected provider"). Most dispatches succeed (recovery works), but two failure classes appear in long-running sessions:

1. Delayed 400 (~5 s): recovery attempted, decode round-trip to the native backend fails. These cluster immediately after 502s from the native backend on the parent session — recovery inherits the same instability and is a single attempt with no retry.
2. Instant 400 (10–21 ms): envelope not parseable, recovery never attempted. The 2.42.0 envelope contract in src/server/responses/agent-task-recovery.ts requires exactly one encrypted_content part, exactly one Fernet token, a plaintext Message Type: NEW_TASK header, and matching author/recipient. Anything else (e.g. MESSAGE-type follow-ups, token-split ciphertext) fails closed.

Expected: either these dispatches recover (like the majority do), or the error distinguishes "transient native-backend failure, retry plausible" from "unrecoverable payload shape".

Related: #3568 covers the MESSAGE-type follow-up half. This report adds field evidence plus two gaps that PR does not appear to address: (a) multi-part / token-split NEW_TASK envelopes are unrecoverable (encryptedPartCount !== 1 || ciphertextCount !== 1 → null), and (b) no resilience/retry when chatgpt.com is returning 5xx.

Reproduction

1. Configure a native ChatGPT main model (gpt-5.6-luna, gpt-6-astra) with routed subagents (opencode-go/omen-alpha, volcengine-coding-plan/glm-5.3-flash, volcengine-coding-plan/deepseek-v4-flash-ga-260731).
2. multi_agent_v2 ON, multi_agent_mode: v2, agentTaskRecovery: {"enabled": true}.
3. Run a multi-agent session for 20+ minutes (parent spawns workers, sends follow-ups).
4. Observe: most dispatches 200; intermittently 400 unreadable_encrypted_agent_task — either after ~5 s (decode attempt failed) or instantly (envelope unparseable). Instant failures repeat identically on retry of the same dispatch.

Observed frequency: ~6 400s out of ~190 requests across 3 sessions (~25 minutes).

Version

2.42.0

Operating system

macOS 26.0 (Apple Silicon)

Provider and model

Main (native): openai/gpt-5.6-luna, openai/gpt-6-astra (ChatGPT account, forward). Subagents (routed): opencode-go/omen-alpha, volcengine-coding-plan/glm-5.3-flash, volcengine-coding-plan/deepseek-v4-flash-ga-260731.

Logs or error output

# Class A: delayed 400 after native-backend 502 (recovery attempted, failed)
20:36:49  502  10105ms  openai/gpt-6-astra
20:36:54  400   5014ms  volcengine-coding-plan/deepseek-v4-flash-ga-260731
          requestId ocx-e0b1cc267c7d7d00237a9b51be4a62db

20:49:34  502  17125ms  openai/gpt-6-astra
20:49:34  400     12ms  volcengine-coding-plan/deepseek-v4-flash-ga-260731
          requestId ocx-5f0d7dc5b04c8a921909628e969b6b1e

# Class B: instant 400 (envelope not parseable)
20:41:54  400  14ms  opencode-go/omen-alpha  requestId ocx-9fa0c50024d78d36a4909b7c42c2d295
20:47:01  400  21ms  opencode-go/omen-alpha  requestId ocx-937dc1543871b4698efecddb542c39a7

Error body: {"error":{"message":"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.","type":"invalid_request_error",
"code":"unreadable_encrypted_agent_task"}}

Redacted configuration

{
  "multiAgentV2": { "enabled": true, "multiAgentMode": "v2", "keepNativeChatgptOnV1": false },
  "agentTaskRecovery": { "enabled": true },
  "providers": {
    "openai": { "adapter": "openai-responses", "authMode": "forward" },
    "opencode-go": { "adapter": "openai-chat", "authMode": "key", "apiKey": "sk-****" },
    "volcengine-coding-plan": { "adapter": "openai-chat", "authMode": "key", "apiKey": "****" }
  }
}

Checks

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

[lidge-jun]

리뷰 · 우선순위 68 / 80

설명

이 이슈는 네이티브 ChatGPT 메인 모델이 라우팅된 제공자로 V2 서브에이전트를 보낼 때, 가끔 400 unreadable_encrypted_agent_task가 나는 문제를 현장 로그로 정리한 것입니다. 대부분은 복구가 되어 200이 나오는데, 긴 세션에서 두 종류로 실패합니다. 하나는 부모 세션이 chatgpt.com에서 502를 맞은 직후, 복구를 한 번 시도하다가 약 5초 뒤에 실패하는 경우입니다. 다른 하나는 10~21ms 만에 바로 400이 나고, 같은 디스패치를 다시 보내도 똑같이 실패하는 경우입니다. 리포터는 Codex App(0.153.1)과 codex exec에서 같은 증상을 봤고, 약 190요청 중 6번 정도라고 적었습니다.

지금 dev HEAD bf58ef182(package 2.43.0)의 src/server/responses/agent-task-recovery.ts는 복구 대상을 아주 좁게만 받습니다. findEnvelope()는 Message Type: NEW_TASK 헤더 하나, encrypted_content 파트 정확히 하나, Fernet 토큰 정확히 하나, author/recipient가 헤더의 sender/task와 같을 때만 통과합니다. 조건이 하나라도 어긋나면 null을 돌려서 복구를 시작조차 하지 않습니다. 그러면 src/server/responses/core.ts 쪽이 unreadable_encrypted_agent_task로 닫습니다. 복구 엔드포인트도 https://chatgpt.com/backend-api/codex/responses 한 번뿐이고, 부모 쪽 5xx 직후에 같은 백엔드가 흔들릴 때 재시도하는 경로는 없습니다.

열린 PR #3568(Go 서브에이전트용 네이티브 MESSAGE 복구)이 이슈 본문이 가리키는 “MESSAGE 후속” 절반과 겹칩니다. 다만 이 이슈가 추가로 찍은 두 구멍은 #3568만으로 안 닫혀 보입니다. (a) 멀티파트·토큰 분할 NEW_TASK는 encryptedPartCount !== 1 || ciphertextCount !== 1에서 바로 null이고, (b) chatgpt.com 5xx 창에서의 복구 재시도가 없습니다. 버전 표기는 2.42.0인데, 지금 HEAD의 복구 계약도 같은 엄격 규칙을 유지합니다. 증상은 간헐적이지만, 멀티에이전트 V2를 켜 둔 사용자에게는 “가끔만 깨진다”가 재현·디버깅을 더 어렵게 만듭니다. 에러 문구도 “암호화라서 못 읽는다”로만 나와서, 일시 장애인지 페이로드 모양 문제인지 구분되지 않습니다.

라인 136-137 agent-task-recovery.ts encryptedPartCount !== 1 || ciphertextCount !== 1 - 파트/토큰이 둘 이상이면 복구를 아예 포기한다. 클래스 B(즉시 400)와 맞다. 합치기·재조립을 넣을지, 아니면 “모양 불일치” 전용 에러 코드를 낼지 정해야 한다.
라인 72 ROUTING_HEADER - NEW_TASK만 잡는다. MESSAGE 후속은 여기서 탈락한다. #3568이 그 절반을 다루는지 같이 확인해야 한다.
경로 RECOVERY_ENDPOINT (chatgpt.com/.../responses) - 부모 세션이 방금 502를 낸 같은 백엔드로 한 번만 간다. 클래스 A(지연 400)와 맞다. 5xx/타임아웃 때 같은 계정으로 짧은 백오프 재시도가 없다.
경로 core.ts unreadable_encrypted_agent_task - 복구 실패·미시도가 같은 코드로 묶인다. 클라이언트가 “다시 시도해도 되나”를 알 수 없다.
경로 설정 agentTaskRecovery.enabled - 켜져 있어도 계약 밖 봉투는 복구 시도 자체가 없다. 로그에 “시도함/스킵함/디코드 실패”를 나눠 남기지 않으면 현장 분류가 계속 힘들다.
관련 #3568 - 열려 있고 MESSAGE 쪽이다. 이 이슈의 (a)(b)를 그 PR에 얹을지, 후속 이슈/PR로 쪼갤지 정해야 한다.

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

• #3568에 MESSAGE + 에러 코드 분리를 먼저 넣고, 멀티파트/5xx 재시도는 후속으로 둘지
• 멀티파트 NEW_TASK를 안전하게 합칠 수 있는지, 아니면 명시적 fail-closed + 별도 코드를 유지할지
• chatgpt.com 5xx 창에서 복구 재시도 횟수·백오프·쿼터/헬스 패널티를 어떻게 둘지
• 리포터에게 2.43.0/dev HEAD 재현과 복구 시도 여부(로그)를 더 받을지

너의 추천
중복 이슈로 닫지 말고 연다. #3568을 MESSAGE/에러 구분 1차로 밀고, 이 이슈는 (a) 멀티파트·토큰 분할 계약과 (b) 5xx 복구 재시도를 명시 범위로 남긴다. 당장 “항상 재시도”로 넓히기보다, 실패 이유를 로그·에러 코드로 나눈 뒤 재시도는 같은 계정·짧은 창으로만 실험하는 편이 안전하다. #2495(plaintext V2)와 섞어 닫지 말 것.

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