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

61–70 of 157 posts

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

#61

Post by SoftTalker »

hoppp wrote: post #43
tiew9Vii wrote: post #38

Earlier quoted context omitted.

A lot of people have secrets/config files in the projects working directory but ignored by git i.e. `.env.local` So they're following best practice, not committing secrets but agents running locally can still see them even if sandboxing to the working directory. I've taken to storing configs using XDG_CONFIG_HOME and have the app auto resolve them by convention or take a cli arg to specify the config path. All secret…

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.

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

#62

Post by nikhilsimha »

Files 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 own terminal. Can share more if anyone is interested.

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

#63

Post by tern »

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.

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.

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

#64

Post by 8organicbits »

SoftTalker wrote: post #55
TheDong wrote: post #49

Earlier quoted context omitted.

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…

bash actually has a "restricted" mode which is sort of like that. In restricted mode, the following are disallowed: - Changing directories with cd. - Setting or unsetting the values of SHELL, PATH, HISTFILE, ENV, or BASH_ENV. - Specifying command names containing /. - Importing function definitions from the shell environment at startup. - Parsing the values of BASHOPTS and SHELLOPTS from the shell environment at star…

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

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

#65

Post by jstanley »

nativeit wrote: post #60
kstenerud wrote: post #48

Earlier quoted context omitted.

If you're not sandboxing your agent, everything on your computer is waiting to be exposed. Assuming that file permissions will save you is naively dangerous.

It seems insane to me that so many people are OK with this. Why is it necessary for an agent to upload every bit of data it sees to OpenAI at all? Particularly if my agents can’t remember anything beyond a single session, why should the data exist permanently anywhere but in its original location?

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

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

#66

Post by SoftTalker »

8organicbits wrote: post #64
SoftTalker wrote: post #55

Earlier quoted context omitted.

bash actually has a "restricted" mode which is sort of like that. In restricted mode, the following are disallowed: - Changing directories with cd. - Setting or unsetting the values of SHELL, PATH, HISTFILE, ENV, or BASH_ENV. - Specifying command names containing /. - Importing function definitions from the shell environment at startup. - Parsing the values of BASHOPTS and SHELLOPTS from the shell environment at star…

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.

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

#68

Post by TZubiri »

Out of scope, learn cybersecurity. A simple concept such as users and permissions solves this problem.

Regardless of what technique you use, you need a deputy, you wouldn't ask an employee not to go into the vault, right? You would lock the vault. Well you can ask the employee not to go into the vault, and you can also ask codex not to use certain files, but if you need more certainty, you need to it outside.

The issue seems to be that people want to ask their agent to do everything, they want the agent to lock themselves out of some system, they want the agent to install itself, they want the agent to write their prompts so they don't have to write them. At some point there's some things YOU have to do, and you have to DO them.

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

#70

Post by TZubiri »

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…

Sounds overkill, how about giving the agent its own user?
Post reply on HN