9 ms·

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

227 points by pikseladam 3mo ago

pikseladam 3mo ago
it has been a year and still it is not resolved
- pamcake 3mo ago
  It's not their problem to solve. Don't give it access to sensitive files on the first place.
pohl 3mo ago
This should be an open standard like AGENTS.md or skills. What do other harnesses do?
- ampersandwhich 3mo ago
  I believe JetBrains products like Junie use the neutral term .aiignore for this funtionality.
TheDong 3mo ago
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 the codex process is unable to access those files, hence using a container, or unix permissions, or deleting the files. Which you can already do. I imagine this isn't resolved primarily because people expect it to apply to bash tool use, not just the "read" and "edit" tools, and people also expect those files to still be accessible i.e. if the agent invokes "make", which makes it impossible to solve perfectly.
- FergusArgyll 3mo ago
  Yes, this was solved decades ago. How do you stop a human from reading one of your files? chmod 600
  - deleted 3mo ago
    [deleted]
  - re-thc 3mo ago
    > How do you stop a human from reading one of your files? Call the police!
    - aleph_minus_one 3mo ago
      > > 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 https://www.youtube.com/watch?v=eFvxqQTh3m4 Without intro: https://www.youtube.com/watch?v=HHhZF66C1Dc https://www.youtube.com/watch?v=HHhZF66C1Dc
- lelandfe 3mo ago
  Just be aware that AI agents will explore alternate means of accessing said files: https://news.ycombinator.com/item?id=48348578 https://news.ycombinator.com/item?id=48348578
  - cowsandmilk 3mo ago
    If you’re already running codex as a different user to limit its file permissions, why would you add it to the docker group?
    - lelandfe 3mo ago
      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.
planb 3mo ago
Sound like snake oil. How would this work? The app that the agent is developing needs access to the file, so access to it cannot be blocked. Just because read_file can not access it (I think current harnesses prevent reading .env files already), does not mean the contents will never be seen by the model.
iluvcommunism 3mo ago
[dead]
petcat 3mo ago
Hopefully they never actually implement this pointless feature because it will only give people a false sense of security given the unpredictable nature of LLMs. How could something like this even be enforced? People just need to learn how to use the tools their system already provides them. i.e., chmod
- wodenokoto 3mo ago
  The whole point of using an agent is that I don't want to learn everything. I fully expected the harness to read the .agentignore file and do what is needed to hide it from the LLM. But apparently, even if implemented, that's not how it works!
  - KHRZ 3mo ago
    How would it prevent an agent from writing a script that discovers the secret file? It's not magic.
    - tomrod 3mo ago
      It can't. As others pointed out, its the wrong layer to implement the security feature. The agent needs to operate in an isolated user / container.
- quotemstr 3mo ago
  > Hopefully they never actually implement this pointless feature because it will only give people a false sense of security given the unpredictable nature of LLMs. How could something like this even be enforced? You run everything the model wants to do inside an OS-enforced sandbox of the sort browsers have used for decades to isolate tabs. It's already implemented and works fine. Codex just needs a few minor tweaks to make it apply its already-implemented sandboxing policy to a few situations it misses today. > People just need to learn how to use the tools their system already provides them. i.e., chmod I'm not running my agent as a separate POSIX user. Fortunately, my OS provides all the tools I need to free my having to do so. I love when I do something in a few hours and people later call it impossible.
kstenerud 3mo ago
.agentsignore is NOT a security tool. It's a good idea as a hint to agents about what files it should ignore (because they'd be of no value and only chew up tokens). However, using it to prevent exposure of secrets would be a BIG mistake. There's simply no way to guarantee that an agent will ignore things in the ignore file. And even a harness-enforced restriction would still be in-process, which a rogue agent could trivially compromise. For security, use a sandbox. Nothing else will do. I do AI sandboxes (FOSS, free forever, no rug pull): https://github.com/kstenerud/yoloai https://github.com/kstenerud/yoloai
agentdev001 3mo ago
Sounds like user error to me. Codex gives an llm a tool to allow it to use shell in the context of the host and user in which it is running. If a resource is sensitive, and accessible in that context, then the user is doing something wrong. Would you change your practices if you treated your coding agent as an untrusted human ssh'd under the identity you use for it? In any case. There are solutions in the comments on the issue, as well as this hn thread.
cowpig 3mo ago
I don't think we should ask the agent runtime to police itself. I contributed to a tool for this problem that is lower-friction than traditional sandboxing: greywall.io But you should use something to contain an agent runtime. The idea that people run things like codex on their machines with regular user permissions is baffling to me.
ZiiS 3mo ago
However clever/stupid you believe LLMs are they are extremely capable of working around these sorts of restrictions. The ask is for .env files for whatever code you are writing so if the code it writes dosn't have access (i.e. filesystem/container) what is the point, if the code under development reads the env how dose codex debug it without accedentally reading the values from memory? Adding a security setting that dosn't work is much worse then not having one.
bob1029 3mo ago
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 effect when supplied with a specific workspace guid. CLI tools like git are not authorized to talk to the remotes in this arrangement. The machine is initialized with a clone and no way to talk to origin. There are dedicated methods in the harness that can reach into the VM and pull out a change set for deterministic PR generation in the secure contexts (e.g. when the agent calls "ReadyForReview" or similar).
- TZubiri 3mo ago
  Sounds overkill, how about giving the agent its own user?
  - cozzyd 3mo ago
    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...
    - TZubiri 3mo ago
      highly unlikely the LLM will try to do privesc exploits, LPE risk still exists and should be assumed though, although the more likely risk model is the LLM installing an infected left-pad package, or (on servers) installing a dependency with a RCE vuln, or creating a new RCE vuln from scratch. If we are talking about running the agent on a dev machine, though, Codex doesn't seem to introduce a lot of risk, considering that I can already add OS protection layers, and that the devs added their own protection layers, and that I can direct the model towards my preferences (like not installing dependencies through npm or pip).
  - bob1029 3mo ago
    It's really not overkill if you have good tools to work with. Hyper-V is quite capable of providing ephemeral workspaces on timescales measured in minutes. Especially with nested virtualization. One big machine with fast local disks can provide very short cold start times for a golden image stored on the same.
hoppp 3mo ago
Do not store secrets in the repository in files, but inject them during runtime. Then the agents have no way to access them.
- tiew9Vii 3mo ago
  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 secrets are in files, not env vars. That way when using sandboxing the agent can never see the configs or secrets as outside the working directory.
  - hoppp 3mo ago
    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
    - SoftTalker 3mo ago
      If you let your agent use docker you've basically given it root on your machine.
      - hoppp 3mo ago
        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.
Lucasoato 3mo ago
There should be a standard around .agentignore file similarly to what happens with .gitignore file. Of course this could still be workarounded by agent bash command tools, but at least basic operations like reading and so on should be checked and prevented.
mbid 3mo ago
I recently got the tool I use to orchestrate agents in (remote/secure) devcontainers open-sourced at work to solve this properly: https://github.com/nvidia/rumpelpod https://github.com/nvidia/rumpelpod As others here have pointed out, it's exceedingly unlikely that a blocklist like proposed in the issue would ever be complete. You shouldn't allow agents direct yolo-access to your machine if it has sensitive data. Codex works particularly well as a remote agent harness because of its client-server architecture: The server component runs in the container, which might be remote, while the client runs locally. So, in contrast to e.g. the claude cli where the frontend also runs remotely, there's no lag when you write/edit prompts.
- jofzar 3mo ago
  Neat tool! Will have to check it out Edit: would love a couple of pictures/video of how you use it. I kind of get the idea, but it seems like more hassle then it would be worth? Your comment of codex makes it seem like I might be missing something tho.
  - mbid 3mo ago
    Yeah I should add a video to the README. Have you tried running `rumpel codex foo123` in one of your repositories, asking it to commit something, then `rumpel merge foo123` to get the changes back to your local checkout? Use a different terminal for the merge command, or detach from the codex session with `ctrl-a d`. You can also look at the commit first with `rumpel review foo123`, or get a shell inside the agent environment via `rumpel enter foo123`.
- noveltyaccount 3mo ago
  I agree a block list won't work. And unix file permissions may not be enough; I once saw Codex 5.4 use docker to execute a command as root since it couldn't run sudo. Running in a container may be the only solution: > sudo needs an interactive password here, so I'll use Docker itself to prepare the bind-mount directory as root and hand ownership back to UID/GID 1000. That keeps the compose file's non-root runtime intact. > Ran `docker run --rm -v /shares:/shares alpine:3.20 sh -c 'mkdir -p /shares/local-llm/models && chown 1000:1000 /shar...`
mixedbit 3mo ago
I work on a Linux sandbox that makes it easy to hide sensitive files from AI agents while keeping the files they need accessible. Check it out: https://github.com/wrr/drop https://github.com/wrr/drop
swordlucky666 3mo ago
[flagged]
edg5000 3mo ago
Bind mounts can work fine. Setting them up does require root though. Easiest would be if the harness offered to enable containment. Awkwardly, it would require root.
- ptspts 3mo ago
  In fact, it's possible to set up bind mounts without root on a modern Linux system, using a user namespace and a mount namespace.
  - apitman 3mo ago
    podman is my favorite tool for this.
  - edg5000 3mo ago
    You also need setuid, that's were I hit the root requirement, the bind mount itself can indeed be created.
deleted 3mo ago
[deleted]
nikhilsimha 3mo ago
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.
- schipperai 3mo ago
  Do I understand correctly that you scope least-privilege creds/tokens and pass those to the sandbox? I'd be curious to learn more
kardos 3mo ago
A solution to this is apptainer: you configure it to not see any of the host files by default, and mount the repo you want to work on at runtime.
- TZubiri 3mo ago
  Question, out of curiosity, do you know how User and Permissions work?
TZubiri 3mo ago
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.
eduction 3mo ago
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).
SubiculumCode 3mo ago
So how might I restrict the read paths if I am running codex as a plugin in vscode?
deleted 3mo ago
[deleted]
kennethops 3mo ago
These 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.
skybrian 3mo ago
To 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.
- pamcake 3mo ago
  Yes you should. It will come naturally if you go down the road of separating code from data and properly isolating dev and prod environments, applying principle of least privilege as you do. .env files for creds are a convenience for dev and testing. They were never supposed to be used for security or carried around with sensitive stuff inside. None of this is new.
- tomjakubowski 3mo ago
  The desire not to leak valuable secrets is a strong argument for supporting local-first developer workflows. If an AI agent exfiltrates the credentials to connect to my local dev Postgres database which stores synthetic data, that's pretty low impact.
davidcann 3mo ago
You can block file access on macOS by running codex in a sandbox with my app: https://multitui.com https://multitui.com
quotemstr 3mo ago
I have a local patch that reads a new config section that looks like this: [sandbox.always.filesystem] "~/.config" = "none" "~/.config/git" = "read" (In other words, "other configuration notwithstanding, disallow reads under ~/.config, but do allow reads under ~/.config/git") I then force-merge the restrictions in this sandbox profile into all other sandbox profiles. I also added a new tiered sandboxing mode: now escalated commands, like regular commands, also run in a sandbox: just a more liberal one still subject to sandbox.always.filesystem rules. I added a new menu option to escalate (manually, one-shot) to truly-outside-sandbox mode for those few commands that aren't happy under any bwrap user namespace. For simplicity, I also rewrote the built-in tools to just work through executing commands in the sandbox. Why is ReadFile something separate from cat-in-sandbox? why do we have two rule-enforcement systems, one for shell commands and one for tools? Well, now we don't. Took me a few hours while I was doing other stuff. I love free software. I don't understand why you'd run Codex and not customize it locally. I feel a bit guilty about not sending the patch upstream. It's just so much easier to fix software locally than get improvements landed upstream, especially now that LLMs make carrying patches forward easy.
vollos 3mo ago
[flagged]
cush 3mo ago
Wouldn’t implementing this just give a false sense of security? As long as an agent can execute arbitrary code it can access anything it has access to. Adding a dont-access-my-secrets-pretty-please.yml file isn’t going to help any
nullbio 3mo ago
Look at agent-vault and 1password. There's not really any reason to be storing sensitive keys in plaintext on your local disk that the agent can access.
anuramat 3mo ago
just use bwrap?
NamlchakKhandro 3mo ago
should be using pi-mono tbh. all vendor provided harnesses are complete trash
nicoty 3mo ago
I've contributed to https://github.com/0xferrous/agent-box https://github.com/0xferrous/agent-box which allows you to bind-mount git repositories into containers that agents operate in, preventing the agents from accessing files that aren't bind-mounted. Your usual .gitignore can then be used to also ignore files within the repo to be bind-mounted, which prevents agents from accessing them at all, essentially working as a sandbox. I also maintain https://github.com/nothingnesses/agent-images https://github.com/nothingnesses/agent-images which allows you to use Nix to reproducibly spin up OCI containers containing agents and any other tools you need and use these with agent-box. I use both at the moment to work on some personal projects with agents, where I set up multiple separate git worktrees for the agents to work in, preventing them from accessing anything outside of the worktrees and from trampling over each other's work.
kgeist 3mo ago
>never read or send .env, .env.*, .pem, id_, .aws/, .ssh/. A think a better practice is to not store those things in the repository folder in the first place.
claud_ia 3mo ago
[flagged]
Tragentics 3mo ago
[flagged]
datsci_est_2015 3mo ago
The fact that pretty much every comment in this thread suggests a different solution means there’s still plenty of innovation and consolidation to occur on this problem. My take is that Unix already solved all of these user access problems (what can a user read or execute), so the solution will probably be around containers or virtual machines. But the UX around booting up a container or virtual machine for agentic workflows needs to be simplified to the point where vibe coders who don’t know the first thing about Unix, VMs, or containers can still take advantage of the solutions.
MMDrame 3mo ago
[flagged]
bolinfest 3mo ago
We have had a solution for this built into Codex for several months now. It is marked "Beta" in the docs because we have been tweaking the config API here and there, but a number of folks have been using it for quite awhile and I would recommend switching to it and reporting any issues you find: https://developers.openai.com/codex/permissions https://developers.openai.com/codex/permissions With permission profiles in Codex, you can: - Mark a path, glob, or meta variable (like `:workspace_roots`) readable, writable, or unreadable. - Amend an existing profile using ordinary `config.toml` layering rules. - Create a new profile by extending an existing one (`extends = ":workspace"` is generally what you want to do). Note that permission profiles also allow you to configure the network proxy for the sandbox in a fine-grained way. (Previously, the network options for the Codex sandbox were all or nothing.) Finally, you can also test running a command under a permission profile using: codex sandbox -P PROFILE_NAME -- PROGRAM ARGS... Our goal has been to provide something powerful and flexible out of the box so you do not need to bolt on other solutions like the ones mentioned on this thread.
sacravenger 3mo ago
[flagged]

227 points by pikseladam 3mo ago

pikseladam 3mo ago

it has been a year and still it is not resolved

pamcake 3mo ago
It's not their problem to solve. Don't give it access to sensitive files on the first place.

pohl 3mo ago

This should be an open standard like AGENTS.md or skills. What do other harnesses do?

ampersandwhich 3mo ago
I believe JetBrains products like Junie use the neutral term .aiignore for this funtionality.

TheDong 3mo ago

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 the codex process is unable to access those files, hence using a container, or unix permissions, or deleting the files. Which you can already do. I imagine this isn't resolved primarily because people expect it to apply to bash tool use, not just the "read" and "edit" tools, and people also expect those files to still be accessible i.e. if the agent invokes "make", which makes it impossible to solve perfectly.

FergusArgyll 3mo ago
Yes, this was solved decades ago. How do you stop a human from reading one of your files? chmod 600
- deleted 3mo ago
  [deleted]
- re-thc 3mo ago
  > How do you stop a human from reading one of your files? Call the police!
  - aleph_minus_one 3mo ago
    > > 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 https://www.youtube.com/watch?v=eFvxqQTh3m4 Without intro: https://www.youtube.com/watch?v=HHhZF66C1Dc https://www.youtube.com/watch?v=HHhZF66C1Dc
lelandfe 3mo ago
Just be aware that AI agents will explore alternate means of accessing said files: https://news.ycombinator.com/item?id=48348578 https://news.ycombinator.com/item?id=48348578
- cowsandmilk 3mo ago
  If you’re already running codex as a different user to limit its file permissions, why would you add it to the docker group?
  - lelandfe 3mo ago
    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.

planb 3mo ago

Sound like snake oil. How would this work? The app that the agent is developing needs access to the file, so access to it cannot be blocked. Just because read_file can not access it (I think current harnesses prevent reading .env files already), does not mean the contents will never be seen by the model.

iluvcommunism 3mo ago

[dead]

petcat 3mo ago

Hopefully they never actually implement this pointless feature because it will only give people a false sense of security given the unpredictable nature of LLMs. How could something like this even be enforced? People just need to learn how to use the tools their system already provides them. i.e., chmod

wodenokoto 3mo ago
The whole point of using an agent is that I don't want to learn everything. I fully expected the harness to read the .agentignore file and do what is needed to hide it from the LLM. But apparently, even if implemented, that's not how it works!
- KHRZ 3mo ago
  How would it prevent an agent from writing a script that discovers the secret file? It's not magic.
  - tomrod 3mo ago
    It can't. As others pointed out, its the wrong layer to implement the security feature. The agent needs to operate in an isolated user / container.
quotemstr 3mo ago
> Hopefully they never actually implement this pointless feature because it will only give people a false sense of security given the unpredictable nature of LLMs. How could something like this even be enforced? You run everything the model wants to do inside an OS-enforced sandbox of the sort browsers have used for decades to isolate tabs. It's already implemented and works fine. Codex just needs a few minor tweaks to make it apply its already-implemented sandboxing policy to a few situations it misses today. > People just need to learn how to use the tools their system already provides them. i.e., chmod I'm not running my agent as a separate POSIX user. Fortunately, my OS provides all the tools I need to free my having to do so. I love when I do something in a few hours and people later call it impossible.

kstenerud 3mo ago

.agentsignore is NOT a security tool. It's a good idea as a hint to agents about what files it should ignore (because they'd be of no value and only chew up tokens). However, using it to prevent exposure of secrets would be a BIG mistake. There's simply no way to guarantee that an agent will ignore things in the ignore file. And even a harness-enforced restriction would still be in-process, which a rogue agent could trivially compromise. For security, use a sandbox. Nothing else will do. I do AI sandboxes (FOSS, free forever, no rug pull): https://github.com/kstenerud/yoloai https://github.com/kstenerud/yoloai

agentdev001 3mo ago

Sounds like user error to me. Codex gives an llm a tool to allow it to use shell in the context of the host and user in which it is running. If a resource is sensitive, and accessible in that context, then the user is doing something wrong. Would you change your practices if you treated your coding agent as an untrusted human ssh'd under the identity you use for it? In any case. There are solutions in the comments on the issue, as well as this hn thread.

cowpig 3mo ago

I don't think we should ask the agent runtime to police itself. I contributed to a tool for this problem that is lower-friction than traditional sandboxing: greywall.io But you should use something to contain an agent runtime. The idea that people run things like codex on their machines with regular user permissions is baffling to me.

ZiiS 3mo ago

However clever/stupid you believe LLMs are they are extremely capable of working around these sorts of restrictions. The ask is for .env files for whatever code you are writing so if the code it writes dosn't have access (i.e. filesystem/container) what is the point, if the code under development reads the env how dose codex debug it without accedentally reading the values from memory? Adding a security setting that dosn't work is much worse then not having one.

bob1029 3mo ago

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 effect when supplied with a specific workspace guid. CLI tools like git are not authorized to talk to the remotes in this arrangement. The machine is initialized with a clone and no way to talk to origin. There are dedicated methods in the harness that can reach into the VM and pull out a change set for deterministic PR generation in the secure contexts (e.g. when the agent calls "ReadyForReview" or similar).

TZubiri 3mo ago
Sounds overkill, how about giving the agent its own user?
- cozzyd 3mo ago
  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...
  - TZubiri 3mo ago
    highly unlikely the LLM will try to do privesc exploits, LPE risk still exists and should be assumed though, although the more likely risk model is the LLM installing an infected left-pad package, or (on servers) installing a dependency with a RCE vuln, or creating a new RCE vuln from scratch. If we are talking about running the agent on a dev machine, though, Codex doesn't seem to introduce a lot of risk, considering that I can already add OS protection layers, and that the devs added their own protection layers, and that I can direct the model towards my preferences (like not installing dependencies through npm or pip).
- bob1029 3mo ago
  It's really not overkill if you have good tools to work with. Hyper-V is quite capable of providing ephemeral workspaces on timescales measured in minutes. Especially with nested virtualization. One big machine with fast local disks can provide very short cold start times for a golden image stored on the same.

hoppp 3mo ago

Do not store secrets in the repository in files, but inject them during runtime. Then the agents have no way to access them.

tiew9Vii 3mo ago
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 secrets are in files, not env vars. That way when using sandboxing the agent can never see the configs or secrets as outside the working directory.
- hoppp 3mo ago
  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
  - SoftTalker 3mo ago
    If you let your agent use docker you've basically given it root on your machine.
    - hoppp 3mo ago
      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.

Lucasoato 3mo ago

There should be a standard around .agentignore file similarly to what happens with .gitignore file. Of course this could still be workarounded by agent bash command tools, but at least basic operations like reading and so on should be checked and prevented.

mbid 3mo ago

I recently got the tool I use to orchestrate agents in (remote/secure) devcontainers open-sourced at work to solve this properly: https://github.com/nvidia/rumpelpod https://github.com/nvidia/rumpelpod As others here have pointed out, it's exceedingly unlikely that a blocklist like proposed in the issue would ever be complete. You shouldn't allow agents direct yolo-access to your machine if it has sensitive data. Codex works particularly well as a remote agent harness because of its client-server architecture: The server component runs in the container, which might be remote, while the client runs locally. So, in contrast to e.g. the claude cli where the frontend also runs remotely, there's no lag when you write/edit prompts.

jofzar 3mo ago
Neat tool! Will have to check it out Edit: would love a couple of pictures/video of how you use it. I kind of get the idea, but it seems like more hassle then it would be worth? Your comment of codex makes it seem like I might be missing something tho.
- mbid 3mo ago
  Yeah I should add a video to the README. Have you tried running `rumpel codex foo123` in one of your repositories, asking it to commit something, then `rumpel merge foo123` to get the changes back to your local checkout? Use a different terminal for the merge command, or detach from the codex session with `ctrl-a d`. You can also look at the commit first with `rumpel review foo123`, or get a shell inside the agent environment via `rumpel enter foo123`.
noveltyaccount 3mo ago
I agree a block list won't work. And unix file permissions may not be enough; I once saw Codex 5.4 use docker to execute a command as root since it couldn't run sudo. Running in a container may be the only solution: > sudo needs an interactive password here, so I'll use Docker itself to prepare the bind-mount directory as root and hand ownership back to UID/GID 1000. That keeps the compose file's non-root runtime intact. > Ran `docker run --rm -v /shares:/shares alpine:3.20 sh -c 'mkdir -p /shares/local-llm/models && chown 1000:1000 /shar...`

mixedbit 3mo ago

I work on a Linux sandbox that makes it easy to hide sensitive files from AI agents while keeping the files they need accessible. Check it out: https://github.com/wrr/drop https://github.com/wrr/drop

swordlucky666 3mo ago

[flagged]

edg5000 3mo ago

Bind mounts can work fine. Setting them up does require root though. Easiest would be if the harness offered to enable containment. Awkwardly, it would require root.

ptspts 3mo ago
In fact, it's possible to set up bind mounts without root on a modern Linux system, using a user namespace and a mount namespace.
- apitman 3mo ago
  podman is my favorite tool for this.
- edg5000 3mo ago
  You also need setuid, that's were I hit the root requirement, the bind mount itself can indeed be created.

deleted 3mo ago

[deleted]

nikhilsimha 3mo ago

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.

schipperai 3mo ago
Do I understand correctly that you scope least-privilege creds/tokens and pass those to the sandbox? I'd be curious to learn more

kardos 3mo ago

A solution to this is apptainer: you configure it to not see any of the host files by default, and mount the repo you want to work on at runtime.

TZubiri 3mo ago
Question, out of curiosity, do you know how User and Permissions work?

TZubiri 3mo ago

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.

eduction 3mo ago

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

SubiculumCode 3mo ago

So how might I restrict the read paths if I am running codex as a plugin in vscode?

deleted 3mo ago

[deleted]

kennethops 3mo ago

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

skybrian 3mo ago

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

pamcake 3mo ago
Yes you should. It will come naturally if you go down the road of separating code from data and properly isolating dev and prod environments, applying principle of least privilege as you do. .env files for creds are a convenience for dev and testing. They were never supposed to be used for security or carried around with sensitive stuff inside. None of this is new.
tomjakubowski 3mo ago
The desire not to leak valuable secrets is a strong argument for supporting local-first developer workflows. If an AI agent exfiltrates the credentials to connect to my local dev Postgres database which stores synthetic data, that's pretty low impact.

davidcann 3mo ago

You can block file access on macOS by running codex in a sandbox with my app: https://multitui.com https://multitui.com

quotemstr 3mo ago

I have a local patch that reads a new config section that looks like this: [sandbox.always.filesystem] "~/.config" = "none" "~/.config/git" = "read" (In other words, "other configuration notwithstanding, disallow reads under ~/.config, but do allow reads under ~/.config/git") I then force-merge the restrictions in this sandbox profile into all other sandbox profiles. I also added a new tiered sandboxing mode: now escalated commands, like regular commands, also run in a sandbox: just a more liberal one still subject to sandbox.always.filesystem rules. I added a new menu option to escalate (manually, one-shot) to truly-outside-sandbox mode for those few commands that aren't happy under any bwrap user namespace. For simplicity, I also rewrote the built-in tools to just work through executing commands in the sandbox. Why is ReadFile something separate from cat-in-sandbox? why do we have two rule-enforcement systems, one for shell commands and one for tools? Well, now we don't. Took me a few hours while I was doing other stuff. I love free software. I don't understand why you'd run Codex and not customize it locally. I feel a bit guilty about not sending the patch upstream. It's just so much easier to fix software locally than get improvements landed upstream, especially now that LLMs make carrying patches forward easy.

vollos 3mo ago

[flagged]

cush 3mo ago

Wouldn’t implementing this just give a false sense of security? As long as an agent can execute arbitrary code it can access anything it has access to. Adding a dont-access-my-secrets-pretty-please.yml file isn’t going to help any

nullbio 3mo ago

Look at agent-vault and 1password. There's not really any reason to be storing sensitive keys in plaintext on your local disk that the agent can access.

anuramat 3mo ago

just use bwrap?

NamlchakKhandro 3mo ago

should be using pi-mono tbh. all vendor provided harnesses are complete trash

nicoty 3mo ago

I've contributed to https://github.com/0xferrous/agent-box https://github.com/0xferrous/agent-box which allows you to bind-mount git repositories into containers that agents operate in, preventing the agents from accessing files that aren't bind-mounted. Your usual .gitignore can then be used to also ignore files within the repo to be bind-mounted, which prevents agents from accessing them at all, essentially working as a sandbox. I also maintain https://github.com/nothingnesses/agent-images https://github.com/nothingnesses/agent-images which allows you to use Nix to reproducibly spin up OCI containers containing agents and any other tools you need and use these with agent-box. I use both at the moment to work on some personal projects with agents, where I set up multiple separate git worktrees for the agents to work in, preventing them from accessing anything outside of the worktrees and from trampling over each other's work.

kgeist 3mo ago

>never read or send .env, .env.*, .pem, id_, .aws/, .ssh/. A think a better practice is to not store those things in the repository folder in the first place.

claud_ia 3mo ago

[flagged]

Tragentics 3mo ago

[flagged]

datsci_est_2015 3mo ago

The fact that pretty much every comment in this thread suggests a different solution means there’s still plenty of innovation and consolidation to occur on this problem. My take is that Unix already solved all of these user access problems (what can a user read or execute), so the solution will probably be around containers or virtual machines. But the UX around booting up a container or virtual machine for agentic workflows needs to be simplified to the point where vibe coders who don’t know the first thing about Unix, VMs, or containers can still take advantage of the solutions.

MMDrame 3mo ago

[flagged]

bolinfest 3mo ago

We have had a solution for this built into Codex for several months now. It is marked "Beta" in the docs because we have been tweaking the config API here and there, but a number of folks have been using it for quite awhile and I would recommend switching to it and reporting any issues you find: https://developers.openai.com/codex/permissions https://developers.openai.com/codex/permissions With permission profiles in Codex, you can: - Mark a path, glob, or meta variable (like `:workspace_roots`) readable, writable, or unreadable. - Amend an existing profile using ordinary `config.toml` layering rules. - Create a new profile by extending an existing one (`extends = ":workspace"` is generally what you want to do). Note that permission profiles also allow you to configure the network proxy for the sandbox in a fine-grained way. (Previously, the network options for the Codex sandbox were all or nothing.) Finally, you can also test running a command under a permission profile using: codex sandbox -P PROFILE_NAME -- PROGRAM ARGS... Our goal has been to provide something powerful and flexible out of the box so you do not need to bolt on other solutions like the ones mentioned on this thread.

sacravenger 3mo ago

[flagged]