'Full Access' permissions broken -- network calls are still sandboxed

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #18113
• #18675
• #17644

Powered by Codex Action

note that sessions started with --yolo do not have this issue. only ones started without and switched in-session to full access do

I can reproduce what @agjones described: starting Codex with --dangerously-bypass-approvals-and-sandbox works, but switching an existing
session to Full Access does not give equivalent execution permissions.

Environment:

• Codex CLI: codex-cli 0.124.0
• Platform: WSL2, Ubuntu 24.04.4 LTS
• Kernel: 6.6.87.2-microsoft-standard-WSL2
• Workspace path: /mnt/c/Users/user/Work/Local Files/dirname
• Docker: Docker version 28.1.1, build 4eba377
• Subscription: pro
• Model: gpt-5.5

Repro command inside Codex:

docker ps --format '{{.Names}}\t{{.Status}}'

Observed behavior:

When the session is using in-session Full Access, the command fails:

permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock:

Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.49/containers/json":
dial unix /var/run/docker.sock: connect: operation not permitted

Socket/user metadata from the same Codex session:

$ id
uid=1000(my_username) gid=1000(my_username) groups=1000(my_username),65534(nogroup)

$ stat -c '%A %a %U %G %n' /var/run/docker.sock
srw-rw---- 660 nobody nogroup /var/run/docker.sock

$ docker context ls
default *       Current DOCKER_HOST based configuration   unix:///var/run/docker.sock

The process is in the socket’s group (nogroup), so this does not look like ordinary Unix filesystem permission failure. It looks like the command is still being constrained by the sandbox/broker despite Full Access being selected.

Additional signal:

• Running the same Docker command through Guardian approval succeeds.
• Starting Codex directly with --dangerously-bypass-approvals-and-sandbox also works.
• The broken case is specifically the in-session Full Access path.

This makes the issue look like Full Access permission state is reflected in the UI/session policy, but not fully applied to the actual exec sandbox used for tool commands. It also appears related to #19217

Należy pamiętać, że sesje rozpoczęte z opcją --yolo nie mają tego problemu. Problem ten dotyczy tylko sesji rozpoczętych bez opcji i przełączonych w sesji na pełny dostęp.

I can confirm

I can confirm as well. The fix is to run with --yolo for now.

I'm also seeing the same issue with codex CLI v0.124.0 on macOS. Session ID: 019dbdab-ec7d-7a00-9945-e0396df51542.

Setting /approvals to Full Access doesn't work, github.com access is blocked by the proxy and various filesystem writes are also failing (e.g. ~/Desktop/test.txt is blocked).

Same issue here, arrived with v0.124.0, Ubuntu 24.04.
Auto-review seems to be working, but Full Access fails with bwrap: loopback: Failed RTM_NEWADDR.

Same issue, setting to Full Access with /approvals or /permissions doesn't work, the model reports it cannot access the internet or other folders outside of the sandbox.

Confirming this on another Linux setup.

• Codex CLI: codex-cli 0.124.0
• OS: Ubuntu 24.04.4 LTS noble
• Kernel: Linux 6.17.0-22-generic x86_64
• Symptom: switching an existing session to Full Access still leaves exec commands going through bwrap and failing with:

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

• Confirmed in a new session after changing permissions.
• Auto-review/escalated commands work.
• Workaround: adding features.use_legacy_landlock = true to ~/.codex/config.toml makes codex sandbox linux -- /bin/pwd work again.

This looks consistent with Full Access state not being applied to the actual exec sandbox path in 0.124.0.

same issue
/permission full， but still got

  ssh: connect to host github.com port 22: Operation not permitted
  fatal: Could not read from remote repository.

hi, please update to 0.125.0 - the fix was landed a while ago but it didn't make cut for 0.124.0. This should fix the affected cases where a session started in default permissions tries to switch to danger-full-access using /permissions. Sorry for the thrash!