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

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:

Native V2 passthrough remains unchanged.
Routed V2 tasks that are already readable continue normally.
An unreadable encrypted task fails closed unless the user has explicitly enabled an eligible recovery path.
Experimental recovery must never silently weaken credential-destination, loopback, cancellation, privacy, or cache boundaries.
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.

[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

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

@webmastertorch

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

@webmastertorch

@webmastertorch Can u test v2.7.8 please

@Wibias

@Wibias spawning errors in every routers fuck oai lol

@lidge-jun

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.

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

@Wibias

@Wibias use v1 at gui everything is stable

@lidge-jun

@lidge-jun Yea, i guess for now.

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.

docs(sub-agents): state v2 native-to-routed NEW_TASK encryption limit…

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.

Periodic status check (2026-07-24): unchanged, still upstream-blocked.

The NEW_TASK body remains Fernet ciphertext that only the encrypting native backend can decrypt; no proxy-side transformation can recover the plaintext for a cross-provider child.
dev now fails fast before routed dispatch when the current task is unreadable (hardening rebuilt in PR fix(v2): harden unreadable routed agent tasks #336's branch), and the docs consistently point to V1 sub-agent mode as the reliable heterogeneous-provider surface.
Remaining work is the upstream Codex client change (retain plaintext alongside ciphertext when the child's resolved model is not served by the encrypting backend).

Keeping open for upstream tracking.

Cross-link

Related to (but not the same as) #418 / #290.

#418 is custom-parent → custom-child V2 delegation failing at the parent spawn_agent argument / collaboration-lifecycle stage (missing field message, no child-created). This issue (#92) is native → routed V2 where the child is spawned but the NEW_TASK body is Fernet ciphertext.

Same V2 surface; different failure mode. Keeping this issue focused on the upstream encrypted-content limitation.

docs(fr): repair sub-agent guide prose and document the Models toggle

feat(agents): keep ChatGPT-native models on v1 when the catalog is in v2

docs(fr): repair sub-agent guide prose and document the Models toggle

Triage hierarchy

Treat this issue as the parent tracker for the upstream encrypted V2 task transport limitation.

Child UX/recovery issue: [UX] Explain native-to-routed V2 compatibility and recovery state for preferred sub-agents #1533 for dashboard warning/recovery behavior.

#1533 is a mitigation/UX slice. It should not be treated as resolving the underlying encrypted-task protocol limitation tracked here.

feat(agents): keep ChatGPT-native models on v1 when catalog is v2 (#1728

feat(agents): treat a v1 pin as an eligible leaf subagent

Wave 0 triage note: this stays labelled upstream-tracking and is excluded from the ocx release-blocker count. It is tracked against the upstream defect, not as work blocking an OpenCodex release. No action requested here; the label and this note only make the blocker statistics honest.

Closing the local tracker. The protocol defect is upstream (openai/codex#32031, still open) and cannot be fixed from the proxy side. The mitigations this repository can offer are already on dev: opt-in routed-V2 recovery via #1540/#1556, fail-closed so a lost NEW_TASK body surfaces instead of silently degrading. Further recovery work (e.g. the #1794 operator surface) can proceed as its own feature without this tracker. Reopen if the upstream fix ships and the relay still drops the body.

docs(sub-agents): state v2 native-to-routed NEW_TASK encryption limit…

docs(devlog): triage every open bug issue and PR against dev

fix(agents): preserve recovery tool maps

feat(agents): keep ChatGPT-native models on v1 when catalog is v2 (li…

feat(agents): treat a v1 pin as an eligible leaf subagent

Navigation Menu

Repository navigation

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

Current status

Summary

Current expected behavior

User-visible mitigation

Why this stays open

Related

Cross-link

42 remaining items

Triage hierarchy

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

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

Description

Current status

Summary

Current expected behavior

User-visible mitigation

Why this stays open

Related

Activity

lidge-jun commented on Jul 11, 2026

Wibias commented on Jul 11, 2026

Wibias commented on Jul 11, 2026

lidge-jun commented on Jul 11, 2026

Wibias commented on Jul 11, 2026

Wibias commented on Jul 11, 2026

lidge-jun commented on Jul 11, 2026

Wibias commented on Jul 11, 2026

lidge-jun commented on Jul 18, 2026

lidge-jun commented on Jul 22, 2026

lidge-jun commented on Jul 23, 2026

Wibias commented on Jul 26, 2026

Cross-link

42 remaining items

Wibias commented on Aug 16, 2026

Triage hierarchy

lidge-jun commented on Aug 16, 2026

lidge-jun commented on Aug 18, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions