Repository navigation
V2 cross-provider sub-agent loses NEW_TASK body in encrypted_content #92
Description
Activity
already issued by bug in upstream
will be patched soon upstream and here both
im keep pushing it!Shouldnt this be fixed by #94 @webmastertorch or am I confusing something here? Just woke up though, lol.
@webmastertorch Can u test v2.7.8 please
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 sentedit-2: welp, thats actually an codex problem itself, yikes.
Spinned up an issue on codex github.. Lets see.. openai/codex#32453
@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_TASKwith empty plaintext + a pure Fernetencrypted_contentblock (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 (
devcommit 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.messagebe 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.
- Still reproducible. A native v2 parent spawning a routed child delivers
- added a commit that references this issue
on Jul 18, 2026 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_contentthat 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.
devnow 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_agentargument / collaboration-lifecycle stage (missing field message, no child-created). This issue (#92) is native → routed V2 where the child is spawned but theNEW_TASKbody is Fernet ciphertext.Same V2 surface; different failure mode. Keeping this issue focused on the upstream encrypted-content limitation.
42 remaining items
- added 3 commits that reference this issue
on Aug 15, 2026 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.
- added a commit that references this issue
on Aug 16, 2026 - added a commit that references this issue
on Aug 16, 2026 Wave 0 triage note: this stays labelled
upstream-trackingand 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.- added 6 commits that reference this issue
on Sep 17, 2026
Current status
This remains an upstream-tracking issue, not an unfixed ordinary OpenCodex routing bug.
OpenCodex now has an experimental mitigation:
NEW_TASKmessages before dispatch to a routed provider.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 throughencrypted_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:
gpt-5.6-solxai/grok-4.5fork_turns: "none"The child model override was applied correctly, but the
NEW_TASKpayload was not available as plaintext.Current expected behavior
OpenCodex should preserve the following contract:
unreadable_encrypted_agent_taskclass 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:
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