unreadable_encrypted_agent_task in the field: MESSAGE-type follow-ups + recovery failures during chatgpt.com 5xx windows (2.42.0) #3660

Environment

• opencodex 2.42.0 (npm global, bundled Bun 1.4.0), macOS (Apple Silicon)
• Codex runtime: ChatGPT.app bundled codex 0.153.1
• multi_agent_v2 ON, multi_agent_mode: v2 (global override), keep_native_chatgpt_on_v1: off
• agentTaskRecovery: { enabled: true } (defaults otherwise)
• Setup: native ChatGPT main models (gpt-5.6-luna, gpt-6-astra) dispatching V2 subagents to routed providers (opencode-go/omen-alpha, volcengine-coding-plan/glm-5.3-flash, volcengine-coding-plan/deepseek-v4-flash-ga-260731)

What works

The majority of subagent dispatches succeed end-to-end: ~190 requests over ~25 minutes across 3 sessions, only 6 unreadable_encrypted_agent_task 400s. Fresh NEW_TASK spawns recover fine. Long-running multi-agent sessions are otherwise productive.

Failure class A — delayed 400 (~5 s), correlates with chatgpt.com 5xx windows

Recovery is attempted (the decode round-trip to the native backend runs for 5–9 s) and then fails. In the request log these cluster immediately after 502s from the native backend on the parent session, suggesting recovery inherits the same backend instability and has no retry:

20:36:49  502  10105ms  openai/gpt-6-astra                     (parent turn)
20:36:54  400   5014ms  volcengine-coding-plan/deepseek-...    (recovery attempted, failed)

20:49:34  502  17125ms  openai/gpt-6-astra
20:49:34  400     12ms  volcengine-coding-plan/deepseek-...

• requestId ocx-e0b1cc267c7d7d00237a9b51be4a62db (5014 ms)
• requestId ocx-5f0d7dc5b04c8a921909628e969b6b1e (12 ms)

Failure class B — instant 400 (10–21 ms), 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

Instant rejection means findEnvelope() returned null — recovery never attempted. Reading the 2.42.0 source (src/server/responses/agent-task-recovery.ts), the envelope contract is strict: exactly one encrypted_content part, exactly one Fernet token, a plaintext Message Type: NEW_TASK routing header, and author/recipient must match sender/task name. Anything else (token-split ciphertext, MESSAGE type, header variants) is unrecoverable and fails closed.

My instant-400s are consistent with the MESSAGE-type follow-up gap that #3568 already covers, so I'm mainly adding field evidence there. Two gaps that PR does not appear to address:

1. Multi-part / token-split NEW_TASK envelopes. If a long task description is ciphered as multiple encrypted_content parts or multiple Fernet tokens, the strict encryptedPartCount !== 1 || ciphertextCount !== 1 check makes recovery impossible. (Inferred from source; I did not capture payloads to confirm.)
2. No resilience when the native backend is unstable. Recovery is a single attempt at chatgpt.com/backend-api/codex/responses; during 5xx windows every fresh dispatch in that window fails, and the surfaced error is the same generic unreadable_encrypted_agent_task, which makes it look like a hard config problem rather than a transient upstream one.

Requests

• For fix(responses): recover native messages for Go subagents #3568: this is real-world confirmation on 2.42.0 — encrypted follow-up send_message to routed Go/Volcengine subagents fails exactly as described.
• Consider a one-shot retry (or short backoff) for the recovery decode, and/or a distinct error code/message when recovery was attempted but the native backend failed, so transient 5xx windows are distinguishable from unrecoverable payloads.
• Consider relaxing the envelope contract to concatenate multiple Fernet tokens from a single encrypted_content part (or multiple parts) before giving up.

Happy to capture payload-shape diagnostics with debug logging enabled if useful.