Codex now encrypts sub-agent prompts — and breaks your telemetry

4 min read 1 source clear_take
├── "Shipping encryption without a flag or opt-out breaks production observability tooling"
│  ├── top10.dev editorial (top10.dev) → read below

The editorial argues that the change collides head-on with how teams actually operate LLM agents in production — logging everything, diffing prompts across runs, and routing traffic through policy-enforcing gateways. Sub-agent traffic is precisely where tool calls get planned and reasoning happens, so losing visibility there darkens the middleware ecosystem built around inspectable LLM payloads.

│  └── embedding-shape (GitHub Issue #28058, 150 pts) → read

The reporter discovered the change when their local inspection proxy — standard tooling for any serious agent team — stopped returning readable JSON overnight. They filed the issue because the change shipped with no feature flag, no changelog callout, and no documented opt-out, breaking a workflow that had been working reliably.

└── "Encrypting sub-agent prompts is a defensible hardening measure against prompt leakage"
  └── Codex maintainers (GitHub Issue #28058) → read

The maintainers framed the encryption as a security posture to protect prompt contents in transit and at intermediate hops. Their reasoning is that prompts routinely leak through logs, proxies, and third-party middleware, and encrypting the sub-agent channel closes a real exposure surface even if it costs teams some debuggability.

What happened

A GitHub issue filed against `openai/codex` (#28058) surfaced a change that anyone running the Codex CLI behind an inspection proxy noticed within hours: the prompts Codex sends to its sub-agents are now encrypted on the wire. The request bodies going to the sub-agent endpoint are opaque blobs where they used to be readable JSON. The reporter caught it because their local logging proxy — the kind of thing every serious agent team stands up on day one — stopped being useful overnight.

The change shipped without a feature flag, without a changelog callout, and without a documented way to opt out. The maintainers' initial response framed it as a hardening measure to protect prompt contents in transit and at intermediate hops. That is a defensible security posture on paper. In practice, it collides head-on with how teams actually operate LLM agents in production: they log everything, they diff prompts across runs, and they route traffic through gateways that enforce policy on the payload itself.

The scope is narrow — this is prompts sent from the orchestrator to sub-agents, not the top-level user turn — but sub-agent traffic is where the interesting stuff happens. It's where tool calls get planned, where retrieval context gets injected, and where the model's reasoning about the task actually lives. Losing visibility there is losing visibility into the part of the system that matters most for debugging.

Why it matters

Encrypted-by-default sounds unambiguously good until you remember what "observable" means for an agent stack. You can't grep an encrypted payload. You can't run a regex against it in your gateway. You can't build a dashboard that shows the top 20 tool-call patterns your sub-agents produce this week. Every piece of tooling that treats the sub-agent request as inspectable data — the entire middleware ecosystem that has grown up around LLM APIs — is now dark.

The defenders of this move have a real point. Prompts leak. They leak through logs that shouldn't have been retained, through proxies that got compromised, through screenshots pasted into tickets. If Codex is going to be trusted with proprietary code and internal system prompts, wire-level opacity is one of the cheapest defenses available. OpenAI has been on a run of tightening the perimeter around agent execution — this fits the pattern.

The critics have a bigger point. The whole reason teams pick a CLI-based agent runner over a hosted black box is that they want to see what it's doing. Encryption that the operator can't disable isn't a security feature — it's a control transfer. You've moved the trust boundary from your infrastructure to OpenAI's, and the tradeoff wasn't yours to make. Community reaction on the issue reflected that exact split: half the commenters want the encryption on by default with an opt-out, half want it off by default with an opt-in, and almost nobody wants the current shape where the choice doesn't exist.

There's also a supply-chain wrinkle worth flagging. A lot of enterprise Codex deployments sit behind a corporate egress proxy that terminates TLS specifically so security teams can inspect what's leaving the network. Application-layer encryption on top of TLS defeats that entire inspection path. For regulated environments — finance, healthcare, defense — that's not an inconvenience, it's a compliance blocker. Expect procurement conversations to get awkward.

What this means for your stack

If you run Codex in CI or on developer machines with any kind of gateway in front of it, audit your logs today. The change may already be live in the version pinned in your `package.json` or your Nix flake, and the failure mode is silent — your proxy still forwards traffic, it just can't tell you what's in it. Confirm whether your observability stack is degraded before you find out from an incident.

Pin your Codex version and hold it until OpenAI clarifies the opt-out story. Floating on latest was already a bad idea for anything touching a paying customer's data; this is a fresh reason to lock it down. If you were planning a Codex rollout for next quarter, add "middleware compatibility" to your evaluation matrix alongside the usual latency and cost numbers.

For teams building their own agent frameworks, the lesson is architectural. If you want operators to trust you, the observability contract has to be part of the API surface, not something they reverse-engineer from the wire format. Ship a structured event stream — spans, tool calls, reasoning traces — that operators can subscribe to without having to intercept HTTP. LangSmith, Braintrust, and the OpenTelemetry GenAI conventions all point at the same shape. The teams that got there first are the ones this Codex change doesn't hurt.

Looking ahead

The likely resolution is a config flag — probably an environment variable — that lets operators disable the encryption for their own traffic. OpenAI has walked back similar surprise defaults before when the community pushed hard enough, and the issue thread has enough weight behind it that a response is coming. The broader trend is clearer than the specific fix: agent runtimes are quietly becoming closed boxes, and the window for building your observability on request-body inspection is closing fast. Move your instrumentation up the stack now, or plan to keep fighting this fight every time a vendor tightens the screws.

Hacker News 398 pts 234 comments

Codex starts encrypting sub-agent prompts

→ read on Hacker News

// share this

// get daily digest

Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.