[CLI] MultiAgentV2 decrypt failure is persisted and permanently poisons a thread; no safe recovery

What version of Codex CLI is running?

Current runtime: codex-cli 0.149.0

The affected persisted thread was originally created by 0.149.0-alpha.4.1 and remains unrecoverable after upgrading to 0.149.0.

What subscription do you have?

ChatGPT paid subscription through a self-hosted OpenAI-compatible Responses endpoint backed by ChatGPT OAuth. The endpoint is healthy for fresh threads and minimal Responses requests.

Which model were you using?

gpt-5.6-sol

The effective catalog reports multi_agent_version: "v2" and supports_search_tool: true for both Sol and Terra.

What platform is your computer?

Linux 5.4.0-216-generic x86_64

What terminal emulator and version are you using (if applicable)?

Codex CLI over SSH. No terminal-specific behavior has been identified.

Codex doctor report

Not attached because the affected environment uses a custom provider and the report may contain environment-specific paths/configuration. Endpoint reachability and fresh-thread requests are healthy.

What issue are you seeing?

A single MultiAgentV2 encrypted function-output failure is persisted into the rollout and makes the entire thread permanently non-resumable:

stream disconnected before completion: Encrypted function output content could not be decrypted or decoded.

After the first failure, every reconnect or follow-up in the same thread replays the bad item and fails again. Restarting Codex and upgrading from the alpha runtime that created the thread to stable 0.149.0 do not recover it. Fresh threads using the same endpoint and model work normally.

At inspection time, the affected rollout had:

• multi_agent_version: "v2" in session_meta
• 25 persisted occurrences of the exact same decode error
• 371 encrypted_content key occurrences
• the first exact error persisted as a response_item whose payload type is custom_tool_call_output

The reconnect loop was still appending new records while the thread remained unusable. No raw rollout, encrypted payload, thread ID, prompts, tool output, provider URL, or credentials are attached.

This is a data-availability problem even if the initial invalid encrypted payload originates upstream: Codex durably commits an item that it cannot replay, then provides no supported way to resume from the last valid turn or preserve the visible transcript.

What steps can reproduce the bug?

The initial trigger is intermittent, but persistence after the first failure is deterministic:

1. Start a fresh gpt-5.6-sol thread whose effective runtime is MultiAgentV2.
2. Use subagents in a sufficiently long-running thread.
3. Encounter Encrypted function output content could not be decrypted or decoded while consuming or replaying an inter-agent/function output.
4. Allow the CLI reconnect attempts to complete.
5. Restart Codex, upgrade the CLI if applicable, and resume the same thread.
6. Send any follow-up. The same decode error repeats before useful work can continue.
7. Start a new thread against the same provider/model. The new thread works, isolating the failure to persisted history.

The existing affected rollout makes steps 4-6 reproducible on every attempt.

What is the expected behavior?

Codex should never permanently poison a thread because one encrypted replay item is invalid. At least one fail-safe path should exist:

• Do not commit encrypted function/inter-agent output to durable replay until the turn is known to be replayable.
• On this exact decode failure, stop the reconnect loop instead of appending the same failure repeatedly.
• Offer a backup-first recovery action that resumes from the last valid turn while preserving visible user/assistant messages and valid tool history.
• Mark only the invalid unfinished turn or replay-only item as degraded; do not make the entire thread inaccessible.
• Provide a supported codex doctor / repair-history operation with a dry run and byte-for-byte backup.
• Provide an explicit V1 runtime override that cannot be silently overridden by model-catalog metadata, so affected users do not need to freeze the entire model catalog.

Additional information

Related open reports cover individual parts of this failure, but the current behavior still reproduces on 0.149.0 and lacks an end-to-end recovery path:

• #33267: identical MultiAgentV2 encrypted function-output error
• #36662: persisted desktop thread cannot resume after the error
• #25290: persisted encrypted reasoning/compaction can make replay unrecoverable
• #17541: encrypted content can become invalid across model/provider changes
• #31097: model catalog can force V2 despite local feature configuration

The immediate workaround is to abandon the affected thread or manually rewrite private rollout JSONL. Manual rewriting is risky: blindly deleting every encrypted_content field can damage valid reasoning, compaction, or inter-agent records. A built-in structural recovery path is needed.