Testing in sandbox is failing often on OSX (asking for running outside sandbox often).

It seems to be solved by using the linux builds, here's how I did it (for reference):

$ sudo rm /usr/local/bin/node /usr/local/bin/npm
$ curl -fsSL https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.5/install.sh | bash
$  source .zshrc
$  nvm install --lts
$  nvm use --lts

Maybe it would be nice that if codex runs into this issue (it's often testing a lot during iteration and failing) it can suggest solution / pinpoint the problem?

Still getting this though:

│command running...                                                                     ││
│$ bash -lc 'npm test'                                                                  ││
│                                                                                       ││
│event                                                                                  ││
│BackgroundEvent(BackgroundEventEvent { message: "Execution failed: sandbox denied exec ││
│error, exit code: 1, stdout: \n> vibechain@1.0.0 test\n> vitest\n\n\n RUN  v3.2.4      ││
│/Users/mau/Development/vibechain\n\n, stderr: \u{1b}[33mThe CJS build of Vite's Node   ││
│API is deprecated. See                                                                 ││
│https://vite.dev/guide/troubleshooting.html#vite-cjs-node-api-deprecated for more      ││
│details.\u{1b}[39m\n\n⎯⎯⎯⎯ Unhandled Rejection ⎯⎯⎯⎯⎯\nError: kill EPERM\n ❯            ││
│ChildProcess.kill node:internal/child_process:512:26\n ❯ ProcessWorker.terminate       ││
│node_modules/tinypool/dist/index.js:124:16\n ❯ WorkerInfo.destroy                      ││
│node_modules/tinypool/dist/index.js:428:15\n\n⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯\nSerialize││
│d Error: { errno: -1, code: 'EPERM', syscall: 'kill' }\n\n\n\n" })                     ││
│                                                                                       ││
│event                                                                                  ││
│BackgroundEvent(BackgroundEventEvent { message: "retrying command without sandbox" })  ││
│             

I have the same issue. Codex is practically unusable on MacOS because of this.

@stellar-scottreed This works if you know what you're doing $ codex --dangerously-bypass-approvals-and-sandbox

@stellar-scottreed This works if you know what you're doing $ codex --dangerously-bypass-approvals-and-sandbox

It works by allowing codex to run any commands it wants outside of sandbox. Would have to setup a docker sandbox for it because I certainly don't trust it to run any commands it wants on my host machine!

@stellar-scottreed This works if you know what you're doing $ codex --dangerously-bypass-approvals-and-sandbox

So it's acceptable that the only way to codex run shell commands in a way that works (like all similar tools can do) is to completely disable any prompts that would allow you to allow or deny a command before it runs?

In my opinion, the intuitive behavior would be to respect the answer I give to the prompt and actually run it outside the sandbox. I'm not going to enable it to run any arbitrary command without any prompt, and neither should anyone.

> @stellar-scottreed This works if you know what you're doing $ codex --dangerously-bypass-approvals-and-sandbox So it's acceptable that the only way to codex run shell commands in a way that works (like all similar tools can do) is to completely disable any prompts that would allow you to allow or deny a command before it runs? In my opinion, the intuitive behavior would be to respect the answer I give to the prompt and actually run it outside the sandbox. I'm not going to enable it to run any arbitrary command without any prompt, and neither should anyone.

It's not about allowing or denying commands, it's about the commands running in a sandbox. The reason it asks to allow/deny at all is because there is an error every time it tries to run a command within the sandbox.

@stellar-scottreed That's right, it's a temporary work-around, the real problem is getting the sandbox to "just work" identically to your shell. In my experience, as long as you don't tell the model anything that can make it upset 😆 , it won't just do anything dangerous out of nowhere, but the risk is there nevertheless.

> > @stellar-scottreed This works if you know what you're doing $ codex --dangerously-bypass-approvals-and-sandbox > > > So it's acceptable that the only way to codex run shell commands in a way that works (like all similar tools can do) is to completely disable any prompts that would allow you to allow or deny a command before it runs? > In my opinion, the intuitive behavior would be to respect the answer I give to the prompt and actually run it outside the sandbox. I'm not going to enable it to run any arbitrary command without any prompt, and neither should anyone. It's not about allowing or denying commands, it's about the commands running in a sandbox. The reason it asks to allow/deny at all is because there is an error every time it tries to run a command within the sandbox.

What I said is correct if you ignore the implementation details and look at the current behavior. Since I was only trying codex while waiting for my Claude Code credits to recharge, I'm not exactly super invested in the implementation yet. I signed up for a 2nd claude account on a different email so problem solved. For me at least.

I do recommend fixing this problem, since having it be broken (regardless of the whys and hows) out of the box on MacOS may lead to lower adoption. Most people aren't going to look for github issues and leave a comment. I'm doing this for the project's benefit. You should know that for every person commenting there might be hundreds or thousands who will just move on.

Sandboxing on MacOS works like garbage:
1) grep is often timed out and getting repeated multiple times
2) calling build and test do not work most of the time so Codex can't even check if the generated of changed code compiles or works correctly

ATM Codex is the worst of agent CLIs and this should be fixed ASAP.

+1, most of the commands on MacOS just do not work, if they use stuff that is blocked by the sandbox. The thing is, it blocks almost everything, like using ps or killing script's child processes. It's not clear (for me) why it needs to restrict the commands I wrote myself and I already approved to run? Like with other coding agents, you approve a command, and then the agent runs it in your shell. If you don't trust the agent you can configure it to never run commands without approval. But once it's approved, what is the point of not allowing my own scripts to use my own host utilities just because they were started by the agent?

It'd be great to disable sandboxing but still have an option to approve commands the agent wants to run.

I hit this on macOS running Jest integration tests in Codex CLI. By default, Jest runs tests in parallel, and the sandbox can’t keep up—jobs time out. Forcing serial execution avoids the timeouts, though it’s slower (my suite still takes \~5–6 minutes):

jest --runInBand
# or
npm test -- --runInBand

Not a true fix, but it keeps things moving within sandbox limits.

I'm no longer seeing this behavior in the latest version with GPT-5.

It works if you set sandbox mode to at least workspace-write in your Codex config.

I have my sandbox set to - workspace-write but still the sandbox commands just fail with Signal(11)

I'm failing to run tests inside codex, presumably due to some sandbox issues.

stderr = 'error connecting to /var/folders/n7/sg58bw5n6kj3m8j3xq2gk0vr0000gn/T/
tmux_timv1810.sock (No such file or directory)\n'
...
E   subprocess.CalledProcessError: Command '['tmux', '-S', '/var/folders/n7/
sg58bw5n6kj3m8j3xq2gk0vr0000gn/T/tmux_timv1810.sock', 'send-keys', '-t', 'test:', 'cd /
private/.../workmux add feature-worktree > .../workmux_stdout.txt 2> .../workmux_stderr.txt;
echo $? > .../workmux_exit_code.txt', 'C-m']' returned non-zero exit status 1.

Why isn't --yolo enough? Sigh.

i basically create a task for the agent to create a script for npm installs and auto bash command to run once script is created...it therefore runs outside of sandbox for where its blocked (not ideal but just a workaround)

Still hitting this even on basic yarn create next-app and even after trying codex --dangerously-bypass-approvals-and-sandbox