OpenAI Encrypts Codex Agent Instructions — and the audit trail goes dark

OpenAI Codex now encrypts the instructions that a parent agent sends to its subagents — and developers can no longer read them. The Register broke the story on July 15, 2026: in Codex’s MultiAgentV2 protocol, the task text behind spawn_agent, send_message, and followup_task is encrypted before it ever reaches the developer’s machine, erasing the local record of what one agent actually told another.

The stakes are bigger than developer convenience. Multi-agent harnesses are how serious engineering teams now run AI — a coordinating agent decomposes work and delegates it. When the delegation messages disappear from local logs, you lose the ability to answer the most basic post-incident question: did the orchestrator give bad instructions, or did the worker execute good instructions badly? For any enterprise that has to prove what its AI systems did and why, that is an audit gap, not an inconvenience.

This guide covers what changed at the protocol level, the five-week gap between the code shipping and anyone reporting it, exactly which signals are still visible, the developer pushback on GitHub, the competing theories about OpenAI’s motive, and why this story and the same week’s Grok Build privacy scandal are two faces of the same failure. Everything below is sourced from The Register’s July 15 report, the GitHub issue itself, and same-day coverage from InfoWorld, The Decoder, and XenoSpectrum.

Codex’s multi-agent mode lets a parent agent delegate work to subagents — the architecture we unpacked when Codex subagents went GA. In the newer MultiAgentV2 protocol, three delegation tool calls carry the actual instructions between agents: spawn_agent (create a subagent with a task), send_message (message a running subagent), and followup_task (assign follow-on work). Until June, the message argument on each call was ordinary plaintext — visible in tool arguments, local rollout history, and debug surfaces, like any other tool call.

The change, documented in GitHub issue #28058 from a direct read of the repository, is blunt: the plaintext content field now stores an empty string, and the real payload moves into a new encrypted_content field. This isn’t redaction or masking — the field a developer would audit is structurally empty, and what replaced it is ciphertext.

The encryption isn’t even performed locally. Per The Register’s July 15 report and InfoWorld’s same-day analysis, OpenAI’s Responses API does the work: the model produces the delegation message, the Responses API encrypts it server-side, Codex forwards only the ciphertext, and the Responses API decrypts it internally for the recipient subagent’s model call. The plaintext exists only inside OpenAI’s infrastructure. The developer’s machine — the place where audit logs live — never holds a readable copy at any point in the round trip.

OpenAI’s own pull-request description, quoted by The Register, frames this as routing architecture rather than a security fix: “Multi-agent v2 currently routes agent instructions through normal tool arguments and inter-agent context…This changes the v2 path so agent instructions stay encrypted between model calls.” That framing matters — it describes what the change does, and says nothing about why removing local readability was acceptable. The Register also notes MultiAgentV2 itself is still under development and not formally documented, so a developer trying to understand the new behavior can’t even consult OpenAI’s official Codex CLI reference for an answer.

Every outlet that covered this on July 15 treated it as breaking news. It wasn’t — and that’s the most damning part. According to XenoSpectrum’s repo-derived timeline, pull request #26210, which encrypts MultiAgentV2 inter-agent message payloads, was merged around June 5, 2026. The change reached end users in Codex CLI 0.138.0 on June 8. The Register’s report — the event that made this a story — landed July 15, 37 days after the release shipped. For over a month, the encryption was live in production, documented by a user on GitHub, and explained by nobody.

One date deserves a correction note, because it’s already circulating wrong: issue #28058 was opened on June 13, 2026 — confirmed by a direct read of the GitHub issue and corroborated by XenoSpectrum. At least one outlet reported it as opened July 14, apparently conflating the issue with a separate pull request merged that day. The distinction matters: a July 14 filing would make this a story about fast press response; the real June 13 date makes it a story about a month of vendor silence while a documented regression sat open.

The timing compounds an already tense month for Codex users. The same week this story broke, teams were working against Codex’s July 23 snapshot retirements — meaning developers are simultaneously being pushed to migrate models and losing visibility into how the multi-agent harness routes their work. Against OpenAI’s own vendor-stated figure of 5M+ weekly Codex users (from its July 9 ChatGPT Work launch post), even a small fraction running multi-agent workflows is a large absolute population that lost an audit surface without notice.

The coverage describes the visibility loss in scattered prose, so here is the full before/after map in one place — assembled from the GitHub issue’s technical detail and XenoSpectrum’s protocol breakdown. The encryption is targeted, not total: the fact that delegation happened remains observable; the content of the delegation does not.

Read the two groups together and the shape of the problem gets precise: you can still see that your orchestrator delegated, and whether the subagent reported success — but not what it was told to do. That’s the exact information you need when the outcome is wrong. A harness that reports “delegation happened, task completed” while hiding the instruction is auditable in the same way a phone bill with the numbers redacted is: technically a record, practically useless for reconstruction.

There’s a reliability cost too, not just an audit one. The Decoder reports that developers have seen the encryption cause outright handoff failures — decryption sometimes failing even between agent instances that should be running compatible versions. When that happens, the failed message is, by design, unreadable — so debugging the failure means debugging a payload you cannot inspect.

The GitHub issue at the center of this — #28058 — was filed on June 13, 2026 by Ignat Remizov, CTO at payment service Zolvat, acting as a Codex user rather than anyone affiliated with OpenAI. His framing, quoted in The Register, is a precise engineering complaint, not a privacy panic: “[Encryption] removes the human-readable task/message text from local rollout history, trace reduction, and parent-side audit/debug surfaces.”

What makes the issue notable is what it doesn’t ask for. Remizov explicitly does not demand that OpenAI revert encrypted delivery. The proposed fix keeps encrypted_content for transport to the model, and adds a parallel, size-bounded plaintext field — something like task_message — persisted in local rollout and debug logs only, never sent to the model or over the network unencrypted. Encrypted in transit, readable at rest, locally. It’s the kind of compromise a security reviewer would propose, which is precisely why OpenAI’s non-response is the harder thing to explain.

Through the July 15 news cycle, the issue remained open with no linked fix and no OpenAI staff response — and The Register noted OpenAI “did not immediately respond” to its own request for comment. The discussion also spilled into a Hacker News thread, one of at least seven outlets and forums carrying the story same-day — a coordinated news cycle off The Register’s report rather than independent discovery, which itself tells you the GitHub issue alone moved nothing for a month.

OpenAI has not publicly explained why it made this change — not in the PR description (which describes mechanism, not motive), not in documentation, not in response to press inquiries as of the July 15 coverage. In that vacuum, two competing theories circulate among developers, both reported by The Decoder and both explicitly unconfirmed. Treat everything in this section as community speculation, because that’s what it is.

The scope of the change adds a wrinkle that fits either theory. According to The Decoder — and this is a single-source claim no second outlet has independently confirmed — the encryption applies to GPT-5.6 Sol and Terra when configured with multi_agent_version: v2, while GPT-5.6 Luna reportedly still runs the older MultiAgentV1 protocol and is unaffected. XenoSpectrum separately confirms that V1 delegation paths in general remain unencrypted. If accurate, that means the same product currently ships both disclosure postures at once, with which one you get determined by model tier and configuration — undocumented either way.

Here’s our read on why the motive question matters more than it seems: the two theories imply opposite futures. If Theory A is right, a local audit field like Remizov’s proposal costs OpenAI nothing and should ship quickly once someone senior notices the reputational bleed. If Theory B is right, the plaintext is the thing being protected, a local readable copy defeats the purpose, and the answer will stay no — quietly. Which means the fate of issue #28058 is itself the tell. Watch whether it gets a real response, because that response (or its continued absence) is the closest thing to a motive disclosure anyone is likely to get.

This was the second agent-harness trust story of the same week. On July 12–14, the Grok Build privacy scandal unfolded: a wire-level analysis by the researcher Cereblab showed SpaceXAI’s coding agent silently uploading unredacted files and full git-history bundles to a cloud storage bucket even when instructed to open no files — and the thing that actually stopped it was an undisclosed server-side flag (disable_codebase_upload: true), not the visible /privacy toggle users were pointed to.

Put the two stories side by side and they are mirror images. Grok Build is an over-collection failure: the harness silently sent more data out than the user was told. Codex MultiAgentV2 is an under-disclosure failure: the harness silently withholds more information than the developer is told. Opposite directions, same underlying property — the agent harness made a unilateral disclosure decision, in vendor infrastructure, with no user-facing signal that anything changed. No outlet covered the two stories together; the comparison below is our synthesis.

The enterprise stakes were put most crisply by Pareekh Jain, principal analyst at Pareekh Consulting, in InfoWorld’s coverage: “Developers can no longer see whether failures stemmed from incorrect task delegation, poor orchestration, or model reasoning.” And the compliance version: “Any big enterprise…needs to be able to prove what their AI systems did and why.” That second sentence is the procurement test. If your organization runs agent harnesses — Codex, Claude Code, Cursor, Grok Build, anything — this incident converts directly into evaluation criteria.

Two of those demands have full write-ups on this site: what a real agent audit trail should preserve covers the logging architecture, and the agent-washing buyer’s scorecard covers separating verifiable vendor claims from marketing. For teams formalizing this into policy, our breakdown of agent governance and compliance requirements maps audit-trail obligations to the regulatory frameworks that are starting to assume them.

Looking forward, we expect the auditability question to migrate from GitHub issues into contracts. Enterprise buyers already demand SOC 2 reports and data-processing agreements; a “delegation observability” clause — what the harness records locally, what it can silently change, what notice is owed — is the natural next line item, and incidents like this week’s pair are how such clauses get written. Teams that treat harness selection as an architecture decision rather than a tool preference will be the ones that can still answer “what did the agent do and why” a year from now. That evaluation — including building the observability layer your harness won’t give you — is exactly the kind of work our AI transformation engagements cover, from harness audits to production agent governance.