OpenAI encrypted the instructions passed from parent agents to sub-agents in Codex's MultiAgentV2. This change was merged into the official repository on June 5, 2026, and included in Codex CLI 0.138.0, released on June 8. The target is not the prompt a user first types in, nor all of Codex's internal instructions, but rather the message a parent sends when spawning a sub-agent and assigning it additional work. The sub-agent still receives the instruction, but the plaintext of that instruction no longer appears in the history left on the user's machine.
The dispute extends beyond whether to adopt encryption to the question of how much can be audited. Codex reads code, executes commands, and rewrites files. When something goes wrong, if there's no way to check what a sub-agent was actually told to do, it becomes difficult to isolate whether the cause lay in the parent's delegation, the sub-agent's interpretation, or the execution environment itself. This creates a collision between OpenAI's stated pillar of safe operation—auditing to explain "why a given behavior occurred"—and this new delivery path.
Three Delegation Messages Are Encrypted
What changed is the message argument in MultiAgentV2's spawn_agent, send_message, and followup_task. spawn_agent launches a sub-agent and hands it its first task. The other two are used to send messages or additional work to a sub-agent that is already running or waiting.
When the parent model calls a tool, OpenAI's Responses encrypts the message. What the locally running Codex receives is ciphertext, and it carries that same ciphertext in the request to the sub-agent as agent_message. Responses decrypts it internally at the point of handing it to the receiving model. In other words, the instruction generated by the parent model remains ciphertext while passing through the local Codex, and is decrypted only just before reaching the receiving model.
The storage format changed under the same logic. In InterAgentCommunication, which represents inter-agent communication, the plaintext content field is left as an empty string, and the ciphertext is placed in encrypted_content. According to the official changelog, this format is stored in history and rollouts, and persists across compaction. The telemetry and app-server schemas also handle ciphertext. No plaintext extractable from tool arguments remains even in the parent's context.
Meanwhile, the completion notifications and status notifications returned by sub-agents are generated by Codex itself, so they remain plaintext as before. The MultiAgentV1 communication path is also unchanged. What was encrypted is the delegation content in MultiAgentV2—not all inter-agent exchanges have become invisible.
Reduced Plaintext, Lost Traceability
This design has the effect of reducing the plaintext stored locally. Delegation content can include descriptions of unreleased code, details of failures, and filenames of files under investigation. Even if a rollout is backed up or shared for debugging purposes, the instruction content becomes harder to read directly from the ciphertext.
However, OpenAI has not disclosed the purpose of this encryption. The "Why" section of the PR explains that plaintext previously flowed through ordinary tool arguments and inter-agent context, and describes the new ciphertext flow, but does not indicate who it is protecting against or what attack it anticipates. The encryption method, who manages the keys, and the retention period are also undisclosed. Since Responses decrypts internally, this cannot be called end-to-end encryption that even OpenAI itself cannot read.
What is lost instead is the user's ability to trace root causes. Even if the sub-agent's output and execution results remain, without the delegation text that served as the input, it becomes impossible to later verify whether "the parent expanded the scope too much" or "the sub-agent dropped a condition." Reproduction tests also become impossible, since the same instruction cannot be re-supplied. The more sub-agents that work on the same repository in parallel, the heavier this gap becomes.
In its own Codex operational policy published on May 8, OpenAI stated that while conventional security logs show "what happened," they struggle to explain the intent of the user or the agent. The company says it will fill this gap with "agent-facing telemetry" that includes user prompts, approval decisions, and tool execution results. Yet in MultiAgentV2, the delegation text—the direct reason a sub-agent acted—becomes ciphertext in local history and traces. Whether the enterprise-facing Compliance Platform retains this plaintext is also unclear from public materials.
Reaching the Product Path via 0.138.0; Sol and Terra Use V2
The encryption change was merged on June 5, 2026, and included in the changelog of Codex CLI 0.138.0, released June 8. Since the preceding 0.137.0 was released on June 4, encryption first entered a stable release with 0.138.0. On June 6, an OpenAI representative responded to a related bug report by stating that MultiAgentV2 was under development, not recommended for use, and that bug reports were not being accepted at that time.
However, looking at the official model catalog bundled with 0.144.4, released July 14, GPT-5.6-Sol and GPT-5.6-Terra are specified with multi_agent_version: v2. GPT-5.6-Luna uses V1. A configuration that enters V2 as a result of model selection is included in the distributed release—this is not limited to cases where users manually enable an experimental flag.
This distinction means that, even within the same Codex, what can be audited may differ depending on the model path. Under V1, delegation text remains as plaintext, while under V2 it becomes ciphertext. When comparing agent performance and speed, users need to check not only the quality of model output but also whether they can trace back to the input in the event of failure.
A Proposal to Separate Audit Copies, and Unreleased Additional Changes
Issue #28058, concerning auditability, was opened on June 13 and remained unresolved as of July 15. The proposal does not seek to revoke encryption. It keeps the message passed to the receiving model as ciphertext, while storing a separate plaintext field for auditing purposes in the parent's history and traces. This is a design that separates the delivery channel from the verification channel.
Under this proposal, the sub-agent model would continue to receive instructions via the encrypted channel as before, while users could later read what had been delegated. However, if plaintext remains locally, this rolls back part of the reduction in information leakage that encryption achieved. Implementing this would require defining the conditions under which audit copies are enabled, the retention period, and how much sensitive information should be masked.
Furthermore, on July 14, OpenAI merged PR #33030 into the main branch, which removes the latest task content from the output of list_agents, returning only agent names and statuses. No reason was given for this change. Since this PR was merged about five hours after the release of 0.144.4, it is not included in that version. Still, if it enters a future release, the path for checking delegation content from the list of running agents will also disappear.
To settle the question of whether encryption is justified, OpenAI needs to clarify what threats it anticipates and who is capable of decryption. Beyond that, the specification should address whether a local audit copy can be selected, and whether a verifiable record survives across resumption and history compaction. The next signal to watch is OpenAI's official response to Issue #28058, and whether a change implementing a plaintext audit copy makes it into a release.