Multi-agent V2 regression: subagent instructions are no longer observable

[hoganfan]

Codex version

codex-cli 0.144.1

Variant

Codex CLI / TUI with Multi-agent V2

Platform

macOS 26.5.2, arm64

Summary

Multi-agent V2 no longer provides the operator with any way to inspect the exact instructions sent from a root agent to a subagent.

This is an observability regression introduced by the encrypted Multi-agent V2 message path in #26210.

The security goal of keeping agent instructions out of plaintext rollout history is understandable. However, encryption was introduced without an authorized operator-facing replacement for viewing or auditing those instructions.

As a result, users can observe a subagent's output, but cannot observe the input that caused it.

This issue is not primarily a request for more hooks. The lack of hook coverage only confirms that there is currently no alternative way to recover the missing observability.

Current behavior

With Multi-agent V2 enabled, the root agent can use:

• spawn_agent
• send_message
• followup_task

The recipient subagent receives and acts on the message, but the operator cannot inspect the exact content afterward:

1. The root rollout stores the message tool argument as ciphertext such as gAAAA....
2. The subagent rollout stores the received task or follow-up as encrypted_content.
3. The subagent UI shows lifecycle and status information, but not the exact dispatched instruction.
4. Setting hide_spawn_agent_metadata = false does not restore the message content.
5. Follow-up messages have the same problem, so the operator also cannot determine whether the task changed during execution.

The result is an incomplete execution record:

observable subagent result
        ↑
missing task and message history
        ↑
observable spawn/status metadata

Why this is a serious problem

When a subagent produces an incorrect or unexpected result, it is impossible to determine whether:

• the root agent sent incorrect instructions;
• the root agent omitted an important constraint;
• a later message changed the assignment;
• the subagent misunderstood correct instructions; or
• the subagent simply failed to follow them.

The exact dispatched text is execution input and must be part of the observable causal chain.

Asking the root agent to summarize or log its own messages is not a reliable workaround. AI-generated records may be omitted, paraphrased, or inaccurate. An audit record must be produced mechanically by the runtime.

This affects:

• debugging multi-agent failures;
• evaluating subagent quality;
• auditing autonomous workflows;
• compliance and incident analysis;
• comparing prompts against results.

Minimal reproduction

Enable Multi-agent V2:

[features.multi_agent_v2]
enabled = true
hide_spawn_agent_metadata = false

Start a root session and ask it to spawn a no-context child with a distinctive instruction, for example:

SUBAGENT_AUDIT_SENTINEL_12345.
Reply exactly: DONE.

Then send a distinctive follow-up:

FOLLOWUP_AUDIT_SENTINEL_67890.

After the child completes:

1. Inspect the root session UI and rollout.
2. Inspect the child session UI and rollout.
3. Try to reconstruct the exact initial task and follow-up message.

Observed result:

• the child receives the messages;
• the root rollout contains encrypted tool arguments;
• the child rollout contains encrypted_content;
• neither UI provides the exact message history;
• there is no supported audit surface from which the messages can be reconstructed.

Hooks do not currently fill the gap

Hooks are relevant only as a possible integration mechanism, not as the core issue.

Currently:

• PreToolUse does not cover built-in collaboration tools;
• SubagentStart exposes identifiers and type metadata, but not the task;
• UserPromptSubmit does not fire for inter-agent messages;
• reading the transcript from another lifecycle hook only returns ciphertext.

Therefore, users cannot restore observability themselves through existing hooks.

Expected behavior

Multi-agent V2 should preserve an authorized, deterministic way for the operator to inspect the exact communication history between agents.

At minimum, the observable record should include:

• the exact initial subagent instruction;
• every subsequent message or follow-up;
• sender and recipient;
• operation type;
• timestamp;
• parent and child thread identifiers.

Possible product surfaces include:

1. A message-history view in the TUI/Desktop subagent UI.
2. An authorized app-server audit event or export.
3. An opt-in runtime audit stream.
4. A dedicated hook carrying the exact dispatch content.

Hooks are only one possible implementation. The product-level requirement is that an authorized operator must be able to reconstruct the exact input/output causal chain.

The rollout files may remain encrypted by default. This request does not require restoring unconditional plaintext transcript storage. If necessary, plaintext audit access could be explicit, local-only, access-controlled, or opt-in.

Regression context

PR #26210 intentionally changed Multi-agent V2 so that:

• spawn_agent, send_message, and followup_task message parameters are encrypted;
• rollout/history stores ciphertext;
• the recipient model decrypts the message internally;
• Multi-agent V1 remains unchanged.

That change solved a confidentiality problem but removed the previous operator-visible task record without providing a replacement.

Related work

• Encrypt multi-agent v2 message payloads #26210 introduced encrypted Multi-agent V2 message payloads.
• MultiAgentV2 spawn_agent with fork_turns none delivers task as assistant/commentary mailbox envelope #25458 shows the earlier plaintext task-envelope behavior. That issue concerns task delivery and role classification, not the loss of operator observability.
• Full Claude Code Hook Parity (29+) #21753 tracks general hook parity, but this issue is broader than hooks.
• MultiAgentV2 encrypted spawn_agent schema returns 400: model not configured for encrypted tool use #26753 concerns encrypted-tool schema compatibility errors, not auditability.

Security note

Please do not interpret this request as requiring plaintext agent messages in every rollout by default.

The requirement is narrower:

An authorized user who can run and inspect the parent session must have some supported way to inspect the exact instructions sent to its subagents.

Encryption at rest and operator observability should not be mutually exclusive.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Subagent inspector does not show the task delegated by the parent agent #32270

Powered by Codex Action

[safal207]

The duplicate chain appears related, but I think this issue captures a broader runtime-level contract than #32270 / #32125.

Those issues primarily describe missing information in the Codex App subagent pane. A UI fix could satisfy them while the underlying Multi-agent V2 execution record remains incomplete in CLI/TUI, rollout storage, app-server integrations, and audit exports.

The distinction I would preserve is:

streaming observability
!= lifecycle interception
!= inter-agent causal audit

codex app-server streaming deltas can support live rendering of agent output, and hooks can support lifecycle observation or enforcement. Neither solves this regression unless the runtime also exposes the exact mechanically dispatched parent-to-subagent input through an authorized surface.

A minimal runtime-level acceptance contract could be:

1. Every spawn_agent, send_message, and followup_task operation produces a mechanically generated dispatch record.
2. The record binds a unique dispatch ID to sender thread, recipient thread, operation type, sequence, timestamp, parent dispatch, and exact content or a protected content reference plus digest.
3. An authorized operator can recover the exact initial instruction and every follow-up without asking the model to summarize its own messages.
4. Default rollout/transcript storage may remain encrypted or redacted.
5. Subagent results remain causally linked to the dispatch sequence that was effective when the result was produced.
6. A follow-up cannot silently replace or mutate the original assignment without creating another auditable dispatch record.
7. UI, app-server notifications, hooks, and export files are possible delivery surfaces; they should not define the underlying audit contract.

The core invariant is:

confidentiality at rest
!= authorized operator observability
!= causal audit completeness

A deterministic regression fixture could use one initial sentinel instruction, one follow-up sentinel, and one result, then fail when:

• only a model-generated paraphrase is recoverable;
• the exact dispatch content is unavailable to the authorized operator;
• sender/recipient or parent linkage is missing;
• follow-up ordering is ambiguous;
• the UI displays content but no supported machine-readable audit/export surface exists.

This would preserve the security objective of encrypted rollout storage while restoring the causal chain needed for debugging, evaluation, and incident analysis.

[safal207]

Concrete follow-up: I turned the acceptance contract above into a small vendor-neutral conformance artifact in safal207/LS#907.

It includes:

• a Draft 2020-12 JSON Schema;
• one canonical encrypted spawn_agent → followup_task → completed-result chain;
• exact-content digests and authorized-view semantics;
• complete sender / recipient / ordering / parent-dispatch bindings;
• six deterministic rejection vectors for missing exact content, UI-only observability, broken parent linkage, ambiguous ordering, incomplete result binding, and content/digest drift;
• a dependency-free validator wired into CI.

The dedicated Operational continuity fixtures workflow passes, including the new Validate inter-agent dispatch audit v0.1 step.

PR: safal207/LS#907

The artifact does not prescribe a Codex implementation or require plaintext rollout storage. It only makes the external contract testable across whichever authorized surface is chosen: app-server, hooks, or an audit export.

[hoganfan]

I found a second, separate Multi-agent V2 regression while testing the behavior discussed here: a root session resumed in a new CLI process cannot resume or send a follow-up to a subagent created by the previous process.

A cross-process control test confirmed that Multi-agent V1 supported this through resume_agent(child_id) followed by send_input(child_id). In V2, the root history resumes, but the live agent tree does not; followup_task cannot resolve the historical child by UUID or canonical task path, and V2 exposes no resume_agent equivalent.

I filed the independently actionable resumption issue as #33002. It is related to this issue because both are V2 regressions, but the acceptance criteria differ: this issue is about exact inter-agent message observability, while the new issue is about persistent subagent continuity across root-session resume.

[embedding-shapes]

I think this issue is a duplicate of #28058, seems more or less the same right?