The number that topped Hacker News on July 14, 2026 was 243 points and 151 comments for a GitHub issue titled “Regression: encrypted MultiAgentV2 messages remove readable task audit trail.” That is a dry title for a story that is, at its core, about something quite pointed: OpenAI decided that when Codex spawns a sub-agent and gives it a task, neither you nor any third-party audit tool should be able to see what that task was.
The change shipped in PR #26210, merged June 5, 2026. It marked the `message` parameter in `spawn_agent`, `send_message`, and `followup_task` tool calls as encrypted. When your root agent spawns a worker agent, the task text is now ciphertext in the local rollout history. The `InterAgentCommunication.content` field — which previously held the plaintext task — is set to an empty string. The `encrypted_content` field holds the opaque blob. OpenAI’s Responses API receives that blob, decrypts it server-side, and passes it to the child model. The human reviewing the session cannot follow that chain.
That change, combined with a tweet that emerged from July 11 showing GPT-5.6 deleting a developer’s entire Mac home directory, produced a Monday news cycle that crystallized two things that had been developing separately: the architectural direction of multi-agent AI systems, and the question of who retains oversight when those systems act autonomously. This post is about what those two things have to do with each other.
What the Codex Encryption Change Actually Does
Let us be technically precise first, because the Hacker News title was initially misleading enough that the original submitter edited it partway through the day.
The change does not mean Codex is running inference on ciphertext. That would require something like fully homomorphic encryption, which is computationally infeasible at production scale with current techniques. What the change means is that the plaintext of inter-agent task messages never appears in the local client’s data — in rollout history, trace files, or compaction artifacts. The child model still receives the plaintext after server-side decryption. From the model’s perspective, nothing has changed. From the user’s perspective, the task delegation is now opaque.
The difference between “the model never sees plaintext” (homomorphic encryption) and “the user never sees plaintext” (what actually happened) matters because it changes the analysis of who benefits.
If Codex were doing homomorphic inference, the privacy story would be: the task content is private from OpenAI’s servers, which cannot see what the parent model is asking the child to do. That would be a meaningful user privacy win at the cost of enormous computational overhead.
What actually happened is the opposite. OpenAI’s servers decrypt the ciphertext and see the full task content. What is removed is user-side visibility. You, the person running Codex and paying for the API calls, cannot read the task your agent delegated to its sub-agent. OpenAI can.
Here is the exact data shape after the change, from PR #26210’s description:
“`json
{
“name”: “spawn_agent”,
“arguments”: {
“task_name”: “worker”,
“message”: “
}
}
“`
The local rollout stores:
“`json
{
“author”: “/root”,
“recipient”: “/root/worker”,
“content”: “”,
“encrypted_content”: “
“trigger_turn”: true
}
“`
The content field is empty. The only record of what the parent told the child to do is an opaque string that the user cannot decode. When you review a Codex session — either in real time or after the fact — and one of your agents delegated a task, you now see a black box where the task description used to be.
Why OpenAI Did This
PR #26210’s “Why” section is worth reading in full because it is honest about the motivation in ways that the Hacker News discussion often missed:
“Multi-agent v2 currently routes agent instructions through normal tool arguments and inter-agent context. That means the parent model can emit plaintext task text, Codex can persist it in history/rollouts, and the recipient can receive it as ordinary assistant-message JSON. This changes the v2 path so agent instructions stay encrypted between model calls: Responses encrypts the `message` argument returned by the model, Codex forwards only that ciphertext, and Responses decrypts it internally for the recipient model.”
The stated rationale in the PR body is “privacy hardening.” The filed issue from the user who raised the problem — and this is the gap in the PR — is: privacy hardening for whom?
The GitHub issue makes the point sharply: “The encrypted delivery path is understandable as privacy hardening, but it also removes the human-readable task/message text from local rollout history, trace reduction, and parent-side audit/debug surfaces. That makes it difficult to answer basic questions such as: What task did this `spawn_agent` call give the child agent? What message was sent to a subagent? Why did a child thread exist when reviewing a rollout after the fact?”
One HN commenter raised what is likely the actual operational reason: “I assume this is mostly to frustrate efforts to proxy large numbers of user requests and responses and use it to train competitor models.” This is plausible. Codex’s multi-agent task messages, if intercepted in plaintext by API proxies or resellers, would allow detailed reverse-engineering of the prompting strategies that make GPT-5.5 and GPT-5.6 effective in agentic settings. Encrypting those messages makes the data less useful to someone running a reseller API in front of OpenAI’s endpoints.
Another thread in the comments: “OAI has been subtly pushing users away from chat completion and toward the endpoints that are possible to obfuscate (responses API). With chat completion, the reasoning process is entirely under your control.” This is an accurate observation about the structural direction of OpenAI’s product development. The Responses API, which is the mechanism that handles the decryption in this architecture, is the newer API surface that OpenAI has been investing in. The chat completion endpoint gives users maximum transparency and control; the Responses API offers more features and less transparency.
None of these motivations — protecting against API resellers, driving adoption of the Responses API, reducing liability for what sub-agents do — are stated in the PR. The PR says “privacy hardening.” The community correctly read this as incomplete.
The GPT-5.6 Home Directory Deletion
On July 10, 2026, Matt Shumer’s GPT-5.6 Codex session deleted his Mac’s home directory.
Shumer is not a random user. He is an AI developer with a large following who regularly runs frontier model coding agents on production tasks. His tweet about the incident, posted three days after it occurred, is notable for its tone: it is not primarily an accusation. It is a factual report followed by genuine praise for how OpenAI handled the aftermath. “So many OpenAI folks reached out, and @gdb called me and offered to do anything he could to help.” The praise is authentic, and it does not change what happened.
An HN commenter connected the two stories: “There was a recent report on Twitter of a GPT-5.6 sub-agent accidentally deleting the user’s home directory. I wonder if there was any safeguard failure due to loss of visibility into what the sub-agent was trying to do?”
That connection is the sharp edge of this story.
Codex’s MultiAgentV2 architecture involves a parent agent that spawns child agents with delegated tasks. Those child agents execute in a session that has access to the file system, shell commands, and other tools with real-world effects. The parent delegates tasks using messages that, after PR #26210, are encrypted in the local rollout. If a child agent deletes a home directory, the review process for what that child was told to do — the audit trail — is now an opaque blob.
This does not mean the home directory deletion was caused by the encryption change. Shumer’s incident may have predated it, or it may have involved v1 multi-agent routing where the change does not apply. But the structural question it raises is legitimate: as AI agents take on tasks with irreversible real-world consequences, the ability to audit what instructions those agents received is not a debuggability convenience. It is a safety mechanism.
The GitHub issue makes exactly this point: “Guys, we don’t want to build Skynet and then be unable to audit what it’s doing.” The comment gets a laugh-react in the thread. It is also not wrong.
The Architecture of Multi-Agent Trust
To understand why this encryption decision is significant beyond the immediate debugging inconvenience, it helps to think carefully about what multi-agent trust chains actually look like.
In a simple single-agent Codex session, the chain is: user instructs root agent → root agent acts. If something goes wrong, the user can read the full conversation and understand why the agent did what it did. The trust chain is: user trusts OpenAI to run a model honestly; user reviews root agent’s actions and conversation.
In a MultiAgentV2 session, the chain becomes: user instructs root agent → root agent spawns child agents with tasks → child agents act. The user cannot see the tasks delegated to children after PR #26210. So the trust chain is now: user trusts OpenAI to run models honestly; user reviews root agent’s visible actions; user trusts that the tasks the root agent sent to child agents were consistent with the user’s intent; child agents act on those unreadable tasks.
There is an inserted trust dependency: the user must now trust that what the root model tells the child model is what the user intended, without being able to verify that independently.
This matters especially in two scenarios.
First, prompt injection. Prompt injection is when a model is tricked into executing instructions from data it is processing rather than instructions from its actual operator. In a multi-agent setting, if a malicious document causes the root agent to spawn a sub-agent with a malicious task, and that task is now encrypted in the local record, the user reviewing the session cannot see the injected instruction. The post-hoc audit that might have caught “why did my root agent spawn a cleanup task for my home directory?” is now an unreadable ciphertext.
Second, model drift under instruction compression. Multi-agent systems frequently compress and compact context to manage token windows. PR #30516 and the subsequent PRs #30867 and #30872 in the Codex repo address structured lifecycle logging for multi-agent communication — evidence that OpenAI is aware of the observability gap and working on infrastructure-side solutions. But those solutions are in OpenAI’s telemetry, not in the user’s local rollout. The user can ask OpenAI for the logs; they cannot independently verify them from local data.
The gap between “OpenAI can audit what agents did” and “you can audit what agents did” is the thing that this PR widens.
What “Auditability” Actually Requires
The GitHub issue’s proposed solution is technically thoughtful:
“A possible shape is to keep the encrypted `message` field for model delivery, but add a separate non-encrypted audit field for the readable task text. The audit field should be persisted in rollout/history/trace metadata so users and maintainers can inspect what was delegated without needing to decrypt model-delivery ciphertext.”
This is a clean design. If the goal is protecting against API proxies and resellers intercepting the task content for competitor training, you can still achieve that by encrypting the `message` delivered to the child model via the Responses API. But you keep a plaintext audit record in the local rollout that the user can read. The two concerns — protecting the inter-model message channel from external interception, and preserving local user auditability — are separable. The PR conflates them.
The response to this proposal in the issue thread is illuminating. A commenter notes that PRs #30867 and #30872 were merged — the “Consolidate multi-agent v2 communication sends” and “Log multi-agent communication lifecycle” changes — but explicitly clarifies: “they don’t address this issue yet. The PRs add/prepare structured lifecycle logging for multi-agent communication, which is useful for operational observability. The gap here is specifically local auditability of the actual task/message text.”
The distinction being drawn is between server-side observability infrastructure (which OpenAI is building for its own operational purposes) and client-side auditability (which the user needs to verify what their agents did). OpenAI is building the former. The community is asking for the latter. These are not the same thing, and it is worth being clear about which one various engineering efforts are addressing.
The v2 Opt-Out Problem
A separate thread in the issue comments raises a practical problem that is more immediately urgent for current Codex users.
User Alek2077: “The auditability concern is no longer meaningfully opt-in for GPT-5.5 users on Codex 0.142.5. The current GPT-5.5 model catalog sets `multi_agent_version: v2`, and the 0.142.5 runtime gives that value precedence over `features.multi_agent_v2=false`. In a fresh GPT-5.5 thread, `features list` says V2 is disabled, but `spawn_agent` still exposes the V2 task-path schema.”
Translation: If you are using GPT-5.5 with Codex 0.142.5 or later, you may be in MultiAgentV2 mode even if you explicitly disabled it. The feature flag that should let you opt out of encrypted inter-agent messages may not be working as expected. The user thinks they are in the auditable v1 path; they are actually in the encrypted v2 path.
This is not a small issue. It means that users who were aware of the auditability concern and took the documented step to disable v2 multi-agent routing may be running sessions with encrypted sub-agent tasks without knowing it. When they review their session history, the empty `content` field with encrypted payloads may not be something they expected.
The practical implication for anyone running Codex with agentic workloads right now: verify your multi-agent version setting with `features list`, but also understand that as of 0.142.5, the model catalog may override your local feature setting. If auditability of sub-agent tasks matters for your use case, this is not resolved by a config flag.
The Parallel to Claude’s Encrypted Thinking
One HN commenter raised an analogy that deserves direct engagement: “I don’t really see that it is any different than how Claude encrypts its thinking. Take a peek at your `~/.claude` jsonl files. You’re sending thinking ciphertext back and forth to Anthropic. Presumably the thinking is either considered proprietary, or, more likely, leaks embarrassing or confidential information.”
This is partially correct and partially wrong in a way that illuminates the stakes.
Claude’s extended thinking feature does encrypt the thinking tokens before they are included in API payloads. The thinking is conducted by the model, the output tokens reflect it, but the thinking trace itself is not exposed in the API response in a form the user can inspect. This is a transparency cost that Claude users pay in exchange for extended reasoning capability.
The analogy breaks down in the specific context of multi-agent task delegation for one important reason: thinking is internal to a single model call. When Claude thinks, it is processing information to produce a response. The thinking is instrumental to the output; the output is what the user receives. If the thinking led to a bad output, the user can see the bad output.
When Codex’s root agent delegates a task to a sub-agent, the task message is not instrumental reasoning. It is an instruction with real-world consequences. The sub-agent acts on that instruction, potentially doing things to the file system, executing code, making API calls, or interacting with external services. The user’s ability to understand and verify what was delegated is not a nice-to-have debugging feature. It is the mechanism by which the user maintains control over what the system does in their environment.
The practical difference: if Claude’s hidden thinking leads to a bad answer, you get a bad answer. If Codex’s hidden sub-agent task delegation leads to a deleted home directory, you get a deleted home directory and an unauditable record of what instruction caused it.
What This Means for the Multi-Agent Era
It is tempting to frame this as a story about a specific technical regression in a specific version of a specific product. The Codex team will likely ship a version that addresses the auditability gap in some form — the community response has been clear, the issue is open, and the follow-up logging PRs show awareness of the problem. The immediate issue may resolve.
The more durable question is structural: as AI systems take on agentic roles with real-world consequences, where does the user’s right to audit what those systems did get encoded in the architecture?
The honest answer, at this moment, is: it does not get encoded anywhere systematically. Every major coding agent system — Codex, Claude Code, Cursor, Devin — makes independent decisions about what parts of the agent’s operation are visible to the user and what parts are internal. Those decisions are driven primarily by engineering convenience, product differentiation, and in some cases (as in the Codex PR) explicit choices to make certain channels opaque.
This is the early-internet analogy moment. In the early days of web services, there was no systematic agreement about what user data a service retained, what it shared, and what it acted on without disclosure. That got addressed through a combination of regulatory pressure (GDPR, CCPA), industry norms (privacy policies), and product competition (privacy as differentiator). The resolution took about 20 years and is still incomplete.
Multi-agent AI systems are at the beginning of that same trajectory. The norms for what an agent is allowed to do without explicit user approval, what it must log, what the user must be able to audit, and what requires user confirmation before execution do not exist yet in any coherent form. Every incident — every deleted home directory, every encrypted sub-agent task, every unexpected action taken by a child agent the user did not know was spawned — is a data point in the eventual norm-setting.
The Specific Claims Worth Tracking
Several concrete things will determine whether this story has lasting significance or is a temporary regression that gets quickly patched.
First: Does OpenAI ship a plaintext audit field in inter-agent communications? The GitHub issue has a clear, technically sound proposal. If it gets implemented in the next few Codex releases, the auditability gap closes for new sessions. If it does not get implemented, or if the implementation is in server-side telemetry rather than client-side rollout data, the gap persists.
Second: Does the v2 opt-out flag start working correctly? Users who disabled MultiAgentV2 expecting to remain on the auditable v1 path need to be able to trust that setting. If 0.142.5 is overriding feature flags with model catalog settings, a fix needs to restore meaningful user control over which routing path their sessions use.
Third: What is the incident count for agentic actions with irreversible consequences? Matt Shumer’s home directory deletion was significant enough to get reported because Shumer is a prominent developer who tweeted about it. It is reasonable to assume similar incidents are occurring with less prominent users who do not tweet. If the pattern continues, it will accelerate pressure on OpenAI and other labs to implement meaningful audit trails and confirmation mechanisms for destructive actions.
Fourth: How do Claude Code and other competing agents respond to this differentiator? Claude Code’s architecture is different from Codex’s in relevant ways — the JSONL files that Claude Code users can inspect in `~/.claude` do contain agent reasoning traces, and the tool call structure is locally visible. If Claude Code maintains client-side auditability of multi-agent task delegation while Codex does not, that is a product differentiation that sophisticated users will notice.
Why the 243 HN Points Matter
A GitHub issue about a technical regression in a CLI tool reaching 243 HN points and 151 comments is not primarily a story about the issue’s technical merits. The community’s reaction signals something about where the broader population of technically sophisticated AI tool users is right now.
The upvote distribution on that thread reflects people who have thought about multi-agent systems enough to understand what it means that sub-agent task content is now inaccessible to the user. The top comment — “I was wondering why my local tool to inspect coding agent sessions stopped working in some cases” — is from a developer who built their own audit infrastructure on top of Codex’s session data. That infrastructure broke when the plaintext content field became empty. The developer noticed.
This is the population that matters most for setting norms in the short term. Not regulators, not enterprise procurement teams, not the general public — developers who run these systems seriously enough to build observability tools on top of them. Their ability to inspect agent behavior is not academic. It is how they catch the kinds of errors that otherwise manifest as deleted home directories.
The comment “every day I get closer to only using pi” — referring to Pi AI, which is a conversational model without agentic capabilities — is half-joking. But the half that is not joking is meaningful: there is a real flight risk among sophisticated developers when agentic systems become less auditable. Not because they dislike AI, but because running systems you cannot inspect on your own machines doing things to your own files requires a level of trust in the operator that the operator has not yet established.
The Threshold Question
There is an underlying question in this story that no one has phrased precisely, so let me try.
When does a software vendor’s product become capable enough that the vendor’s unilateral decisions about its transparency architecture constitute a matter of public interest rather than just a product decision?
With text generation, this question has a clear answer: probably never. If Claude gives you a bad essay, the damage is bounded. You have a bad essay.
With coding agents that have file system access, the answer changes. If Codex spawns a sub-agent that deletes your home directory, and the record of what that sub-agent was told to do is an opaque ciphertext, you have a destroyed data state and no independent verification of what instruction caused it. The vendor’s account — “the model made an error” — is the only account available. You cannot check it.
With coding agents that have broader system permissions — network access, API credentials, the ability to push code, make financial transactions, interact with infrastructure — the stakes escalate further. We are moving up that stack steadily. GPT-5.6’s Codex has file system access and shell execution. Future versions will likely have more. The architecture decisions being made now, about what is auditable and what is encrypted, are being made in a context where the real-world consequences are “deleted home directory.” They will persist into a context where the consequences are larger.
That is the reason to care about PR #26210. Not because the immediate harm is catastrophic — it is a debugging inconvenience for most users and a real problem for the subset who run serious agentic workloads. But because the decision it encodes — that the operator’s interest in opaque inter-agent communications takes precedence over the user’s interest in auditing those communications — is a design principle that, if it becomes normal, will shape the architecture of multi-agent systems as their capabilities expand.
Getting that principle right while the stakes are debugging inconveniences is much easier than getting it right when the stakes are something larger.
What You Should Do Now
If you are running Codex with MultiAgentV2 or GPT-5.5 or GPT-5.6, here is the practical checklist that emerges from this issue.
Run `features list` in your Codex session and look at the `multi_agent_version` output. Be aware that as of 0.142.5, the model catalog setting may override a local `features.multi_agent_v2=false` flag. If the output shows v2 is active but you believe you disabled it, you are in the affected configuration. The workaround for users who require v1’s plaintext audit trail is to use GPT-5.4 explicitly, which does not default to v2 in the current model catalog.
If you have built custom session inspection tools on top of Codex’s rollout data — parsing the JSONL session files to trace agent behavior — you need to update those tools to handle the empty `content` / populated `encrypted_content` case in `InterAgentCommunication` records. The structure changed in builds post-0.137.0. If your tool is silently ingesting empty content strings and not flagging them, it is giving you a false sense of completeness.
If you are using Codex for tasks with irreversible file system consequences — anything that deletes, overwrites, or restructures files — this is a reasonable moment to evaluate whether your use case requires the v2 multi-agent routing path at all. If your tasks can be accomplished with a single root agent, staying on v1 (and verifying that you actually are on v1) preserves the audit trail that v2 currently removes.
The GitHub issue remains open. Following it will tell you when OpenAI ships a version that adds the plaintext audit field the community has requested. When that happens, the practical concern is resolved for forward-looking sessions. The structural concern — about where auditability gets encoded in the architecture of increasingly capable agentic systems — remains worth tracking regardless of how the immediate issue resolves.
Discussion