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

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

• #26210 introduced encrypted Multi-agent V2 message payloads.
• #25458 shows the earlier plaintext task-envelope behavior. That issue concerns task delivery and role classification, not the loss of operator observability.
• #21753 tracks general hook parity, but this issue is broader than hooks.
• #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.