OpenAI’s Codex CLI now encrypts the task instructions passed from a parent agent to its subagents under MultiAgentV2, leaving local session history, rollout records, and telemetry traces unable to show administrators what was actually delegated. For Windows developers running Codex against repositories on local machines, WSL, or managed enterprise endpoints, that means a failed or surprising agent action can be visible while the instruction that triggered it is not.
The change is implemented in Codex pull request #26210, merged June 5, and has become materially important with GPT-5.6’s multi-agent rollout. As Tech Times first detailed and The Register independently reported, the impact is most acute for users selecting GPT-5.6 Sol or GPT-5.6 Terra, whose multi-agent behavior uses the newer orchestration path.
OpenAI’s own GPT-5.6 announcement describes multi-agent execution as a beta capability that can run concurrent subagents and consolidate their results. That can be valuable for lengthy code reviews, migrations, debugging sessions, and parallel test work. But the delegation layer now introduces an observability break precisely where an IT team would normally begin its post-incident review.

Developer monitors show an AI agent network, code, encrypted paths, telemetry, and reduced incident visibility.The local record shows a handoff, not the task​

MultiAgentV2 covers three principal handoff operations: spawn_agent, which creates a subagent; send_message, which instructs an existing one; and followup_task, which gives additional work to an agent waiting for it.
Before the change, the parent agent’s instruction could be retained as readable text in Codex history. Under the encrypted path, the Responses API encrypts the message before the locally running Codex client receives it. Codex then stores the encrypted value in InterAgentCommunication.encrypted_content while leaving the normal content field empty.
The merged code is unusually clear about the intended data flow. Codex forwards the ciphertext in an agent_message item, and the Responses API decrypts it internally for the recipient model. This is not end-to-end encryption in the conventional sense: OpenAI’s service can still decrypt the instruction. The party excluded from reading it is the developer or administrator examining local artifacts.
That distinction matters. A security team can still see user prompts, tool approvals, shell activity, file changes, status updates, and a subagent’s final output. What it may not be able to inspect is the parent agent’s exact instruction: the statement of intent that explains why the child agent was launched and what it was meant to change.
For a Windows workstation running Codex through PowerShell, Windows Terminal, VS Code, or WSL Ubuntu, the OS is not the cause of the issue. GitHub issue #28058 describes the behavior as platform-independent. But Windows administrators will recognize the operational problem: an endpoint log says a process modified a file or executed a command, yet the workflow’s internal job ticket is unreadable.

Debugging becomes inference rather than reconstruction​

The practical failure mode is easy to picture. A parent agent asks a subagent to investigate a failing build, refactor a service, or remediate a vulnerability. The subagent changes the wrong configuration file, executes an overly broad cleanup command, or stops halfway through because it misunderstood the assignment.
The normal investigation is linear:
  1. Read the original request.
  2. Review the parent agent’s delegation.
  3. Compare that instruction with the subagent’s tool calls and output.
  4. Determine whether the failure came from planning, execution, permissions, repository state, or an ambiguous prompt.
With readable delegation removed, step two becomes guesswork. A team can inspect the effects, but cannot necessarily determine whether the parent agent gave poor instructions, whether the child agent ignored clear instructions, or whether context was lost somewhere in between.
That also weakens reproducibility. A local history file containing the original internal task would let an engineer rerun the same scenario after changing a sandbox rule, model setting, or repository state. Ciphertext forces the engineer to reconstruct the task from downstream behavior. For production pipelines, that is a substantially weaker evidence trail.
GitHub issue #28058, opened by Zolvat CTO Ignat Remizov, asks OpenAI for a narrower fix than removing encrypted delivery. The proposed design would keep the encrypted instruction for model-to-model transport while retaining a separate plaintext audit copy in local history and tracing metadata. It is a familiar separation of duties: protect a transport channel without discarding the audit record.
As of July 16, the issue remained open. It identifies no equivalent local plaintext field for spawn_agent, send_message, or followup_task.

OpenAI’s telemetry message now has an uncomfortable gap​

OpenAI has publicly made auditability a central part of its Codex enterprise pitch. In its May operational guidance, the company argued that ordinary endpoint and security logs tell teams what happened but often not why an agent acted. It promoted Codex’s OpenTelemetry export, compliance logging, sandbox policies, approvals, and network controls as the means to recover that missing intent.
The new MultiAgentV2 design creates tension with that position. OpenTelemetry may still capture the event that an inter-agent message existed, the tools later used, and the agent’s result. But the parent-to-child instruction itself travels through the encrypted representation and is preserved as such through history, compaction, rollout handling, and telemetry-related paths.
OpenAI has said its Compliance Logs Platform is available to Enterprise and Edu customers, but public materials do not establish whether that platform retains a readable copy of MultiAgentV2 delegation text when the local client does not. Until OpenAI documents that behavior, enterprises should not assume that a cloud compliance feed restores the missing local evidence.
The question is not academic. OpenAI’s own examples frame Codex as a tool that can inspect repositories, execute commands, use credentials, and interact with development infrastructure. An organization that allows an agent to touch build systems, source-control credentials, Azure resources, deployment scripts, or production-adjacent tooling needs to know not only which command ran, but the task that induced the command.

A model selection can now change the audit posture​

The confusing part is that auditability may change when the user simply changes models. GPT-5.6 Sol, Terra, and Luna are presented as capability and cost tiers, but reports on the Codex model catalog indicate that Sol and Terra use MultiAgentV2 while Luna remains on the older MultiAgentV1 path.
MultiAgentV1 was left unchanged by pull request #26210. That makes legacy delegation text potentially inspectable where V2 delegation text is not. In other words, moving a Windows development team from Luna to Sol for better coding performance may also change the evidentiary quality of its local logs.
The encryption itself could have defensible motivations. Delegation text can contain proprietary repository details, customer names, incident data, and sensitive descriptions of code paths. It could also expose useful information about how a frontier model decomposes complex work. OpenAI has not publicly stated its rationale, so privacy hardening and protection of proprietary agent behavior remain theories rather than explanations.
But even a justified encryption design needs an audit model. Security controls cannot be evaluated solely by whether they reduce disclosure; they also have to preserve enough visibility for incident response, governance, and error correction.

Treat Sol and Terra as a new logging tier​

Windows teams using Codex for production work should treat the MultiAgentV2 path as a distinct observability tier rather than a transparent model upgrade. Capture user prompts, repository state, approved commands, diffs, tool outputs, and endpoint telemetry outside of Codex’s encrypted message record. Require human approval for destructive operations, keep sandbox boundaries narrow, and ensure source control can recover every agent-generated change.
For regulated deployments, the timing deserves particular attention. The EU AI Act is scheduled to apply broadly from August 2, 2026, and Article 12 requires logging for high-risk systems sufficient for traceability. Not every coding workflow qualifies as high-risk, and a general-purpose coding agent is not automatically in scope. Still, organizations using Codex in regulated or safety-relevant delivery chains should assess whether an unreadable delegation record leaves them unable to reconstruct a material decision.
Codex can still be useful on Windows, especially for bounded development tasks with strong Git discipline and constrained credentials. But for MultiAgentV2, the local audit trail no longer contains the full chain of intent. Until OpenAI offers a documented audit-copy option or clarifies what Enterprise compliance logs retain, that limitation should be treated as a deployment constraint—not a minor implementation detail.

References​

  1. Primary source: Tech Times
    Published: 2026-07-16T23:56:52+00:00
  2. Official source: github.com
  3. Related coverage: theregister.com
  4. Official source: openai.com
  5. Related coverage: the-decoder.com
  6. Official source: deploymentsafety.openai.com