OpenAI's Codex Now Encrypts What Your Agents Say to Each Other. You Can't Read It.

TL;DR

OpenAI changed how Codex's multi-agent mode moves work around, and it did it quietly. When a parent agent hands a task to a sub-agent, the instruction is now encrypted. Codex forwards only the ciphertext, OpenAI's Responses service decrypts it on the server, and the plaintext copy that used to sit in your local session logs is empty. Coding agents that spawn other coding agents just became a black box to the human who launched them. The change surfaced this week via The Register, and builders are not thrilled.

What actually changed

Codex has an experimental multi-agent mode (multi_agent_v2) where one agent can hire others: it can spawn_agent, send_message, and queue a followup_task. Until recently, the text of every one of those calls landed in your local rollout history as plaintext. You could open the log and read exactly what your lead agent told its underlings to do.

Now that text is encrypted. In the message record, the readable content field is left empty and the payload lives only in an encrypted_content field that travels to OpenAI and back. As The Register put it, the model encrypts the message argument, Codex forwards only that ciphertext, and the Responses API decrypts it internally. Your machine never sees the plaintext.

Per developer testing summarized by Developers Digest, the encryption shows up on OpenAI's newest Codex models (the GPT-5.6 Sol and Terra variants), while Luna appears unaffected for now. The mode is off by default and still labeled experimental, so if you have never flipped it on, nothing about your day changed. If you run agents that hire agents, quite a lot did.

Why builders actually care

The plaintext was not decoration. It was the audit trail. Removing it takes the readable task text out of three places at once: your local rollout history, the trace-reduction view, and the parent-side audit and debug surfaces. In other words, every spot you would look to answer the question "what did my agent just tell the other agent to do?" now returns ciphertext.

Think of it like a foreman who writes every work order in a language only head office can read. You can see that orders are flying around the job site, you can watch the crew scramble, but you cannot read a single instruction. When the building comes out wrong, "let me check the paperwork" is no longer a move you have.

We don't want to build Skynet and then be unable to audit what it's doing.

That line is from Ignat Remizov, CTO of Zolvat, quoted by The Register. It is a joke with a real edge under it: the entire selling point of multi-agent systems is that they act on their own, and the entire safety story for those systems is that a human can go back and see what they did. Encrypting the hand-off keeps the first half and quietly deletes the second.

The "you can't just turn it off" wrinkle

Experimental and off by default sounds reassuring until you read the bug reports. In issue #31097, a developer says a recent CLI build forces the multi-agent v2 surface on even when they set features.multi_agent_v2 = false in config.toml and pass command-line overrides. The same report says the v2 schema quietly drops the agent_type, model, and reasoning_effort controls that v1 exposed, so you cannot pin a sub-agent to the reviewer profile you configured. That is one person's report against one build, not a confirmed universal behavior, but it is exactly the kind of thing that turns an opt-in experiment into a default you did not choose.

Why would OpenAI do this?

OpenAI has not explained the rationale. It shipped the technical description in the pull request and left it there. Into that silence, two theories have grown.

• Privacy and safety hardening. Inter-agent messages can carry chunks of your code, secrets, and intermediate reasoning. Encrypting them shrinks the surface for prompt injection and for anything that scrapes local logs. This is the charitable read, and it is not a bad one.
• A competitive moat. The plaintext hand-offs were also a free tutorial on how OpenAI's multi-agent orchestration is wired. Encrypt them and rivals lose a window into the plumbing. The ciphertext, in this reading, is doing double duty as a trade secret.

Both can be true at once. What is missing is OpenAI simply saying which, and giving the people running these agents a supported way to keep their own audit log.

What you can do right now

Until there is an official knob, the community workarounds are blunt but real:

• Keep multi-agent workflows on a model that still emits plaintext (Luna, per current testing) rather than the encrypting variants.
• Skip Codex's built-in multi-agent mode and orchestrate sub-agents yourself through the app-server RPC, where you control what gets logged.
• Run a different agent for fleets. If local auditability is a hard requirement, Claude Code and other open harnesses keep the delegation text where you can read it.

There is also a fix in flight. The tracking discussion in issue #28058 proposes keeping the encrypted payload for the model while adding a required plaintext companion field (a task_message) so parent rollouts keep a readable record. A related change, PR #27830, already routed Codex's own child-completion notices back through a typed plaintext path. So the maintainers clearly see the gap. Whether the human-readable audit field lands, and whether it is on by default, is the thing to watch.

Key Takeaways

• Codex's multi-agent mode now encrypts inter-agent messages: the readable content field is empty and only encrypted_content moves, decrypted server-side by OpenAI.
• It hits spawn_agent, send_message, and followup_task on the newest models (Sol and Terra per testing); Luna looks unaffected so far.
• The cost is auditability: the task text vanishes from local rollout history, trace reduction, and parent-side debug surfaces, the exact places you would inspect an agent after the fact.
• One developer reports the mode can be forced on despite being disabled in config, and that it hides v1's per-agent model and reasoning controls (issue #31097).
• OpenAI has not stated why. Leading guesses are prompt-injection hardening and keeping its orchestration a trade secret.
• Workarounds exist today (stick to plaintext models, self-orchestrate, or use another agent), and a plaintext-audit-field fix is under discussion in issue #28058.

Sources: The Register, openai/codex issue #28058, openai/codex issue #31097, openai/codex PR #27830, Developers Digest, openai/codex on GitHub