Codex starts encrypting sub-agent prompts(github.com) |
Codex starts encrypting sub-agent prompts(github.com) |
Specifically, I use Opus and others for subagent execution to get alloyed properties on the workflow, and as far as I can tell, that's not affected.
Presumably, this is to hide optimizations they might be making to their own subagent processing, but that's a losing, dumb battle to fight, and misses the forest for the trees.
Obviously it doesn't, how even could it? Read the issue description, it wouldn't make sense if something like that was possible, considering how it was implemented...
Obviously, I wasn't claiming that it would WORK for cross-model subagents, but that this would be a limiting behavior requiring use of the Codex harness to operate if this was paired with model-level limitations on using specific tools to spawn sub-agents.
Or maybe not so obvious to you.
Might as well just stuff the prompts in a database and only hand back the primary key to the client to hand off to the sub-agents. Keeps the same “data security” without the overhead of encryption (especially since encryption and decryption are happening in the same domain)
There is no possible audit trail. No possible way to review what happened to validate the result. But even worse, no you will be billed somehow randomly. 20 sub agents started to do something we don't know. No way to now if it was legitimate, if it is just burning tokens or agents doing the same work on loop...
Edit: F really misunderstood the change, the title is misleading AF. I should have read the post before commenting lmao.
Absolutely hate it, now I guess... sigh..
Incase the title gets changed it used to say, "Codex starts encrypting prompts, uses ciphertext for inference instead"
Your local harness never decrypts the prompt, and only the OpenAI backend does. Your harness still sees tool calls in the transcript so it can act, but you lose (some) visibility as to why the subagent chooses to do so.
Imagine seeing this transcript during forensics:
[encrypted blob][thinking summary: I need to drop the prod database][shell: psql "drop database users"]
It literally cannot.
> Obviously, I wasn't claiming that it would WORK for cross-model subagents
I know, but you were questioning (before investigating) if maybe it did, which I'm saying should have been obvious it wouldn't, if you had understand how this was encrypted.
> requiring use of the Codex harness to operate
Yes, if you want to use Sol + Ultra + sub-agents, you'd need to use the endpoints provided by OpenAI, as (again), the content is encrypted on OpenAI's side, it's not technically possible for other platforms to implement OpenAI's encryption.
And of course this doesn't impact anyone else not using Codex + Sol + Ultra + launching subagents, it's the specific combination that is "protected", not the individual pieces.
This is a really interesting engineering decision, I wonder how many people will want an encrypted external piece of instructions running on their machine.
It's not as if the tech lords have been training people to believe that them having impossible to inspect encrypted channels from your machines to theirs is a best practice for security and your privacy or anything.
training people to believe that them having impossible to inspect encrypted channels from
your machines to theirs is a best practice
Is this user-hostile? Encrypting stuff from the user is what RIAA used to do with DRM, worried about copyright infringement.
And just as I was considering subscribing.
Fuck these companies. Pulling the ladder up.
If I could donate to GLM, I would.
edit: originally was "Codex starts encrypting prompts, uses cyphertext for inference instead"
It seems possible they trained this by doing full RL rollouts of agents interacting with each other. They likely view these prompts somewhat the same as raw reasoning traces, they don't want people to train directly on them.
I am unsure if this has been confirmed, but there are some signs that the opaque "compaction blob" they return from their dedicated compaction endpoint might not be text at all, rather a latent space representation of the conversation. The fact that OpenAIs compaction seems to be much higher fidelity than a lot of other providers makes me inclined to believe this.
If this is true, it doesn't seem far fetched to infer that they might be applying similar techniques to prompting subagents.
I would be curious to see if this way of spawning subagents (encrypted blob) is used when subagents of a different model type is spawned.
I Imagine next that programming languages, interfaces and API design starts going this direction next. Being written, expressed and optimized as blobs of high dimensional vector space. As humans we might still be able to understand some abstractions of what our AI's are talking about to each other, but maybe not more so then we understand how different regions of our own brain communicate with each other.
Hopefully they can add that.
If you keep RL'ing the dispatch then the prompts are likely to keep diverging from the type of prompt a person would write (like CoT becoming increasingly incomprehensible), and that divergence is part of their competitive advantage.
> rather a latent space representation of the conversation
Student/teacher models derived from the same checkpoint convey a lot of latent information through token choice, as in: https://techxplore.com/news/2026-04-ai-chatbot-student-owls....
I wonder if this is something they can take advantage of by training on compaction inside of the RLVR loop?
and how would you load that back into the model? they are token-in, token-out, plus the KV-cache which is derived from token-in
I've gone in to look at Claude subagent/workflows and sometimes been like "no this was a mistake to spin up" ... Codex users just get to token yolo the encrypted telephone operator instructions+shell from orchestrator to subagents?
It makes more sense when you realize they don't want developers to be doing any coding at all. That's what they seem to be moving towards. From product manager to product via AI.
We had this discussion a few months ago where we talked about allowing people to choose an AI provider and provide their API key, thinking about enterprises with "preferred" (read: mandated) AI suppliers. We also wanted to offer the kind of very simple pricing that this is one way of enabling. But we realised pretty quickly that this would/could lead to leaking our back end prompts to customers and, although those prompts are only a part of the value add, if you could build a detailed trace of them then you'd be able to relatively easily reverse engineer a lot of what we're doing.
So we quickly dropped that idea.
a lot of expertise of certain domains' workflows is needed to make it functional within that domain. some of this can be yielded via prompting too etc so its also baoance of how much to prompt it vs. how much of it you wanna let it reason over itself. (if you tell it too much i lock it into a path and if you tell too little it will give incomplete results )
With chat completion, the reasoning process is entirely under your control. You can build a reasoning agent that uses custom MCTS techniques with GPT5.6 models today if you are willing to get your hands just a little bit dirty. You have to enable experimental flags and set options in slightly confusing ways, but it still works.
You can use models up to gpt5.5 with custom API tokens and model configuration in VS Copilot. gpt5.6 family (currently) no longer work in this setup. Presumably, because we aren't explicitly forcing reasoning_effort to none to satisfy the new moat expansion behavior.
what does that mean?
> the reasoning process is entirely under your control
you're still dealing with summarised thinking, no, which is kinda useless as it's way too high level?
The thing you’re gesturing at isn’t mcts in any real sense
Responses integration will lock you into OAI much more deeply than chat completion integration will. I can easily swap my inference provider right now. The business is not interested in a form of integration that is difficult to swap.
> Sure. "Traditionally", your agent would send a text prompt to the sub-agent, then it goes off doing it's work. In the logs/session data, the clear-text prompt would be there, so if I want to see what's happening, I just browse the data. It's all just clear-text prompts being sent everywhere, even when you were using the experimental "sub-agents" stuff in Codex, before Sol et al was available.
> Now, when using Sol or Terra (Luna seems unaffected), instead of the agent sending clear-text prompt to the sub-agent, it sends a ciphertext generated on OpenAIs backend, which ends up being the prompt, then agent sends this ciphertext to the sub-agent, which then continues to use that for further inference to OpenAIs backend. Only delegated inter-agent messages are encrypted, not all session data. Now if you browse the data, it's all encrypted content, that can only be decrypted by OpenAI and their backend.
Edit: Re-reading, I think I understand what you mean to be misleading. You're taking "uses ciphertext for inference" quite literally, while I couldn't fit a more nuanced version within the HN title constraints. Yes, the inference at OpenAI obviously doesn't happen over the ciphertext, but from the perspective of the local user, you don't see the clear-text prompt at all, only the ciphertext.
But, please suggest alternative titles that sufficiently explain what the issue is and is more accurate, I'm sure the mods can change it once people come up with better alternatives :)
Edit2: I've updated the title from "Codex starts encrypting prompts, uses ciphertext for inference instead" to "Codex starts encrypting sub-agent prompts", hopefully it's clearer now!
Need an human-readable, concise but accurate audit trail message like the PR suggests.
Encryption is useful to at least stop the latter.
Ultimately same purpose as a\ ‘s trick exposed earlier, but a much nicer implementation.
I see this as an argument against using them/Chinese models all the time, but I don't get it. I totally understand wanting to keep your data private if you're using an LLM for personal chats. But coding? I'm not working for the military, I'd gladly donate my codebase to Chinese labs if that means they can keep releasing 6-months-behind level models for 100x cheaper.
(I understand why OpenAI doesn't want this and would implement protections. I'm talking about people using this as an argument for why you as an end user shouldn't use those services.)
I wonder if there was any safeguard failure due to loss of visibility into what the sub-agent was trying to do?
I assumed that the main agent makes calls to sub-agents locally. Does Codex work in such a way where the main agent makes calls to sub-agents in the backend (openai server) before reaching local?
Now, when using Sol or Terra (Luna seems unaffected), instead of the agent sending clear-text prompt to the sub-agent, it sends a ciphertext generated on OpenAIs backend, which ends up being the prompt, then agent sends this ciphertext to the sub-agent, which then continues to use that for further inference to OpenAIs backend. Only delegated inter-agent messages are encrypted, not all session data. Now if you browse the data, it's all encrypted content, that can only be decrypted by OpenAI and their backend.
Which is a real problem since you can't intercept/monkey patch the ciphertext to decrypt it locally to be able see the clear-text since we don't have the encryption key/algo/salt. No hacking :(
I was already only using Claude Code to double-check if it's getting better than Codex, but with things like this, it really isn't even an alternative. What's the point of using a reasoning model if you as an end-user can't seen the reasoning? I don't think I'd be able to work like that at all, I need to have introspection into what the model is doing, and can't believe I have to say this, but also need to be able to see the plaintext of the input prompt...
At least Anthropic doesn't pretend that they have open source software in the form of Claude Code.
They're only encrypting thinking because AI is so dangerous and only they can be trusted to be in control of AGI.
This happens to align with lining their pockets as well.
Inference is still done in plaintext after this multi-agent message gets decrypted in the server side
The only way these AI labs can get the app layer lock-in they need is if they can get customers used to writing them a blank check: “here, take my data and my system, do ‘stuff’ and bill me for it.”
Between this and the recent Grok upload breach, I consider these products radioactive.
These two ideas don't compute for me.
Same thing with homomorphic encryption. I don't get it. If you can gain any knowledge from a ciphertext, you just found a way to exploit the ciphertext to me.
Yes, that is the obvious answer. I was looking for an explanation as to why and why now. Codex is open source after all. They used to not do it. Agent prompts more generally are also not encrypted, and continue to be.
This particular change just looks unintuitive to me.
Oh and you can't even use local models or other providers for the sub-agents. You're locked-in.
If desired the user can always see what the sub agent is doing in detail ?
Isn't it the same in case of claude as well ?
Yes
> If desired the user can always see what the sub agent is doing in detail ?
Well, no, that's the problem, you're currently not allowed nor is it even possible, to see the exact prompt the main agent sent the sub agent. This is the problem.
> Isn't it the same in case of claude as well ?
No idea, but if Claude Code makes it so it's impossible to inspect what the sub-agents actually received before they started their work, then I'll say it's similarly impossible to rely on Claude Code if so.
Notably, subagent output is still in plaintext.
EDIT: Title was now clarified. But wanted to expand that this is actually enabled for 5.6 Ultra it appears, which does subagent orchestration more natively in the API rather than direct tool calls; they are beginning to treat subagents as similar to chain-of-thought traces (already encrypted) rather than traditional tool calls.
Wrong, this is enabled by default for Sol and Terra (not Luna), no way of avoiding this short of patching the client yourself, and that still doesn't make the backend endpoints work, they want the ciphertext that OpenAI creates on their side.
> but noting that this is only for parent -> subagent spawns/messages
This is almost fully correct though, the encryption only seems to be for the initial prompt the main model sends the sub-agent, not all communication and not regarding the state of the sub-agent at all.
So you can inspect what the sub-agent is doing currently, and the output, but you cannot see what the initial prompt the sub-agent got started with.
"Codex starts encrypting prompts, uses ciphertext for inference instead"
to just
"Codex starts encrypting prompts"
That is enough.
Maybe you could say sub agent prompts. The article can say the rest.
Probably not, the whole app-server machinery is there to facilitate that thing, would be a huge piece to rip out of codex. This is basically the reason I end up using codex the most, as it's the easiest to integrate against, with the app-server's RPC API making it really trivial.
Besides, most of my codex usage at this point is all through custom integrations I've built using Codex's app-server, not the Codex TUI they publish. I'm sure I'm not alone in this.
But, if they suddenly start to encrypt content on our disk, so only their backends can see it, and those things are prompts and other things that are actual inputs to the inference, then who cares if it's easy to integrate against, it becomes impossible to figure out what the fuck is going on, I can't understand how the team thought this was a good idea...
If they go down that path I'll just go back to my old buddy Claude, or maybe buy a second Spark and keep it local.
https://github.com/openai/codex/blob/main/codex-rs/responses...
Inference is done in plain text. It's just that some parts of the response can be encrypted. While I haven't looked into this specific implementation, here's a short "how I'd do it" if I wanted to implement this:
Before:
[] - encrypted {} - plain text
1. user -> please do this -> server
2. user <- a) [thinking1] encrypted; b) {answer1} plain text <- server
3. user -> please do this -> [thinking1] (sent encrypted as received) -> {answer1} -> good but do this instead -> server
4. user <- [...] <- [thinking2] ; {answer2}
(here the server decrypts the thinking parts, adds them to the conversation, does the inference, and sends back the new thinking trace (encrypted as well) and the new answer
After:
1. user -> please do this long task -> server
2. user <- [thinking1] ; {tool_agent_spawn([params1])} ; {answer1} (e.g. would you like me to explore or do a quick hack?) <- server
3. user -> please do this long task -> (decides if explore or message) spawn([params1]) / message -> server
3. a) if no explore -> send message as usual 3. b) if explore execute spawn that in turns begins 2 channels
4. user <- [channel_1_thinking] ; {channel_1_answer} ; [channel_2_thinking] ; {channel_2_answer} ... <- server
So the server always does inference on plain text. But it sends the "important" bits encrypted, and you only send those back if you as the user want to (or need to, or choose to, etc). The idea is that the client still gets to decide on "local" things, but the server keeps the important bits from reaching the client. In this particular case, the [params] are encrypted bits that can include prompts, etc.
Regardless, I've updated the title from "Codex starts encrypting prompts, uses ciphertext for inference instead" to "Codex starts encrypting sub-agent prompts", hope this makes it clearer for everyone :)
Internet Explorer?
Add? Just make the sub-agents input prompt not encrypted, literally change "encrypted: true" to "encrypted: false" everywhere and everything continues to work as it used to.
They need to fix the regression, not add something new here.
zero-graph v1
origin source-text
module "hello"
hash "graph:a7f7e6899a73f3b4"
node #decl_ad8d9028 Function name:"main" type:"Void" public:true fallible:true
node #param_4610ae76 Param name:"world" type:"World"
node #expr_c403020c MethodCall name:"write" type:"Void"
node #expr_653eeb6e Literal type:"String" value:"hello from zero\n"
edge #expr_c403020c arg #expr_653eeb6e order:0
Even for like token efficiency it could make sense - like imagine if the representation were more compact
Agents acn already translate languages quite well. It doesn't seem crazy that they could work and think in a model specific language, and then translate back to English or something for the user
I actually built such a language: https://magarshak.com/U.html
it reminds me of the pre-vulkan game programming days.. drivers were black boxes, game developpers had to resort to magic tricks to do stuff, until everybody got fed up and wanted some logical ground to operate
One does find oneself slightly askance at one's own thinking sometimes, that's for sure.
But I suppose, is it really so different? I mean, back in the day moreso than now, a lot of the valuable IP in any system was in the design and specification of that system - the problems usually solved within the design and specificaion (use X algorithm, etc.) - and the code was "just" the implementation of those solutions.
So perhaps it's more of a regression in some ways: the value is in the specification (the prompt) once again.
Your point about stochastic behaviour is well made though, and there is no way to 100% guarantee or formally verify the behaviour of a system that relies on an underlying technology whose behaviour is fundamentally stochastic.
In an ideal world this would have been public tech like ARPANET or WWW and there would have been 2-3 major iterations (until the equivalent of Claude 7-8) and only then would everyone have tried to build huge businesses on top of it.
I mean, sure, it's sort of usable, but the churn is insane. And we're burning the planet (and probably the economy, too) for it.
When was the last time you used an LLM to evaluate how true those last part(s) still are?
I also love how you went from "I'm unable to understand" to "This is surely right", it's a good representation of the software ecosystem at large :)
I was about to do the same with Sol + Ultra, but then discovered this encryption issue that prevents me from doing the same for sub-agents.
Personally I do, these tools aren't mature enough to be used without supervision
It sort of feels like an area of friction even still.
I already switched to a Chinese provider personally, I don't think the difference between both really justifies the wide gap in pricing
Source: I work on such code. We don't allow devs to use (cloud-based) LLMs.
More importantly, they train on not only code but also your interactions with the model, no matter how little you value your labor, there are values in it.
I think most of these discussions aren't about irresponsible vibe-coders, as that whole thing is mostly a fun joke more than something serious. The rest of developers who use LLMs for development, review the code the agent writes, iterates and makes changes. Think more like pair-programming, than "Write me X then deploy to production".
I know Twitter makes it seem like everyone is doing vibe-coding and YOLOing podman images into production, but it's very uncommon in a serious/production environment to act like that. While a proper structure doesn't make it impossible for the LLMs to add backdoors either via dependencies or otherwise, but it sure makes it a lot harder.
Personally, LLMs are barely able to work alongside developers and not miss anything, I wouldn't be so worried about them being able to do normal work + malicious work at the same time, as they barely handle the first part properly yet.
I read the code.
Seemingly mostly a prompting thing it seems on the surface. GPT-5.5 (and maybe even GPT-5.4) already had (experimental?) support for sub-agents, remember using it even with -spark which I think was launched together with GPT-5.4 if I remember correctly, so this whole "use sub-agents" stuff most have been part of the training data for quite some time already, but maybe they've mainly been iterating on the prompt themselves since then.
Beats having to parse output from CLI-runs and so on. Initially this environment was running aider (which feels like years ago), was running Claude (parsing stdout) at one point but using Codex's app-server since some weeks/months back and is a lot simpler implemented now.
Unless you are a participant of the computation and you have the key, that is.
I don't see a way to make it a open standard. The processing steps would need to be part of the key.
Anyway If someone figured it out I would be very interested to be sure they weren't just trying to slap a it's encrypted to meet some standards required. And..also, what amount of data processing does Alice need to do that required outsourcing to Bobs machines. Data processing and anaysis is cheap.