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:

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.
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

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).
multi_agent_v2 ON, multi_agent_mode: v2, agentTaskRecovery: {"enabled": true}.
Run a multi-agent session for 20+ minutes (parent spawns workers, sends follow-ups).
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.

리뷰 · 우선순위 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이 작성했습니다

Merge pull request #3716 from lidge-jun/codex/a-08-transition-watchdog

Merge pull request #3718 from lidge-jun/codex/a-final-closeout

fix(responses): expose bounded recovery refusal reasons [skip ci]

fix(responses): classify encrypted task recovery failures

Status after the 60-plus contributor backlog pass, which landed 12 lanes on dev. This issue is not closed by it, and the reason is specific rather than a blanket deferral.

#4364 bounded multipart encrypted task recovery and #4351 restored the opt-in plaintext V2 path. Both say in their own descriptions that they do not close this, and that remains accurate.

#4454 was also repaired in this pass and is adjacent enough to be worth naming: a mixed encrypted agent_message bypassed the routed Responses fail-closed path, and the repair now runs before dispatch. That is the egress side. Your issue is the recovery side — a strict recovery envelope with no retry during chatgpt.com 5xx windows — and nothing here changed that behavior.

Merge pull request lidge-jun#3716 from lidge-jun/codex/a-08-transitio…

Merge pull request lidge-jun#3718 from lidge-jun/codex/a-final-closeout

fix(responses): expose bounded recovery refusal reasons [skip ci]

fix(responses): classify encrypted task recovery failures

test(responses): pin bounded transient-retry cases for encrypted task…

fix(responses): opt-in bounded retry for encrypted task recovery on t…

docs(responses): document opt-in bounded recovery retries (#3661)

New matched pull request: #5825 (would resolve this issue) — fix: P0 #5369 spill growth + P1 bug batch [priority: P0]

fix(agent-task-recovery): honour Retry-After as a floor within the re…

fix: P0 #5369 spill growth + P1 bug batch (#5421, #5008, #4191, #3522, …

Fixed by #5825 (22b22ae): the new agentTaskRecovery.retries setting (0–2) enables bounded retries on transient 5xx and transport errors. The default is 0, so behaviour doesn't change unless you set it. Please reopen if it still happens after enabling it.

Navigation Menu

Repository navigation

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

Bounded failure reasons landed; recovery gaps remain open

Client or integration

Area

Summary

Reproduction

Version

Operating system

Provider and model

Logs or error output

Redacted configuration

Checks

리뷰 · 우선순위 68 / 80

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

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

Description

Bounded failure reasons landed; recovery gaps remain open

Client or integration

Area

Summary

Reproduction

Version

Operating system

Provider and model

Logs or error output

Redacted configuration

Checks

Activity

lidge-jun commented on Sep 5, 2026

리뷰 · 우선순위 68 / 80

lidge-jun commented on Sep 13, 2026

devin-ai-integration commented on Sep 25, 2026

lidge-jun commented on Sep 25, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions