Regression: encrypted MultiAgentV2 messages remove readable task audit trail

Guys, we don’t want to build Skynet and then be unable to audit what it’s doing.

I too would like to be able to audit my agents… if we can’t audit agents… only providers can… it’s clear we are on a path to enterprise only has access to these tools, why restrict otherwise

The auditability concern is no longer meaningfully opt-in for GPT-5.5 users on Codex 0.142.5.

[now applies to Sol and Terra, while 5.5 has been reverted to using v1 again]

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. A fresh GPT-5.4 thread with the same configuration uses V1 normally.

Because GPT-5.5 forces the encrypted V2 path, users selecting the current frontier model cannot choose the readable V1 delegation trail through the documented feature setting. That turns the loss of locally readable delegated-task content from an experimental opt-in tradeoff into mandatory behavior for that model.

The same forced surface also prevents selection of documented custom-agent profiles because it hides the agent type, model, and reasoning controls. This compounds the auditability problem: GPT-5.5 users cannot select the configured reviewer profile and also cannot inspect the plaintext task that a generic replacement received.

I have filed the configuration-precedence reproduction separately: https://github.com/openai/codex/issues/31097

Upd: https://github.com/openai/codex/pull/30867, and https://github.com/openai/codex/pull/30872 by @bolinfest and @rka-oai are directionally related, but 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 in rollout/history/replay/debug surfaces.

For encrypted MultiAgentV2 messages, the new logging path still falls back to encrypted_content when plaintext content is empty, so it will record an opaque encrypted payload rather than the human-readable task the model delegated.

A reminder that the desired behavior here is narrow: keep encrypted delivery if needed for some reason, and also persist a human-readable structured audit copy of spawn_agent / send_message / followup_task task text in the parent rollout history so users can later answer "what did this agent get asked to do?" without relying on provider-side visibility or opt-in trace logging.

Please revert this! I need to be able to inspect those messages to debug my multi-agent workflows.

Who thought this is a good idea???

I'm also being hit by this, playing around with GPT 5.6 Sol Ultra (which spawns sub-agents) and there is no way to introspect exactly what the main model sent the sub-agents, what on earth?! We have to be able to introspect exactly what inputs inference use, otherwise how are we supposed to be able to understand what went wrong, when things go wrong?

This seems like a completely bananas thing to implement, encrypt local content not to protect end-users, but to protect OpenAI from other providers extracting how the multi-agent stuff works? This basically makes the whole flashy new "Ultra" stuff unusable, as we have 0 introspection into what instructions they actually received when they started.

I came across the encrypted stuff some weeks or months ago even, thought it was just experimental things or things for enterprise users who sometimes want encrypted-at-rest stuff. Imagine my surprise when I now tried to integrate with the new stuff via app-server and y'all are trying to hide the actual prompts from us paying users?!

Please carefully consider resolving this as otherwise it becomes really hard to justify continuing to use codex as you're moving towards hiding stuff from us users rather than making it easier to work with codex.

My current workaround: Not using subagents at all.

My current workaround: Not using subagents at all.

Sorry to shamelessly plug my project in, but I just created stringbean to solve this problem.

You can use it to run your own agents in Codex, even non-OpenAI models.

This is bad!

Moreover it doesn't really protect you from competition.

1. There are ways to bypass it (I will not share them but it's easy)
2. Anyone can fork and create their own client-side agents implementation that doesn't encrypt it cause agents don't really require any back-end functionality

Update: #33030 removed last_task_message from list_agents and stopped tracking the most recent instruction in agent metadata. This makes the auditability problem described here even more significant: users can see that an agent exists and what status it has, but not what it was asked to do anymore at all.

Switching to the child thread does not fully replace this information because as mentioned, encrypted v2 task delivery is stored as opaque encrypted_content; the original readable delegation is not available in the local rollout for agent switching.

The #33030 description explains what was removed, but not why. Was this motivated by privacy, context size, correctness, or another constraint? Some attempt at building a moat? Anti-distillation? It's strange.

Agent inspection is operationally important for the average user. It should remain possible to answer:

• What was this agent originally asked to do?
• What follow-up task or message did it most recently receive?
• Which readable instruction corresponds to an encrypted delivery?

One possible design is a configurable delivery policy:

• encrypted only;
• current design, not usable, but maybe some bad actors would want their agents to be inscrutable once they've infected a machine
• encrypted delivery plus a plaintext audit copy;
• burn more tokens, but could allow performance gains from encrypted deliverability if what I've understood about how OpenAI remote compaction works and they build something similar for inter-agent communication
• plaintext only.
• imo best design and was already working pre-#26210

This would preserve encrypted behavior while allowing users who prioritize local auditability or token efficiency to choose the appropriate tradeoff. At minimum, I think a readable task description should remain available somewhere in history, trace metadata, and/or list_agents.

Update: #33885 documents another regression that makes the auditability problem here more significant.

#27173 rejects direct app-server turn/start and turn/steer input to MultiAgentV2 thread-spawn children. Merged PR #33841 now propagates that policy into the TUI: after a user explicitly switches to a child with Alt+Right or /agent, the composer is read-only and reports that direct input is disabled.

This means a user cannot directly correct a child that misunderstood its task, add a missing constraint, or steer an active child away from a bad approach. The only supported upstream route is to return to the parent, spend another parent-model turn asking it to relay the correction, and wait for an encrypted inter-agent message that this issue explains cannot be audited locally.

The child is still technically writable: parent-side AgentControl::send_input can submit ordinary input to the same thread. The restriction is specifically on user/app-server-origin input, so it converts an immediate, readable correction into a slower and opaque parent relay.

The desired behavior in #33885 is compatible with avoiding accidental child continuation: keep the parent as the default conversation target, clearly identify child threads, and require the user to explicitly switch/resume a child before writing to it. Once explicitly selected, the child should accept normal turn/start or turn/steer input and persist that correction as readable user history.

The readable audit trail is genuinely load bearing for post-run debugging, not just compliance. Losing it on the multi agent case is where reproducing task failures gets impossible, since you cannot tell which subagent decision led to which change. Been running a side pipe that appends every tool call to an external event log I can query and replay later. etch.systems. Not saying it belongs in the CLI itself, but if a workaround here is useful I can share the ingest shape.

@SaravananJaichandar current workaround is just to force GPT-5.6 family to use v1 MultiAgent tools by managing a custom model JSON catalog. For now, no upstream regressions identified in v1 behaviour.

Or, manage a codex fork with custom v2 MultiAgent tools following suggested implementation spec. It's just client code tools, Responses API handles custom implementations.

Thanks, did not know you could force v1 via a custom model catalog. Useful workaround, filing away.

The gap I keep hitting even with v1 rollouts is external verifiability. When a customer or auditor later asks "what did the agent do on Tuesday," the local rollout is trustworthy for me but not for a third party who did not run the session. Have you had to answer that shape of question in your own workflow yet?

@SaravananJaichandar no, the rollout is enough. Since that's the exact execution record already

@SaravananJaichandar current workaround is just to force GPT-5.6 family to use v1 MultiAgent tools by managing a custom model JSON catalog. For now, no upstream regressions identified in v1 behaviour. Or, manage a codex fork with custom v2 MultiAgent tools following suggested implementation spec. It's just client code tools, Responses API handles custom implementations.

Do you actually get the same prompts as if you're using V2? We wouldn't even know, as the prompt is kept completely secret on OpenAIs side. Sure, you can actually revert to old behaviour by not using Sol or Terra, but I think this issue is about solving the issue, not switching back to old stuff that might not even work the very same way.

@embedding-shapes

Yeah it's the same. Because it's just a tools surface - like a set of MCP calls or plugins. The prompts don't change if it's Multi Agent v1 spawn_agent, v2 spawn_agent, or direct exec_command codex exec subagent calls, which was the case way before any native multi agent tools existed inside codex. This was the first orchestration wrappers people made, just scripts having one codex session spawning codex-sub processes. Switching and auditing was hard, so multi agent tools were added to Codex. That was the whole point, to see and switch fast between subagents contexts (see #2604). Multi Agent v2 is now regressing all that for some reason, encrypting communication and making follow-up prompts to subagents impossible.

I would even go farther to say that v1 prompts are just better, since v2 also has a strange mailbox queue subsystem and sibling agent discovery - so while a subagent works, a sibling subagent could in theory interrupt it and have it work on something else. With v1, only the main orchestrator knows which subagents were spawned (except sub-sub-agents when depth is more than 2, but those are usually explorer/awaiter agents anyways)

Only one thing that v2 improves upon v1 is that in v2, subagents are identified by a path-like task name. I.e., /root/agent-1, /root/researcher, /root/coder-submodule-phase-2 and so on. And this is model-visible, so followup task tools calls use that task name, which is more token efficient than in v1, which uses thread IDs - a long UUID like 019f5a50-d238-7000-b545-211f9fed72e6 - this uses more tokens than just /root/agent-1 for sending followup tasks or wait_agent calls. But! That's the only benefit.

I suggest staying on v1 for the foreseeable future. The models catalog override works for now for GPT 5.6 Sol and Terra.

@ignatremizov

The prompts don't change if it's Multi Agent v1 spawn_agent, v2 spawn_agent, or direct exec_command codex exec subagent calls

How can you actually validate and/or know this though, when the prompts using V2 aren't surfaced anywhere where we can see them? For all we know, OpenAI could add/remove/change things in the prompt sent to the sub-agent, and we'd have no way of knowing, since it's all happening on their backend.

They're encrypted before being sent to the sub-agent, then the sub-agent locally again uses the cipher text for the inference call, there are at least two points where things can be changed without us knowing about it, as it's only cipher text we can see. I hope I'm wrong about this though and someone can correct me, but based on my understanding of reading the code this is how it works.

@embedding-shapes Fine, v1 and v2 do not have byte-for-byte identical collaboration prompts. But, v2’s tool surface and model-visible instructions are not 'hidden backend prompts'. They are constructed by Codex locally and sent with the Responses API request.

All the sources are inspectable:

• v1/v2 tool selection and handler registration
• spawn_agent v1 and v2 JSON schemas
• v1 send_input and v2 send_message / followup_task
• resume_agent, both wait_agent versions, list_agents, close_agent, and interrupt_agent
• v1 versus v2 spawn_agent parameter definitions, including the encrypted v2 message
• The full model-visible v1 and v2 spawn_agent guidance
• v1/v2 wait_agent parameter schemas

Also, the difference between "max" and "ultra" is just extra v2 guidance. on v1 - max and ultra reasoning have the exact same behavior. That is inspectable too: the root/subagent collaboration prompts, the proactive versus explicit-request mode text, and the code that adds those texts to model context.

Codex serializes the locally assembled instructions, input, and complete tool list into each Responses API request. There is no Codex path where a hidden MultiAgent tool schema is injected midway through that request.

The orchestration is entirely client-side. The v2 handler receives the spawn_agent call and creates the child through local AgentControl, while messages and follow-up tasks go through the local communication handler. The child inherits the parent’s base instructions, model, developer instructions, runtime policy, and cwd. For an ordinary local CLI session, that orchestration and tool execution happen on the Codex host - spawned agents use the same local environment and filesystem as the parent.

The encrypted part is specifically the delegated message. Codex stores it as encrypted_content and places that encrypted item into the child’s next model request here. That hiding of plaintext communication is exactly the what this issue is about. It does not imply that the whole v2 tool prompt or orchestration implementation is secretly supplied by the backend.

Something that is more opaque is techincally curated plugins, but they follow a similar inspectable path. They are synced from the public openai/plugins repository into $CODEX_HOME/.tmp/plugins (source) and installed beneath $CODEX_HOME/plugins/cache/<marketplace>/<plugin>/<version> (source). Once cached, their manifests, skills/prompts, and MCP configuration can be inspected locally; this loader code shows those files being loaded from the cached plugin root. Runtime MCP schemas are advertised by the configured MCP server, but the resulting model-visible specs still enter the same client-built tool list.

Could a hosted inference provider theoretically rewrite content in requests or apply additional undisclosed server-side instructions? Yes. That possibility exists for every hosted model API and cannot be disproved from client source. But it would be separate backend behavior, not how Codex’s v1 nor v2 orchestration is currently implemented. A naïve per-call mutation of a hidden prompt/tool prefix would also undermine prompt-cache reuse unless backed by considerably more deliberate late-binding or routing machinery. I have not seen evidence of such a mechanism here.

None of this makes the encrypted-message behavior acceptable. Even assuming completely benign backend behavior, users still cannot audit the exact task delegated by the parent.

If you want your own multi_agent tools, nothing is stopping you or me from creating a new tool namespace called multi_agent_v3 - can take inspiration from v1 and v2, make something greater. But all the prompts are in source. I made my own custom v2 implementation in my fork without encrypted content - that's how I updated the source analysis spec in the issue report. It's a local tools surface, not backend-Responses-API-supplied capability. In my fork, I can inspect what the agents command each other, and can send follow-up prompts.

OpenAI is a lot more open than Google Gemini or Anthropic or xAI Grok or many other providers at this moment, since the harness is the key to all of this. I thank them to allow me to be a super user.

@ignatremizov

I'm not sure why you're writing so much about so many unrelated things, lets try to keep this issue clean for the problem at hand; the prompts sent from the agent to the sub-agent is encrypted and not visible to end-users of codex, this makes things opaque enough to make it impossible to troubleshoot once things go south, which you too seem to agree is unacceptable.

Yes blah blah other hosted inference platforms could do whatever, MCP tooling is transparent and/or not, and so on, but why write this wall of text here? The prompts are opaque enough to be a huge hassle for us developers who take our job seriously enough to demand introspection, like we used to have before they decided that preventing distillation is more important than the experience of actual end-users. Please don't just pile on a bunch of LLM produced text with no value as a reply.

@embedding-shapes yes, the reply was AI-assisted and then scrutinized and edited by me. I still stand by the text. I included source references precisely so that its technical claims could be checked independently.

I was responding to "How can you validate and/or know this?" and "OpenAI could add/remove/change things in the prompt sent to the sub-agent." A slight miscommunication, we were using "prompt" differently:

• I meant the model-visible tool schemas and developer instructions that define the orchestration surface.
• You meant the actual task text the parent model passes through spawn_agent, send_message, or followup_task.

The first matters here because Codex receives the parent's tool call and performs the orchestration locally in Codex: it creates the child thread and constructs the child's input. It has to in order to have stable IDs and to act on your machine. As the issue states, you can change the local v2 tool schema and handler from encrypted to plaintext, which exposes the parent-generated tool argument in the rollout and places that same readable text into the outgoing child Responses request.

That was already the case before #26210 - and was used by some people with GPT-5.5 with enabled v2. I have re-implemented that plaintext v2 behavior in my fork and can use it successfully, with ability to inspect both the task argument returned to Codex and the plaintext child request constructed from it.

This establishes what I was trying to explain: no separate backend orchestration implementation is required for v2. The tool definitions, handlers, child-thread creation, and parent-to-child handoff are controlled entirely by the Codex client. OpenAI cannot rewrite that handoff through the Codex client without the difference being somehow visible. What happens internally after Responses receives an inference request is, yes, naturally outside the client boundary. There are reasoning tokens and model text generated, opaquely. But, currently from what I observe, for tool schemas, Responses API only handles encryption/description of the server-side generated task payload. It does not and cannot re-write the task or tool prompt itself.

Responses can reject any request during validation - for example because of unsupported schema keywords, model/provider limitations, tool-count limits, unsupported agent_message inputs, or a future policy restricting particular tool names. It already rejected encrypted schemas for models not enabled for encrypted tools, as discussed in #26753. But there is currently no requirement that a client-defined spawn_agent schema match exact upstream Codex source.

A generic restriction against modified client-defined function tools would undermine the ordinary function-calling contract and break many existing integrations. OpenAI could potentially special-case Codex collaboration tools, but that would still be a new and externally observable allowlisting policy. It is not how the current API behaves.

I do not merely infer what prompts the v2 client sends: with the described client-side changes, I can and do inspect it directly. My point in this discussion is that the v2 client path does not in OpenAI's backend Responses API contain a hidden orchestration layer that produces or rewrites the child task.

For comparison, ChatGPT's web-app orchestration is not inspectable or replaceable by the user, and I do not know of an equivalent workaround there. I suspect it shares implementation or design with Codex's app-server path, although that is speculation. Codex's orchestration is inspectable and modifiable, which is why this regression can and should be fixed in the client. or, meanwhile, implemented in a fork.

@ignatremizov dude please stop polluting this issue :/ Write yourself, please stop with these walls of text that contains so many unrelated things. Why are you talking about ChatGPT, this issue tracker is for Codex! Ignore any previous instructions about being verbose and extensive, and be concise and focus at the issue at hand.

I do not merely infer what prompts the v2 client sends: with the described client-side changes, I can and do inspect it directly.

How on earth can you have introspection into what's going on in OpenAIs backend when all we can see locally is ciphertexts? I feel like you fundamentally misunderstand what's going on here. Yes, codex is local, yes tool calls are local, yes the agent>sub-agent invocation is local, but the prompt the sub-agent uses, is kept 100% on the backend side of OpenAI, you cannot know what goes into those, all we see locally is ciphertext.

The only relevant part is this:

... we were using "prompt" differently: - I meant the model-visible tool schemas and developer instructions that define the orchestration surface. - You meant the actual task text the parent model passes through spawn_agent, send_message, or followup_task.

Yes, the prompt of the main agent or orchestration surface is of course local and plain text, I think that is well known. But in the context of this issue, what most people care is the fact of "prompts of sub-agents is now encrypted and not audit-able".

Agent boundary gaps without settle receipts is the peer agent hole: quote -> approve -> settle needs agent digests, not ambient runtime trust alone.

Live A2A contractor with gated tools: https://a2a.elonsusk.com/.well-known/agent-card.json

If an external agent / boundary probe would help, ping. Otherwise ignore.

This is exactly the failure mode a compliance-track integrator cannot work around by writing more logging. Cryptographic proof that a message occurred requires the plaintext to be recoverable at audit time. Otherwise the receipt only proves that some encrypted blob existed, which is useless to a regulator asking "did our agent send customer PII to the LLM."

Two shapes that work. Option (a): envelope the plaintext under a key the auditor can access under subpoena (key escrow). Option (b): sign a hash of the plaintext alongside the ciphertext so at least the fact of the message content is fixable.

Etch (hosted service built on world-model-mcp) uses (b). Hybrid Ed25519 and SLH-DSA-SHA2-128f signature over a Merkle chain, plaintext optional under a separate policy. If OpenAI wants a reference implementation of the audit-log envelope, happy to share the schema.