codex cli sandbox blocks tokio signal handling on UnixStream/socketpair(AF_UNIX...)

[ahornby]

What version of Codex CLI is running?

0.125.0

What subscription do you have?

Enterprise ChatGPT and api key

Which model were you using?

gpt-5.5

What platform is your computer?

linux Ubuntu 24.04 Linux 6.14.0-37-generic x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

iTerm2 ssh to tmux session on linux

What issue are you seeing?

I can't run programs that use rust tokio signal handling inside sandbox. Noticed it with the rattler-build tool which is a cli build tool used in conda environments, even running rattler-build --version fails

What steps can reproduce the bug?

install rattler-build somewhere, e.g. brew install rattler-build or micromamba create -y -n rattler-build rattler-build

run codex with sandbox enabled:

codex
...
› run in sandbox: /spare/local/ahornby/.micromamba/envs/rattler-build/bin/rattler-build --version

• Ran in the sandbox. It exited with code 1 and printed:

  thread '<unnamed>' (5) panicked at .../tokio-1.51.1/src/signal/unix.rs:71:53:
  failed to create UnixStream: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
  Error:   × Thread panicked

What is the expected behavior?

Expect that rattler-build --version works, e.g.

codex
...
› run in sandbox: /spare/local/ahornby/.micromamba/envs/rattler-build/bin/rattler-build --version

• Ran /spare/local/ahornby/.micromamba/envs/rattler-build/bin/rattler-build --version
  └ (no output)

──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

• rattler-build 0.63.1

socketpair(AF_UNIX, ...) is a common local IPC primitive. Blocking socketpair is probably overly broad if the intent is preventing host socket access. Allowing socketpair(AF_UNIX, ...) while continuing to deny socket(AF_UNIX, ...)/connect/ bind would likely fix Tokio-style internal IPC without reopening the obvious host-UDS bypass.

Additional information

Config used:

model = "gpt-5.5"
model_reasoning_effort = "medium"
approvals_reviewer = "user"

default_permissions = "workspace"

[shell]
program = "/bin/bash"
args = ["--noprofile", "--norc"]

[permissions.workspace.filesystem]
":root" = "read"
":tmpdir" = "write"

[permissions.workspace.filesystem.":project_roots"]
"." = "write"

[permissions.workspace.network]
enabled = true
# full is still filtered by domain but allows POST etc (c.f. limited)
mode = "full"
# needed to resolve local 10.* IPs
allow_local_binding = true

[permissions.workspace.network.domains]
"example.com" = "allow"

[ahornby]

if you are interested in a PR, local fix from ahornby@cb61f48 seems to sort it out.

codex didn't quite one-shot the fix as originally it opened up all socketpair types which was wider than tokio signal handling needed