We managed to generate probably-correct code, which can then be probably-corrected recursively to get to something that runs (usually).

This made everyone scream and lose their minds saying that code is finished, people think they don't need a technical cofounder anymore, think they don't need engineers anymore, etc. Then they're, at varying speeds, finding out they're wrong.

It seems oddly circular to me that the _exact hubris_ non-engineers have long accused engineers of - and we have indeed been too often guilty of - they themselves turn out to be JUST as guilty of! Just like engineers thought all sales did was bother people, and all marketing did was send emails, and all support did was tell people to turn it off and on again, and all product did was copy google... they all apparently thought all engineers did was tik-tak-click-clack type code all day and when it compiled it was done. Not knowing how much higher-order... well, engineering, there is to it.

Where are all the CTOs during all of this? I thought someone was supposed to be sticking up for their org? Sales, marketing, etc all seem to have entrenched C-suite people keeping their fiefdoms resistant to erosion by outsourcing, downsizing, etc. But all our CTOs seems to have collectively thrown us to the wolves.

I suspect most people don't even know there's a there there.

For instance, while I now know that file systems have permissions, before I became a programmer, I spent maybe ten years thinking of permissions as a special, obscure system thing that you should never touch.

For that matter, I suspect many people don't know basic things like that a file system isn't inherently the operating system.

And, where would you go to learn this information? Your Mac doesn't ship with a manual—how would you know one exists? Furthermore, I would wager that perhaps most people have never learned how anything works requiring a manual and are simply unaware that that's a thing.

All to say, I'm not sure "refusal" is the right term.

The knowledge gap is very real. Because unsavvy users are just going to paste the API key into codex and say "make it work". For the truly lazy/uninformed, codex has computer use, and are going to tell it go into Vercel/Netlify/Stripe/Cloudflare for them, and get the API key, and save it to .env for them. So users knowing they need such a feature in the first place should be celebrated when the alternative is even dumber.

That's the product that is being sold here… why shame the users for expecting what was marketed to them?

The difference is that git is a traditional programming tool which executes deterministically.

agents are not deterministic tools, they're not sandboxes or container runtimes or languages with capabilities models.

They're a way to run arbitrary commands.

It would be like saying that "xterm" should have a ".xtermnoexec" list of commands you can't run, or that VLC should have an option for actors it won't show.

terminals run shells which run commands, it's not really deeply aware of what commands your shell ultimately run, and it's not in xterm's job to setup a sandbox and strip out executables.

VLC displays pixels, it's not up to it to figure out if those pixels are a certain actor.

codex pipes text and tool calls back and forth between OpenAI's servers, and it barely understands what that text and those tool calls are, and especially if a given tool touched a file. If you want VLC to not display an actor, you need to add a layer on top of VLC to stop it displaying a list of movies. If you want codex to not display a file's contents, you need a layer on top of codex to prevent it going near that file.

.gitignore doesn't have the same security implications.

If you fail to prevent a private key from being added to your repository, you can reverse this and purge it from the blobs and reflog as if it never happened.

If you fail to prevent OpenAI from ingesting a private key, you have created a security incident.

But that means the process can’t use the key for network requests, right?

OnePassword can do something like this where you put references to a path there instead of the key material, and then you wrap the invoke command with their CLI and it replaces them. So your local env file never has anything sensitive. A malicious agent could still exfiltrate if you give it access to debug tools on the running code though.

A good but altogether separate note from the point I’m making: this lack of access is seen as an obstacle to overcome, and other means of access will be tried if available.

It’s a different mental model than a first party solution to “ignore” files.

Lack of knowledge and the desire to have it run containers for things.

Or just have a corporate contract that provides assurances.

Though really I’m skeptical that much corporate info is secret for competitive or privacy reasons.

Mostly it seems to be for liability / discovery reasons. Which are still legit of course, but ideas are a dime a dozen and every company has more than they know what to do with. It’s the resourcing and execution that are hard.

Yet many use public github, and human developers accidently push secrets and other "not for public" files all the time.

> Why is it necessary for an agent to upload every bit of data it sees to OpenAI at all?

The LLM is running at OpenAI. The agent doesn't see anything that doesn't get sent to OpenAI.

It's like running a compiler in the cloud and asking why you need to send your source code to it when you only want the binary to be on your local PC. It's because that's where the processing is going on and it can't process what it can't see.

> why should the data exist permanently anywhere but in its original location?

Sure, they don't necessarily have to retain it permanently.