Codex MultiAgentV2 Encryption Regression: Impact on Auditability

A recent update to the Codex CLI (post-version 0.137.0) has introduced a regression where MultiAgentV2 sub-agent prompts are encrypted, effectively removing the human-readable audit trail from local rollout history and debug traces. While the encryption serves as a privacy hardening measure for model delivery, it prevents users and maintainers from inspecting the specific tasks delegated to sub-agents.

The Auditability Gap in MultiAgentV2

In versions of Codex including the changes from PR #26210, the MultiAgentV2 system encrypts message payloads for tools such as spawn_agent, send_message, and followup_task. This implementation marks the model-facing message parameter as encrypted, storing the payload in InterAgentCommunication.encrypted_content while leaving the InterAgentCommunication.content field empty.

This shift creates a significant visibility gap in the local development environment. When reviewing a rollout or trace after the fact, the human-readable task or message text is replaced by ciphertext. This makes it impossible to answer critical debugging questions, such as:

  • What specific task was assigned to a child agent via spawn_agent?
  • What exact message was sent to a sub-agent?
  • Why a specific child thread was created during a session.

Technical Root Cause

The regression stems from the InterAgentCommunication::new_encrypted() function, which deliberately initializes the content field as an empty string. When the system converts these communications into ResponseItem for recipient history, the to_model_input_item() method emits only the encrypted payload if encrypted_content is present.

Specifically, the current v2 message helper communication_from_tool_message constructs encrypted communication with no plaintext companion. Consequently, the record_inter_agent_communication function persists only the ciphertext in the rollout items, and the structured communication logs fallback to recording encrypted_content whenever the content field is empty.

Proposed Implementation for Dual-Content Persistence

To restore auditability without compromising the encrypted delivery path to the recipient model, a dual-content contract is proposed. This approach ensures that the recipient model receives ciphertext while the local system retains a readable copy for the user.

Proposed Technical Changes

  1. Required Plaintext Fields: Add a required, non-encrypted plaintext companion field (e.g., task_message or message_text) to the spawn_agent, send_message, and followup_task tools.
  2. Validation: Reject empty plaintext audit values at the handler boundary to ensure the audit trail is preserved.
  3. Dual Construction: Modify the InterAgentCommunication struct to be populated with both the encrypted_content (for model delivery) and the content (for the plaintext audit copy).
  4. Preservation of Model Input: Keep the to_model_input_item() behavior unchanged so that the recipient model continues to receive only the ciphertext.
  5. Audit Persistence: Persist the plaintext companion in the parent tool invocation, rollout, and structured trace edges.

Acceptance Criteria

For the fix to be considered successful, the following must be met:

  • Parent rollouts and history must display readable text for all v2 agent tools.
  • Child models must continue to receive only the encrypted delivery payload.
  • Communication logs must use plaintext audit content and never substitute ciphertext into fields intended for human readability.
  • Existing plaintext behavior for v1 communications must remain unchanged.

Community Perspectives and Analysis

Discussion among developers on Hacker News revealed concerns regarding the "black box" nature of these changes. Some users speculated that the encryption is intended to prevent the proxying of requests to train competitor models or to obfuscate the reasoning process.

"The black box is getting darker…I’m the end I think they would like to sell you a black box/appliance"

Other users clarified that this is not homomorphic encryption (inference on ciphertext), but rather the encryption of messages passed between agents before they are decrypted on the server side for inference.

Contributor @ignatremizov, who provided a prototype fix, noted that sub-agent prompts must pass through the client to allow the TUI to switch between agents, meaning the prompts are not entirely hidden from the system, but rather the persistence layer was broken. He further noted that MultiAgentV2 remains unstable and a "token burner" compared to v1.

Sources

Related