V2 cross-provider sub-agent loses NEW_TASK body in encrypted_content

[webmastertorch]

Current status

This remains an upstream-tracking issue, not an unfixed ordinary OpenCodex routing bug.

OpenCodex now has an experimental mitigation:

• PR fix(agents): add opt-in encrypted v2 recovery #1540 added an opt-in encrypted V2 task recovery path for eligible native Codex NEW_TASK messages before dispatch to a routed provider.
• Recovery is deliberately disabled by default and has strict credential, loopback, cache, timeout, and fail-closed boundaries.
• PR fix(agents): reroute recovered tasks through healthy fallback #1556 fixed fallback routing after a recovered task becomes readable, so a healthy routed fallback can be selected after recovery.

Those changes make some native-parent -> routed-child V2 workflows usable, but they do not change the underlying wire contract. The original task can still arrive only as backend ciphertext, and a routed provider cannot decrypt that ciphertext itself.

PR #1540 explicitly treats recovery as a compatibility path rather than a protocol fix. The upstream plaintext/task-delivery limitation therefore remains the close condition for this issue.

Summary

With multiAgentMode: "v2", a native Codex parent can select a routed child model, but the child task may be delivered only through encrypted_content. A third-party routed provider cannot read backend ciphertext and therefore cannot execute the task without an additional compatibility mechanism.

The original reproduction used:

• parent: native gpt-5.6-sol
• child: routed xai/grok-4.5
• fork_turns: "none"
• V2 collaboration mode

The child model override was applied correctly, but the NEW_TASK payload was not available as plaintext.

Current expected behavior

OpenCodex should preserve the following contract:

1. Native V2 passthrough remains unchanged.
2. Routed V2 tasks that are already readable continue normally.
3. An unreadable encrypted task fails closed unless the user has explicitly enabled an eligible recovery path.
4. Experimental recovery must never silently weaken credential-destination, loopback, cancellation, privacy, or cache boundaries.
5. Recovery failure must preserve the clear unreadable_encrypted_agent_task class rather than sending ciphertext to the routed model as if it were usable input.

User-visible mitigation

For heterogeneous native-parent -> routed-child delegation, users currently have two practical choices:

• use V1/plaintext-compatible collaboration behavior; or
• explicitly enable the experimental V2 recovery path introduced by fix(agents): add opt-in encrypted v2 recovery #1540, accepting its documented quota, latency, backend-coupling, and fidelity limitations.

The Dashboard compatibility UX is tracked separately in #1533.

Why this stays open

The experimental recovery path is not proof that the transport problem is solved. It performs a bounded compatibility recovery around an upstream ciphertext contract.

Close this issue only when the upstream Codex collaboration surface provides a supported task-delivery contract that routed children can consume directly, or when the upstream limitation otherwise ceases to apply.

Related

• [UX] Explain native-to-routed V2 compatibility and recovery state for preferred sub-agents #1533 - Dashboard warning/recovery-state UX for routed preferred sub-agents
• fix(agents): add opt-in encrypted v2 recovery #1540 - merged opt-in encrypted V2 recovery
• fix(agents): reroute recovered tasks through healthy fallback #1556 - merged routed fallback re-selection after recovery

[lidge-jun]

already issued by bug in upstream
will be patched soon upstream and here both
im keep pushing it!

[Wibias]

Shouldnt this be fixed by #94 @webmastertorch or am I confusing something here? Just woke up though, lol.

[Wibias]

@webmastertorch Can u test v2.7.8 please

[lidge-jun]

@Wibias spawning errors in every routers fuck oai lol

[Wibias]

yea just encountered something similar by using fable before and changing into gpt-sol as fable became rate-limited.. On it.. @lidge-jun lol

Edit:

Existing history produced under Claude Fable 5
↓
Switch thread to GPT-5.6 Sol
↓
Sol has a smaller context window
950,000 → 353,400
↓
Codex decides the oversized history must be compacted first
↓
Codex creates a compaction context using the previous model
anthropic/claude-fable-5
↓
Fable quota is exhausted
↓
Anthropic returns 429
↓
Pre-sampling compaction fails
↓
The actual Sol request is never sent

edit-2: welp, thats actually an codex problem itself, yikes.

[Wibias]

Spinned up an issue on codex github.. Lets see.. openai/codex#32453

[lidge-jun]

@Wibias use v1 at gui everything is stable

[Wibias]

@lidge-jun Yea, i guess for now.

[lidge-jun]

Status update after a fresh root-cause pass on current dev:

• Still reproducible. A native v2 parent spawning a routed child delivers NEW_TASK with empty plaintext + a pure Fernet encrypted_content block (rewritten: 0, parsedContent: "Message Type: NEW_TASK\nPayload:\n"). The model override applies; the task body is lost.
• Root cause is client-side, not the proxy. The Codex client encrypts the spawn message for the native backend; the proxy cannot decrypt Fernet ciphertext for a routed child. The earlier plaintext-parked-in-encrypted-slot case (closed PR fix: preserve routed sub-agent task payloads by sanitizing before parse #94's patch, landed on dev) is a different, already-handled shape — regression-pinned in tests/multi-agent-compat.test.ts.
• Docs are now truthful (dev commit b6281b7): README ×3 and the sub-agent-surface guide ×3 no longer claim cross-model v2 spawns unconditionally stick; they name this limitation and point at v1 as the reliable heterogeneous-provider surface.
• Next step: an upstream openai/codex issue asking that SpawnAgentArgs.message be retained as plaintext (or duplicated beside the ciphertext) when the child's resolved model isn't served by the encrypting backend. Draft is ready and will be filed separately.

Note for readers of the earlier comments: the compaction/429 reports mixed in here are a separate issue (upstream #32453-family), not this encryption path. Keeping this open to track the upstream fix.

[lidge-jun]

Status summary for anyone landing here: this remains reproducible and open intentionally. Root cause is on the upstream Codex CLI client side — the NEW_TASK body is sent as encrypted_content that a cross-provider child cannot decrypt, so no proxy-side transformation can recover it. The documented reliable workaround is to use V1 sub-agent mode for heterogeneous (cross-provider) subagents.

We're keeping this open to track the upstream fix.