logoalt Hacker News

noveltyaccount • yesterday at 2:53 PM • 1 reply • view on HN

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

Replies

quotemstr • yesterday at 9:06 PM

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.