The editorial argues that shipping an undocumented encryption change with no opt-out silently broke the OpenTelemetry wrappers and JSONL trace pipelines developers built around Codex. It frames the move as a trust posture rather than a security one — users can no longer verify what their own agent is instructing sub-agents to do.
The original issue reporter surfaced that recent Codex CLI versions replaced plaintext sub-agent prompts with opaque blobs after a routine npm update. They highlight that the change was undocumented and undermines local logging wrappers that treat prompt visibility as the whole point of using an open CLI.
The editorial acknowledges that end-to-end encrypting orchestrator-to-worker instructions is a defensible design goal because prompt-injection-via-tool-output is a real and embarrassing failure mode of agent frameworks. Making sub-agent instructions tamper-evident closes a genuine attack surface, even if the delivery of the change was poor.
The editorial notes the HN thread is unusually pointed because the loudest voices are running Codex in evaluation harnesses, enterprise pilots, and security-review pipelines. For these users, inspecting every sub-agent instruction is a compliance and auditing requirement, not a nice-to-have — so an opaque blob is functionally a regression.
The editorial emphasizes that the change shipped with no release-note entry, no config flag, and no opt-out — a single npm update silently broke downstream observability. This shipping practice, more than the encryption itself, is what turned a technical decision into a community backlash on Hacker News.
On July 12, a GitHub issue (openai/codex#28058) escalated from a curiosity to the top of Hacker News in a few hours. The report: recent versions of OpenAI's Codex CLI have started encrypting the prompt payloads sent to sub-agents — the internal delegations an orchestrator agent makes when it fans work out to specialized workers. Where users previously saw the plaintext instruction ("read this file, summarize the function, return JSON with these keys"), they now see an opaque blob.
The change is not documented in the CLI's release notes. It was discovered by developers whose local logging wrappers — the ones piping every model call through OpenTelemetry, or into a homegrown JSONL trace — started emitting garbage where prompts used to be. No feature announcement, no config flag, no opt-out: one `npm update` and the observability layer people built on top of Codex quietly stopped working.
The HN thread (398 points at time of writing) is unusually pointed for a library-level change. The top comments are not from hobbyists — they're from people running Codex in evaluation harnesses, in enterprise pilots, and in security-review pipelines where being able to inspect every sub-agent instruction is the whole point of using an open-tooling CLI in the first place.
The official-ish reasoning circulating in the thread is prompt-injection defense: if a sub-agent's instructions are encrypted end-to-end between the orchestrator and the worker, a malicious tool response can't easily rewrite them mid-flight. That's a real threat model. Prompt-injection-via-tool-output is one of the more embarrassing failure modes of agent frameworks, and "the orchestrator's instructions to the worker are tamper-evident" is a defensible design goal.
But the tradeoff is severe, and it's the tradeoff that has the thread lit up. Encrypting the prompts your own agent sends to itself is not a security posture — it's a trust posture, and it moves trust from the user to the vendor. If I'm running Codex on my laptop, against my repo, with my API key, and I can no longer see what the orchestrator is telling the sub-agent, then Codex has become a black box in a way that `claude -p` and `codex exec` were specifically not supposed to be. The whole pitch of a CLI-based coding agent over a hosted product is that everything happens in the open, in your terminal, with your files.
Compare the alternatives. Anthropic's Claude Code exposes every sub-agent invocation as a visible tool call in the transcript — you can read exactly what a research sub-agent is asked to research. Aider logs every message. Continue.dev's agent mode ships with a debug panel that shows the raw JSON. Even LangGraph, which nobody accuses of being simple, at least lets you subscribe to every intermediate state. The direction of travel across the whole ecosystem has been *toward* transparency, and Codex is now the first major coding agent to move the other way.
The other worry, raised more quietly, is what this does to third-party evals. If you're at an AI safety lab or a big-co red team and your job is to characterize how Codex actually behaves under adversarial conditions — what it delegates, how it decomposes tasks, when it decides to run shell commands — you now need OpenAI's cooperation to see the ground truth. That's a meaningful shift in who can audit what.
If you're using Codex CLI in production — and given the download numbers, a nontrivial number of teams are — three concrete things to do this week.
First, pin your Codex version. Whatever release you were on before the encryption change is the last one where your telemetry works. `npm install -g @openai/codex@
Second, audit whatever you were logging. If your compliance story includes "we log every prompt sent to any model," you probably no longer do, and you may not have noticed. This is the kind of thing that shows up in a SOC 2 review six months late. Check your log samples for ciphertext-looking payloads now, not later.
Third, decide whether Codex is still the right primitive for you. For a lot of teams the answer is still yes — the underlying model is good, the CLI ergonomics are good, and encrypted sub-agent prompts don't matter if you never inspected them anyway. But if you specifically chose an open CLI over a hosted agent product because you wanted the transparency, that reason just got weaker. Claude Code, Aider, and Continue's agent mode are all reasonable places to look, and each of them still shows you exactly what the orchestrator is telling the worker.
The most likely outcome, based on how OpenAI has handled similar backlash before, is a config flag — `--allow-plaintext-subagent-prompts` or something equally awkward — landing in a point release within a couple of weeks. That's fine as far as it goes, but it doesn't fix the underlying pattern: shipping an opaque-by-default change to a tool people had built observability on top of, without a heads-up. The real story here isn't the encryption; it's that a coding CLI silently changed its trust model between minor versions. If you build on any vendor's agent framework, that's worth writing down somewhere your future self will see it.
I was wondering why my local tool to inspect coding agent sessions stopped working in some cases.This is a really interesting engineering decision, I wonder how many people will want an encrypted external piece of instructions running on their machine.
I've been sticking with the chat completion endpoint because of this same behavior. 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. You
I wonder if they are gonna stop us from using gpt subscriptions in alternative harnesses. If not - that doesn't matter much, codex cli is a remarkably unremarkable harness.
HN Title is ( edit: was ) very misleading, it makes it sound like inference is being done directly on ciphertext, which would require homomorphic encryption well advanced of what is known.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
This title is easy to misinterpret. If I understand correctly: Codex now encrypts sub-agent prompts and hides those prompts from the user.edit: originally was "Codex starts encrypting prompts, uses cyphertext for inference instead"