Codex Sub-Agent Prompts Are Encrypted: Why That Breaks Multi-Agent Debugging
Codex sub-agent prompts are becoming a real debugging problem. If you are searching for Codex multi-agent debugging, encrypted prompts, or why you cannot see what a sub-agent was told, the short answer is brutal: the delivery path can preserve ciphertext while the local history loses the readable task.
That is not observability. It is a black box with a progress bar.
A currently open Codex issue reports that MultiAgentV2 encrypts the payloads for spawn_agent, send_message, and followup_task. The issue says the readable content field is left empty while encrypted_content carries the message. The result: a human reviewing a rollout can see that delegation happened, but not necessarily what the parent agent actually delegated.
What is happening to Codex sub-agent prompts?
First, kill the misleading interpretation: this is not inference over homomorphic encryption. The Hacker News discussion correctly distinguishes encrypted transport/storage of an inter-agent message from model inference on ciphertext. The reported concern is narrower and more operationally dangerous:
- A parent agent delegates work.
- The delegated message is represented as encrypted content.
- Local rollout, replay, and audit surfaces no longer have readable task text.
- An engineer gets a failed result and cannot answer the first incident-response question: what was the agent asked to do?
The issue traces the behavior to the MultiAgentV2 protocol and handlers, and identifies the affected actions as spawn_agent, send_message, and followup_task. It describes the change as appearing in builds after the MultiAgentV2 encryption work, with MultiAgentV2 enabled.
Why encrypted prompts break Codex multi-agent debugging
Encryption is not the bug. Deleting—or failing to persist—the operator-visible audit record is the bug.
A multi-agent system is a distributed system with more randomness and worse postmortems. You need to inspect the delegation edge, not just the final node output. Otherwise these routine questions become guesswork:
- Did the planner give the reviewer the right repository, constraints, and acceptance criteria?
- Did a follow-up overwrite the original task or target the wrong agent?
- Did the worker fail because of its tools, its context, or a malformed task?
- Can you reproduce the failure after the model, tool schema, or prompt changes?
Without the delegated task, you cannot distinguish a bad plan from a bad execution. You have telemetry-shaped theater.
The issue reports that users of a current model path may be forced onto v2 behavior despite a configuration intended to disable it; treat that as an unverified environment-specific report, not a universal guarantee. But it highlights the real engineering risk: observability cannot be an accidental feature flag when the workflow depends on delegation.
The right design: encrypted delivery, readable local audit
The fix is not “send everything in plaintext.” It is a dual-record contract:
recipient delivery record
encrypted_message: ciphertext
local audit record
task_message: bounded plaintext
parent_agent_id: ...
child_agent_id: ...
correlation_id: ...
timestamp: ...
The child receives the encrypted delivery payload. The operator gets a separate, bounded plaintext audit copy in the local rollout and trace. Do not use plaintext equality for message correlation; use a message ID or ciphertext-derived identity. Do not silently substitute ciphertext into a UI field labeled as readable content.
That pattern gives you both properties that matter:
- Confidentiality boundary: the recipient-facing path stays encrypted.
- Operational accountability: the owner of the workflow can inspect what their system delegated.
The issue proposes precisely this shape: retain encrypted delivery, add a plaintext audit companion, validate that it is non-empty, and persist it through rollout/history/trace surfaces. It also links to a prototype for the spawn_agent half of the change.
How to run observable multi-agent systems today
Until your framework proves its audit behavior, build the audit edge yourself.
1. Record delegation before dispatch
Write an immutable event before a task crosses an agent boundary:
{
"event": "agent.delegated",
"run_id": "run_8f2c",
"parent": "planner",
"child": "reviewer",
"task_id": "task_184",
"task_text": "Review the migration for data-loss risks.",
"task_sha256": "...",
"created_at": "2026-07-14T12:00:00Z"
}
Redact secrets. Bound the payload. Keep the record in the same retention and access-control domain as the rest of your run data. But record it.
2. Make task IDs first-class
Every sub-agent result should point back to the exact delegated task ID. “Reviewer completed” is useless. “Reviewer completed task_184, produced commit abc123, and consumed tool calls X/Y/Z” is debuggable.
3. Test the trace, not just the answer
Your integration test should assert all of the following:
- The child receives the intended task.
- The parent trace contains a readable, authorized audit record.
- The recipient-facing history does not leak that audit record where it should not.
- Replay preserves the task/result relationship.
If the only assertion is “the model produced a plausible final answer,” you are testing a demo—not a system.
4. Treat hidden delegation as a release blocker
Do not ship a workflow where a production incident can end with “we do not know what instructions the worker received.” That is a release-blocking observability defect, especially for coding agents that can modify repositories, run migrations, or trigger deploys.
The sharper point
Agent vendors want you to think of delegation as a product feature: spawn more workers, get more throughput. Engineers should treat it as a trace topology problem. Every delegation is a causality edge. If you obscure that edge, you erase the evidence needed to debug, evaluate, and trust the system.
Codex can encrypt sub-agent delivery and still provide a proper local audit trail. Those are not competing goals. The implementation reported in the issue already sketches the contract: separate encrypted delivery from bounded plaintext audit metadata.
Anything less is not privacy engineering. It is outsourced observability.
Top comments (0)