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 :(
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...
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.
> 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.)
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.
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
> 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.
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.
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.
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.
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.
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.
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!
I would change
"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.
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 :)
Seconded can we change pls.
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.
My bad, fixed now, please do refresh and try with latest updated IE if you still don't see the changes.
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"
What's the idea here? Why does this seem important to OpenAI?
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...
What are some of the things you’re doing with the Codex app-server?
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.
Anthropic and Google already charge extra to use your own harness. That's 100% of the reason I'm using OpenAI.
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.
Well, my backup plan is GLM. Cheap and not that bad really.
Google is really not distinguishing itself. Even the hosted inference sucks.
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.
Sure, lots of differences. Point stands, they're distinguishing themselves in that way at least.
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.
It could also be the case that by the time business adoption picks up a lot they might not be as compute constrained. Depends on rate of growth.
Given that codex itself now ships a proxy that wraps the subscription, it seems unlikely
https://github.com/openai/codex/blob/main/codex-rs/responses...
"remarkably unremarkable harness" is why I like it so much.
I don't, feel better with Pi with a custom set of extensions.
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 :(
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...
I assume this is mostly to frustrate efforts to proxy large numbers of user requests and responses and use it to train competitor models.
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.
Ah I was wondering why the Chinese black market resellers stopped working yesterday, I guess that's it
This is the reason I think. These black markets not only pool and resell subs, but also store data and sell to whoever is training.
Encryption is useful to at least stop the latter.
Ultimately same purpose as a\ ‘s trick exposed earlier, but a much nicer implementation.
> 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.)
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.
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
Is it mainly about how the main/orchestrator agent communicates with its subagents ?
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 ?
> 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.
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.
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.
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.
“Starts”? How’s this not already a TLS connection?
The prompts are now encrypted, not just the transit connections...
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.
Then why to even keep codex open source?
what does that have to do with anything?
~~Finally someone doing it correctly. Love this change.~~
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"
How so?
I assume OP interpreted it as encryption that hides the prompts from OpenAI rather than OpenAI hiding information from users.
I'd be all for homomorphic encryption on inference, but as you say, this is probably mostly to prevent end users from observing intermediate results.
Homomorphic encryption for LLMs is extremely expensive and nowhere near computationally possible for the scale of current LLMs.
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.
ooooooof yeah totally misinterpreted it lmao
to be fair, the title is very misleading, it took me a minute to understand what they meant
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.