### What version of Codex is running? codex-cli 0.36.0 ### Which model were you using? gpt-5-codex ### What platform is your computer? Darwin 25.0.0 arm64 arm ### What steps can reproduce the bug? 1. Create a simple hello world golang project 2. Tell codex to run `go vet ./...` The command should fail and the model sometimes sets the 'GOCACHE` env var to a directory in the current directory or just tells you to run the command yourself. ### What is the expected behavior? The command sh

`go vet ./...` fails on macOS because `~/Library/Caches` is not allowed to be used in the codex sandbox

Resolved 💬 4 comments Opened Sep 16, 2025 by ZerGo0 Closed Nov 26, 2025

What version of Codex is running?

codex-cli 0.36.0

Which model were you using?

gpt-5-codex

What platform is your computer?

Darwin 25.0.0 arm64 arm

What steps can reproduce the bug?

Create a simple hello world golang project
Tell codex to run go vet ./...

The command should fail and the model sometimes sets the 'GOCACHE` env var to a directory in the current directory or just tells you to run the command yourself.

What is the expected behavior?

The command should run without a problem

What do you see instead?

~/Library/Caches should be on the allowed list on macOS, since Apple recommends that developers use that directory to cache stuff: https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html

Additional information

Current fix:
.zshrc

# Codex go vet ./... fix
export GOCACHE="/tmp/go-cache"

View original on GitHub ↗

4 Comments

ZerGo0 · 11 months ago

I actually don't really mind this sandbox limitation. I actually think that it is good that it works like this, but it would be nice if it at least showed some sort of message to the user that the sandbox prevent a command from running because it tried to access a resource outside the sandbox instead of just showing that red dot/the command just failing.

Because in this case it could be a genuine error or just the sandbox preventing it. Codex sometimes just doesn't tell you.

Meowzz95 · 10 months ago

# Extra settings that only apply when `sandbox = "workspace-write"`.
[sandbox_workspace_write]
# By default, the cwd for the Codex session will be writable as well as $TMPDIR
# (if set) and /tmp (if it exists). Setting the respective options to `true`
# will override those defaults.
exclude_tmpdir_env_var = false
exclude_slash_tmp = false

# Optional list of _additional_ writable roots beyond $TMPDIR and /tmp.
writable_roots = ["/Users/xxxxxxxx/Library/Caches"]

does this work for you? this is found in codex's doc, however it doesn't seem to be working for me... although the purpose of this config looks exactly the same as what we want

Meowzz95 · 10 months ago

Oh I just figured that out. We must set

sandbox_mode = "workspace-write"

at the TOP of the config.toml file (I misplaced it above my sandbox_workspace_write section and it didn't work)

now go test works!

ZerGo0 · 10 months ago

Yes that works, but everyone would have to do this when they work with go. I feel like that's not really user friendly, especially because this is pretty similar to /tmp.