Live data from Hacker News

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

github.com

111–120 of 157 posts

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

#111

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.

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…

[flagged]

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

#112

Earlier quoted context omitted.

What is your sandbox approach? Any good guides? Something about asking a LLM for advice on how to sandbox LLMs.....

I use this: https://github.com/kstenerud/yoloai yoloai new mysandbox . # Create a sandbox yoloai attach mysandbox # Attach the sandbox to the current terminal ... (^b^d to disconnect) # It's using tmux to keep the agent alive yoloai diff mysandbox # See what the agent did yoloai apply mysandbox # apply its changes to your workdir yoloai destroy sandbox You can also make it run a prompt and block until it's done: yolo…

thanks. I will check that out, I'm also checking out smolvm. Sometimes it is hard to distinguish my modest needs versus what might be needed at a corporate infrastructure level for coding or agent orchestration.

I'm just writing scripts for neuroimaging analysis, etc, and want to ensure codex etc doesn't read my sqlite db or csvs, and send my research data to the inference provider...

Are people using these and interacting with the agent via terminal, or are there fuller cli interfaces, or integrations?

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

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

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

#114

Earlier quoted context omitted.

huh, but what if the AI trashes my git repo? maybe it just deletes the .git folder entirely. a deterministic undo wouldn’t be the silliest feature, for the current definition of “AI”.

The default sandboxing for Codex does not allow the agent to access .git

I think this is what you meant, but just to clarify: it doesn't allow it to write to .git. Read access is allowed.

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

#115
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…

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

That's quite inconvenient. I want to run my coding agent in a restricted version of my regular user context, not something that drives like a separate machine.

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

You have codex run rg in the sandbox, and the sandbox can't read foo. Why is this model so difficult to understand? Codex already runs a variety of commands under a bwrap/seatbelt/etc. sandbox. I've merely extended Codex to run everything in a sandbox. Escalation isn't a matter of whether to run a command in a sandbox or not: it's a matter of which sandbox policy to apply to whatever it is the model asked to do.

> the only solution is to make it so the codex process is unable to access those files

That's not true. Restrictions need apply only to the tools the model runs, not the Codex process itself. You can always insert a process-and-sandbox boundary between the harness and its tools. Codex inserts this boundary most of the time anyway. I've extended my Codex to do it all the time, even for things like the read-a-file tool.

Works fine.

> I imagine this isn't resolved primarily because people expect it to apply to bash tool use,

Yeah? Applying it to the shell tool [1] is trivial. It's actually harder to apply the sandbox to non-shell tools. It just isn't hard conceptually: you define a sandbox policy, writing down what's allowed and not, and just filter everything the model does through this policy via OS-level lightweight sandboxing tools.

Seriously. It's not that hard. And you don't have to sandbox the Codex process itself. I honestly have no idea why people think it's necessary to do so. The model has no ability to make Codex-the-POSIX-process do arbitrary things.

[1] I refuse to call it the "bash tool" when most users are running zsh in it. Name things appropriately.

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

#116
post #9

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

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

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

#117
post #27

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 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 remo…

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 int…

Huh? Blocking sudo works just fine.

I don't know why everyone is acting like sandboxing tool uses is contrary to the laws of God and man and therefore we must adopt devcontainers and VMs and such to run agents.

... Sandboxes work JUST FINE. Seatbelt on macOS is okay. Namespaces/seccomp/etc. work on Linux even better. We already have all the technology we need to do the isolation people are talking about here, and Codex in particular has 99% of the code needed to solve the bug TFA talks about. I have a local patch that solves 100% of it.

      >_ OpenAI Codex (v0.0.0)                     
                                                   
      model:     gpt-5.5 xhigh   /model to change  
      directory: ...

      Ran sudo whoami
        sudo: The "no new privileges" flag is set, which prevents sudo from running as root.
        sudo: If sudo is running in a container, you may need to adjust the container configuration to
        disable the flag.

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

#118

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.

huh, but what if the AI trashes my git repo? maybe it just deletes the .git folder entirely. a deterministic undo wouldn’t be the silliest feature, for the current definition of “AI”.

The answer is the same: You give it either read-only or its own copy separate from the one you care about.

The requested feature wouldn't be a robust solution here either for the same reasons.

Besides, have you noticed the amount of other amateur-hour bugs anf jank in Codex going for weeks or months without proper resolution? Given that, why would you want and trust their solution here over alternatives, specifically?

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

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

We've been using Tenuo which for task-scoped authorization.

Its integration for Claude Code: https://github.com/tenuo-ai/claude-governance

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

#120

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

Back in the day we'd use chroot to achieve something similar

https://linux.die.net/man/1/chroot

Post reply on HN