Live data from Hacker News

Codex starts encrypting sub-agent prompts

github.com

91–100 of 272 posts

Re: Codex starts encrypting sub-agent prompts

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

Re: Codex starts encrypting sub-agent prompts

#94

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 3. user -> please do this -> [thinking1] (sent encrypted as received) -> {answer1} -> good but do this instead -> server

4. user (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 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 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.

Re: Codex starts encrypting sub-agent prompts

#95

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 t…

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

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.

Re: Codex starts encrypting sub-agent prompts

#96
post #86

Earlier quoted context omitted.

> 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 cheape…

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.

Re: Codex starts encrypting sub-agent prompts

#97

Earlier quoted context omitted.

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

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

> 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"]

Re: Codex starts encrypting sub-agent prompts

#98
post #34

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"

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.

Re: Codex starts encrypting sub-agent prompts

#99
post #93

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…

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

Re: Codex starts encrypting sub-agent prompts

#100
post #93

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…

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

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.

Post reply on HN