I imagine this will be because a decent chunk of the IP in Codex is probably within its prompts, how they're built, and how they're sequenced and orchestrated, rather than in the codebase per se.
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 quickly reverse engineer a lot of what we're doing.
I'm unable to understand how much value can be in low-definability non deterministic prompts. It feels like the kept the right divinity spell into a chest.
the trick about agentic systems is definitely how to do the prompting. things like automation and sandboxing are trivial in comparisson. if you generally ask via API model directly you can see what basic answers it actually yields and how fine tuning prompts and refinements to output as well as adversarial prompts etc are important to get relatively solid results.
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 )
It's also not the first time Codex started encrypting stuff. Their excellent compaction endpoint has served up a giant encrypted blob since at least five months ago.
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 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.
I'm well aware of what the official propaganda states but this is simply not a fair characterization of reality.
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.
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.
It is not misleading, quite literally what's happening is that content the agent sends sub-agents is encrypted in such a way that only OpenAIs backend can decrypt it and actually see the clear-text. Just shared this is another comment that hopefully explains things better:
> 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!
Not everything is encrypted though, session data (even from the sub-agent) remains unencrypted, only select things like the prompt the (main) agent sends the sub-agent is encrypted, rest of communication between the two seems still to be plain-text.
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 :)
Agreed, I immediately thought that homomorphic encryption was at play here or some other kind of computation on ciphertext, given the mention of "inferencing" in the title.
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.
> I wonder if they are gonna stop us from using gpt subscriptions in alternative harnesses
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...
Everything I do with codex is managed via Forgejo comments, issues and PRs basically. I have a tiny little Rust "conductor" that integrates with app-server and does things when issues/PRs are labeled, when I write comments on PR lines and so on, and those interactions all fire of Codex sessions that are run via Codex's app-server and lead to different outcomes.
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.
At least the local models they put out are pretty good for their weight class. Could be worse, could be releasing the same amount of local models as Anthropic.
Google has the benefit of billions of devices in the wild that they control. Anthropic really doesn’t have distribution for local models, makes sense they’re not playing in that space.
Doubt they will do it as long as Anthropic is leading in business adoption. If they become the top dog with a good lead, all bets are off. Hopefully by the time open models will be even better than gpt-5.6 sol xD.
Personally I use both, pi serves as a "personal assistant" with lots of extensions and changes made for those things specifically, and codex is for anything related to coding itself.
Could someone explain to me where exactly the encryption is happening?
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?
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.
Gotcha and thank you! So the encryption is happening on the OpenAI backend and the agent's clear-text output designated to the sub-agent never reaches local.
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 :(
Quite obviously they're afraid of letting other providers see how they handle the whole multi-agent management stuff. Pretty terrible implementation though, which makes it impossible to use the multi-agent stuff as a paying user, as you have zero recourse in figuring out what went wrong, when something inevitably goes wrong.
The title is a bit confusing, they're not using ciphertext for inference – they're passing ciphertext around in cases where an agent calls into another agent without exposing the plaintext to the end-user
Inference is still done in plaintext after this multi-agent message gets decrypted in the server side
> but also store data and sell to whoever is training
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.)
Some workplace code base are legally not supposed to be shared.
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.
When you work on proprietary code with a lot of trade secrets contained in it, on a codebase that did cost millions of dollars of man-hours to build and that holds the company's IP, you tend to be very careful where you're sending that to.
How do you know that they don't train their models or append your prompts to add backdoors, or compromise your supply chain by including evil dependencies? This seems hugely irresponsible.
> How do you know that they don't train their models or append your prompts to add backdoors, or compromise your supply chain by including evil dependencies?
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.
Yeah. I don't see the problem with Chinese prompt stealing proxies, if it's just pure free choice and discount for explicitly insecure use cases, especially when the frontier providers they route to are soft-assumed to be doing something similar.
If we're viewing this as a _bad_ thing, I don't really see that it is any different than how Claude encrypts it's thinking. Take a peek at your ~/.claude jsonl files. You're sending thinking ciphertext back and forth to Anthropic. Presumably the thinking is either considered proprietary, or, more likely, leaks embarrassing or confidential information.
> I don't really see that it is any different than how Claude encrypts it's thinking. Take a peek at your ~/.claude jsonl files. You're sending thinking ciphertext back and forth to Anthropic.
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...
I guess this implies that non-Codex harnesses get a little bit worse? In wondering what's so special about their subagents system that they feel the need to hide these messages...
Sol and Terra seems specifically post-trained to handle multi-agent orchestration, I'm guessing OpenAI feels like the trained data of when to do the spawning and what context to include for the new sub-agent is the magic in their new models, so that's what they're aiming to preserve. But, this is all a guess of course.
Right I saw them saying something along the lines of "they're good at subagents". But this seems true even with third party harnesses. So I'm wondering what Codex is hiding.
The only thing I've found impacting this, is when you specifically use the "Ultra" thinking/reasoning effort, then codex adds a small part to the system prompt to further get the model to use sub-agents. Any other reasoning/thinking effort than "Ultra" and this piece is no longer in the system prompt.
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.
Seems fairly obvious what the point from OpenAI's side is (protect what they see as the moat, that a model is "good at spawning sub-agents"), but what's really strange to me is that the team somehow didn't manage to push back on this, it's so clearly disadvantageous to developers who are trying to rely on Codex for real work. For this we need introspection into what exactly is going on, hiding the prompts is just so backwards from what I expect from OpenAI.
> protect what they see as the moat, that a model is "good at spawning sub-agents"
Yes, that is the obvious answer, of course. I was looking for an explanation as to why that would be so special now. They used to not do it until Codex is open source after all. Agent prompts more generally are also not encrypted. This particular change just looks unintuitive to me.
They must think they have some secret sauce they don't want others to learn. How to optimally instruct sub agents for example. If they hide the sub agent prompts, other models cannot be trained to emulate.
Oh and you can't even use local models or other providers for the sub-agents. You're locked-in.
Using ciphertext for inference would mean it's not a very secure ciphertext.
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.
> Using ciphertext for inference would mean it's not a very secure ciphertext.
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.
They’re not using ciphertext in inference. They are encrypting agent responses on their servers if it’s going to a subagent on the client. The subagent will send it back to their servers for inference.
Only their servers have the keys, so they can decrypt when running inference.
The idea of homomorphic encryption is to do things without the knowledge, and not gaining the knowledge. If ciphertext contains a number, and you don't need to know what number it does to always be able to multiply it by 2, you succeeded - as a simple example.
It still just sounds like fancy obfuscation to me. I've read alot of examples trying to understand but I can't get past that being able to run processes on ciphertext in a way you can learn something doesn't make sense without me changing my definition of what I think encryption means.
> Is it mainly about how the main/orchestrator agent communicates with its subagents ?
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.
No normative opinion on whether this is justified or not, but noting that this is only for parent -> subagent spawns/messages, and only for the `multi_agent_v2` feature (currently experimental / off by default).
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.
> and only for the `multi_agent_v2` feature (currently experimental / off by default).
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.
Couldn't you just instruct the model to always use your tool call to spawn subagents? Subagents are not some magical thing; it's just another prompt with a couple tool calls for plumbing. One of my colleagues made his own subagent harness earlier this year before codex had them at all.
Ok, so help me get this right: I ask the LLM for something, it generates prompts for sub-agents and sends them back to my client for it to call the sub-agents. Now, those sub-agent prompts are encrypted messages that the sub-agents will decrypt (by hitting a backend) to do their work.
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)
> sub-agents will decrypt (by hitting a backend) to do their work
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"]
They always talk about transparency and all but it never was as opaque as it is going on now.
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...
This is very obviously a countermeasure against distillers, illicit resellers, and the like. The scale and competence of the Chinese black (grey?) market has become a serious threat that can’t be ignored.
It's to prevent collection of queries from users that are coming from resellers/proxies, for reasons of economy or bypassing region blocks etc. The users are using the stock client and may believe they are using direct OpenAI servers.
When I say things like that, I'm talking about a hypothetical version that would be computationally possible. I'm not talking about using today's homomorphic encryption.
Apple's Private Cloud Compute is E2EE between the client and the attested node. Not sure if anyone else is legitimately doing that -- Apple has definitely gone the furthest in terms of verifiably ensuring that requests and responses are not misusable by Apple.
edit: originally was "Codex starts encrypting prompts, uses cyphertext for inference instead"
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 quickly 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.
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!
"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.
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 :)
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...
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.
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...
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 :(
Inference is still done in plaintext after this multi-agent message gets decrypted in the server side
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.)
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.
Source: I work on such code. We don't allow devs to use (cloud-based) LLMs.
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 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.
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.
Yes, that is the obvious answer, of course. I was looking for an explanation as to why that would be so special now. They used to not do it until Codex is open source after all. Agent prompts more generally are also not encrypted. 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.
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.
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.
Unless you are a participant of the computation and you have the key, that is.
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.
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)
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"]
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"