Codex starts encrypting sub-agent prompts

It's sort of insane though, you not only have dozens/hundreds of stochastic agents running on your machine, but you cannot even inspect the instructions those agents are working off of?

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 seems likely to me this was driven by the `ultra` mode in 5.6, which fans subagents to do work. This mode was previously only available in the web UI (what was previously known as pro?)

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 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.

So we quickly dropped that idea.

Yeah I thought "wow, some homomorphic encryption* stuff", but then "nah, usual greed".

* https://en.wikipedia.org/wiki/Homomorphic_encryption

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.

responses api provided many benefits over chat completions https://developers.openai.com/api/docs/guides/migrate-to-res.... Any reasoning model which is all the new models these days should use responses as per the recommendation

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!

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.

> 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...

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.

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.

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...

Codex CLI not having a rewind makes it useless to me.

"remarkably unremarkable harness" is why I like it so much.

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.

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.

Interesting. Got a link for this?

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.

> 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...

Claude "encrypting" its thinking is equally bad. Biggest IP thieves in the world worried about IP theft lmao.

At least Anthropic doesn't pretend that they have open source software in the form of Claude Code.

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.

> 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.

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.

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.

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.

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.

> 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.

> 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.

The prompts are now encrypted, not just the transit connections...

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.

what does that have to do with anything?

How so?