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

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.

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.

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

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.

what does that have to do with anything?

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.

How so?

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.

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.

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.

Seconded can we change pls.

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

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.

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

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

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

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.

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.