Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A way to exclude sensitive files issue still open for OpenAI Codex

github.com

Post reply on HN
Print view View original

71–80 of 157 posts

Re: A way to exclude sensitive files issue still open for OpenAI Codex

#71

Post by eduction »

Great example of why operating systems should be stealing more ideas from Qubes, the OS where everything runs in a vm.

Qubes is not practical for mobile laptop use and non expert users.

BUT it would be very practical for other OSes to offer the option of VM-style isolated containers as first class objects that are easy to make and configure boundaries on, and for which first class interop facilities are provided (eg “send this file to this container” “send the clipboard to this container’s clipboard).

Re: A way to exclude sensitive files issue still open for OpenAI Codex

#72

Post by atomicnumber3 »

embedding-shape wrote: post #44
cowsandmilk wrote: post #15

Earlier quoted context omitted.

100% this. The idea that Codex should enforce this is putting the security boundary at the wrong layer. If you don’t want codes to access something, make it so it doesn’t have access.

The Codex bug tracker is a great insight into how wide the knowledge gap seem to be between users. The issue where people ask them to add back /undo or whatever it is instead of just learning to use git, probably reached 100 comments at least by now. People seemingly don't really understand the computers they use on a daily basis, and refuse to learn too.

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.

Re: A way to exclude sensitive files issue still open for OpenAI Codex

#73

Post by tingletech »

tern wrote: post #63
embedding-shape wrote: post #44

Earlier quoted context omitted.

The Codex bug tracker is a great insight into how wide the knowledge gap seem to be between users. The issue where people ask them to add back /undo or whatever it is instead of just learning to use git, probably reached 100 comments at least by now. People seemingly don't really understand the computers they use on a daily basis, and refuse to learn too.

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…

When I was an undergraduate biology student in 1991 a suitemate told me I should go to some desk in some building over by Muir and get an account on the VAX. There were strange rooms all over campus that were open 24/7 and were loaded with green and amber screen terminals with integrated keyboards. Lots of sessions for CS lectures were held in these rooms and there was always interesting notes on the white boards (most rooms still had black boards or green boards, but think the chalk was too dusty so these rooms usually had the white boards.

Once I saw an instruction that was circled with an arrow pointing to is that said:

  man man
  man -k -or- apropos
and that was how I learned about computers.

I just typed `man man` in a terminal on my Mac, and luckily its still there.

Re: A way to exclude sensitive files issue still open for OpenAI Codex

#74

Post by hoppp »

SoftTalker wrote: post #61
hoppp wrote: post #43

Earlier quoted context omitted.

Sounds like a good way to do it. Makes me think of docker secret where the secrets are exposed as files and accessable only from inside the container. If the development environment uses docker then thats a solution too I guess

If you let your agent use docker you've basically given it root on your machine.

I use podman btw

Its aliased to docker

Building a project as a container and giving an agent access to running docker commands are different things.

Re: A way to exclude sensitive files issue still open for OpenAI Codex

#76

Post by LtWorf »

embedding-shape wrote: post #44
cowsandmilk wrote: post #15

Earlier quoted context omitted.

100% this. The idea that Codex should enforce this is putting the security boundary at the wrong layer. If you don’t want codes to access something, make it so it doesn’t have access.

The Codex bug tracker is a great insight into how wide the knowledge gap seem to be between users. The issue where people ask them to add back /undo or whatever it is instead of just learning to use git, probably reached 100 comments at least by now. People seemingly don't really understand the computers they use on a daily basis, and refuse to learn too.

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

Re: A way to exclude sensitive files issue still open for OpenAI Codex

#77

Post by chriddyp »

TheDong wrote: post #4

You can do this now: change the file permissions such that the user you run codex as can't read them, or run codex in a container without those files mounted. If you don't do that, the agent will be able to incidentally upload them. What if the model runs "rg foo", and one of those files contains the string "foo"? It uploads the tool output, which includes the file contents. And so, the only solution is to make it so…

While this is true, there is also a layer in the harness between the output of _any_ tool output (eg stdout or hand-rolled tools) and the LLM. A tool could read the file but then the agentic harness could redact the output before returning it back to the llm if any of the contents matched the file contents. We do something similar in Plotly Studio where we check the entropy of strings in the user input and flag & redact any high entropy strings to the user as “potential credentials” thay the user might have inadvertently copied and pasted into the prompt before sending to the llm.

There are ways around this - the llm can always be clever by invoking tools to read the file contents in a different way than the direct file contents - but this is all to say that the agentic harness layer _does_ allow for deterministic logic in between tool output and the LLM requests.

Re: A way to exclude sensitive files issue still open for OpenAI Codex

#78

Post by binsquare »

bob1029 wrote: post #24

The only thing close to a guarantee is to give the agent exclusive access to a clean VM with precisely the information and permissions you want it to have. I've been looking into a "workspace" concept that involves an entire cloud VM being spun up as part of an agent conversation such that code changes can be iterated without touching the user's local machine or other trusted contexts. All the agent's tools only have…

I made a lightweight vm specifically for this use case: https://github.com/smol-machines/smolvm

Re: A way to exclude sensitive files issue still open for OpenAI Codex

#79

Post by sheremetyev »

jrvarela56 wrote: post #50
TheDong wrote: post #4

You can do this now: change the file permissions such that the user you run codex as can't read them, or run codex in a container without those files mounted. If you don't do that, the agent will be able to incidentally upload them. What if the model runs "rg foo", and one of those files contains the string "foo"? It uploads the tool output, which includes the file contents. And so, the only solution is to make it so…

Sandboxing is a solved problem, there are dozens of providers of firecracker instances to run your agent in. The problem to be solved is how do you define task-specific least privilege versions of your coding agent.

I'm running Codex/Claude in native macOS sandbox with access just to the project folder (plus read-only access to Git repo), and expand to other folders if necessary - https://github.com/sheremetyev/sandfence

Re: A way to exclude sensitive files issue still open for OpenAI Codex

#80

Post by fragmede »

embedding-shape wrote: post #44
cowsandmilk wrote: post #15

Earlier quoted context omitted.

100% this. The idea that Codex should enforce this is putting the security boundary at the wrong layer. If you don’t want codes to access something, make it so it doesn’t have access.

The Codex bug tracker is a great insight into how wide the knowledge gap seem to be between users. The issue where people ask them to add back /undo or whatever it is instead of just learning to use git, probably reached 100 comments at least by now. People seemingly don't really understand the computers they use on a daily basis, and refuse to learn too.

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.
Post reply on HN