[deleted]
A way to exclude sensitive files issue still open for OpenAI Codex
81–90 of 157 posts
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#82These tools are data collection mechanisms to help train these better models. I'm working with some folks to figure out a way to put a layer between the harness and the models to have better control of what data gets sent to and from the model itself and the harness.
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#83Files that codex and any other coding agent has access to, should be opt-in NOT opt-out. I think codex is not the right layer to solve this if you want a sane(one-click) UX. We built our own internal sandboxing-terminal around claude and codex. Where a user-configured base-folder with low-risk code and creds is COPIED into the sandbox BEFORE new session creation. There were many other UX related reasons to build our…
Do I understand correctly that you scope least-privilege creds/tokens and pass those to the sandbox? I'd be curious to learn more
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#84Earlier quoted context omitted.
Not sure I agree? It’s not like gitignore should be independent from git
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. termina…
> they're not sandboxes
Yes they can be, and Codex offers one. It uses Bubblewrap and seccomp on Linux which are perfectly capable of restricting filesystem access.
In a default setup every command is executed inside a restrictive sandbox and you're only asked for permission to run that command if the execution fails.
I don't necessarily think that it's a good idea to rely on these sandboxes as your only line of defense but that's absolutely a feature that they can, should, and do offer.
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#85Earlier 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.
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 _e…
> 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!
I have hardly ever seen this kind of hubris among software developers. The only thing that was common was many software developers were - let's say - somewhat direct in their feedback towards people who are not willing to learn.
I thus rather have the feeling that this kind of accusation of hubris towards software developers rather originates in business people projecting their own overconfidence (hubris) onto software developers.
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#86The 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…
Sounds overkill, how about giving the agent its own user?
That's what I do in part because I went it to use the same system libraries etc. installed on my laptop, but I worry it will try to use privesc exploits...
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#87Earlier quoted context omitted.
Does that work? I've never seen it used. It seems easy to escape. The docs seem to suggest using alternate approaches. > Modern systems provide more secure ways to implement a restricted environment, such as jails, zones, or containers. https://www.gnu.org/software/bash/manual/html_node/The-Restr...
I don't think I've ever seen it used. I think the idea was back in the day when you wanted to let a user have a shell login (because that's the only way you could use a shared computer) but wanted to confine them to a specific directory and prevent them running anything that wasn't in the pre-defined PATH that you set for them.
Can't you do that with regular Unix permissions?
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#88To avoid the risk of exfiltration, we need to stop using .env for security. API keys needed when working in a repo should be handled by a proxy like ssh-agent, and we need something better than bearer auth.
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#89Earlier quoted context omitted.
Yes, this was solved decades ago. How do you stop a human from reading one of your files? chmod 600
> How do you stop a human from reading one of your files? Call the police!
> > How do you stop a human from reading one of your files?
> Call the police!
Rather: Send the Marines.
With intro: https://www.youtube.com/watch?v=eFvxqQTh3m4
Without intro: https://www.youtube.com/watch?v=HHhZF66C1Dc
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#90Earlier quoted context omitted.
Does that work? I've never seen it used. It seems easy to escape. The docs seem to suggest using alternate approaches. > Modern systems provide more secure ways to implement a restricted environment, such as jails, zones, or containers. https://www.gnu.org/software/bash/manual/html_node/The-Restr...
I don't think I've ever seen it used. I think the idea was back in the day when you wanted to let a user have a shell login (because that's the only way you could use a shared computer) but wanted to confine them to a specific directory and prevent them running anything that wasn't in the pre-defined PATH that you set for them.
You could also produce special purpose applications this way, say to provide access to the online library catalog, or a run a gopher client for use in a public terminal lab. Telnetting to a unix account running some sort of restricted shell was how these often worked.
A sibling comment I can't reply to asks if you can do with with unix permissions.
These were really intended for anonymous guest access, or at least often used for this purpose. You couldn't do the same things with the file permissions systems at the time.