Restricted Linux sandbox breaks connected Unix socket sends and asyncio wakeups

[everySympathy]

Summary

The restricted Linux network seccomp filter unconditionally denies sendto(2). On Linux, send(2) is implemented as sendto(..., dest_addr = NULL), so this also breaks writes to already-connected Unix-domain sockets.

One visible consequence is that Python asyncio cross-thread wakeups stop working inside the default Codex workspace sandbox. loop.call_soon_threadsafe() writes to asyncio's AF_UNIX wakeup socket; the write receives EPERM, asyncio suppresses that OSError, and the event loop remains asleep.

Reproduction

On current main (315195492c), build Codex and run:

./target/debug/codex sandbox -P :workspace -C /tmp /usr/bin/python3 -c 'import asyncio, threading; loop=asyncio.new_event_loop(); threading.Thread(target=loop.run_forever, daemon=True).start(); print(asyncio.run_coroutine_threadsafe(asyncio.sleep(0, result=42), loop).result(timeout=2))'

Expected:

42

Actual:

TimeoutError

This also causes Daft's native runner to hang on a simple collect() operation.

Isolation

• The same program succeeds outside the Codex sandbox.
• It succeeds with the same bubblewrap filesystem isolation and a full-network Codex profile.
• It succeeds with plain bubblewrap plus --unshare-net.
• It fails only when Codex's restricted network seccomp filter is installed.

Root cause and possible fix

In codex-rs/linux-sandbox/src/landlock.rs, restricted mode unconditionally denies SYS_sendto.

A narrowly scoped fix is to deny sendto only when its fifth argument (dest_addr) is non-null. This permits send() on an already-connected socket, including AF_UNIX socketpairs used for local IPC, while continuing to deny sends to explicit destinations such as unconnected Unix datagram socket paths.

I have a tested patch with regression coverage for both sides of this boundary:

• connected AF_UNIX socket send() succeeds;
• sendto() with an explicit destination still returns EPERM.

The codex-linux-sandbox test suite passes (120/120), and both the minimal asyncio reproducer and the original Daft collect() scenario pass with the patched binary.

[everySympathy]

A tested patch is available here:

• Commit: everySympathy@582a47d
• Branch: https://github.com/everySympathy/codex/tree/codex/fix-seccomp-asyncio-wakeup

I attempted to open a draft PR against openai/codex:main, but GitHub rejected both the GraphQL and REST creation paths for this external account:

GraphQL: everySympathy does not have the correct permissions to execute CreatePullRequest

The branch is ready if a maintainer would like to invite the contribution or pull the commit directly.

[Artem-B]

Additional reproduction through Bun subprocess stdin

I hit the same SYS_sendto denial through Bun's subprocess API. This affects tools that pass input to child processes, not only Python asyncio.

Environment

• Codex CLI: 0.151.0
• Bun: 1.3.6
• OS: WSL2, Linux 6.6.114.1-microsoft-standard-WSL2, x86_64
• Sandbox: managed workspace-write profile with restricted network access

Inside the sandbox, /proc/self/status reports:

NoNewPrivs:      1
Seccomp:         2
Seccomp_filters: 1

Use case

The failure occurred while configuring open-pstack. Its external model runner uses Bun to start Claude Code in print mode and send the prompt through stdin:

const child = Bun.spawn([executable, ...args], {
  stdin: "pipe",
  stdout: "pipe",
  stderr: "pipe",
});

child.stdin.write(prompt);
await child.stdin.end();

Bun represents this stdin connection as a FileSink. The flush performed by FileSink.end() uses send(), which Linux implements as:

sendto(fd, buffer, length, flags, NULL, 0)

Codex rejects the call with EPERM. Claude receives EOF without any prompt bytes and exits with:

Input must be provided either through stdin or as a prompt argument when using --print

The original runner did not await stdin.end(), so it hid the EPERM rejection. Awaiting it reports the sandbox failure but cannot make the write succeed.

Minimal Bun reproduction

Save this as repro.ts:

const child = Bun.spawn(
  [
    "/bin/sh",
    "-c",
    'IFS= read -r line; printf "child read: %s\\n" "$line"',
  ],
  {
    stdin: "pipe",
    stdout: "pipe",
    stderr: "pipe",
  },
);

const written = child.stdin.write("BUN_PIPE_TEST\n");
console.log("write returned:", written);

try {
  await child.stdin.end();
  console.log("stdin.end succeeded");
} catch (error) {
  console.error("stdin.end failed:", error);
}

const exitCode = await child.exited;
const stdout = await new Response(child.stdout).text();
const stderr = await new Response(child.stderr).text();

console.log("exit code:", exitCode);
console.log("stdout:", JSON.stringify(stdout));
console.log("stderr:", JSON.stringify(stderr));

Run it from a Codex shell under the restricted Linux sandbox:

bun repro.ts

Actual result:

write returned: 14
stdin.end failed: EPERM: operation not permitted, send
exit code: 0
stdout: "child read: \n"
stderr: ""

Run the same command in a normal terminal or with danger-full-access.

Expected result:

write returned: 14
stdin.end succeeded
exit code: 0
stdout: "child read: BUN_PIPE_TEST\n"
stderr: ""

A direct syscall control produces the same result:

python3 -c 'import socket; a,b=socket.socketpair(); print(a.send(b"x"))'

Inside the restricted sandbox:

PermissionError: [Errno 1] Operation not permitted

Outside the sandbox:

1

Isolation and workaround

Both of these alternatives work inside the same restricted sandbox:

• Writing with write(2) instead of send(2).
• Supplying the complete input to Bun at spawn time:

const child = Bun.spawn([executable, ...args], {
  stdin: new Blob([prompt]),
  stdout: "pipe",
  stderr: "pipe",
});

Node's child_process stdin pipe also works because it uses the ordinary pipe and write(2) path.

This supports the fix proposed in this issue: permit sendto when dest_addr == NULL and addrlen == 0. That keeps explicit-destination sendto() calls blocked while restoring connected Unix-socket writes used by Bun, Python asyncio,
and other local IPC implementations.

[GustavoDRL]

Codex Linux sandbox: AF_UNIX regression confirmation

Upstream issues: #33793 and #24933

Environment

• Codex CLI: 0.153.4
• OS: Arch Linux / Omarchy
• Kernel: 7.1.9-arch1-2 x86_64
• Python: CPython 3.13.15
• Sandbox: managed workspace-write, network restricted

Actual result inside the sandbox

socket.socketpair(AF_UNIX, SOCK_STREAM) succeeds, but send() on the
connected socket returns PermissionError: [Errno 1] Operation not permitted.
Consequently, asyncio.to_thread() cannot wake the selector during executor
shutdown and asyncio.run() hangs in epoll_wait.

A real pytest invocation hit the same path twice:

tests/test_briefing.py::TestNadaInterrompePorRotina::test_dia_tranquilo_nao_pede_nada

Both hung processes were eventually aborted and recorded by systemd-coredump as
SIGABRT. Their main thread was in epoll_wait; the executor worker was parked
in concurrent.futures.thread._worker.

Control result outside the sandbox

• Minimal asyncio.to_thread(lambda: 42): returns 42 immediately.
• Original affected pytest: 1 passed in 0.10s.
• Entire tests/test_briefing.py: 29 passed in 0.59s.
• No new coredump was created.

Expected boundary

Allow sendto(..., dest_addr = NULL) for already-connected sockets, including
AF_UNIX socketpairs, while continuing to reject sendto() with an explicit
destination. This preserves external-network isolation while restoring local
IPC and asyncio cross-thread wakeups.

Reproducer

Run codex-sandbox-af-unix-regression.py inside and outside the restricted
Linux sandbox. It must finish in under two seconds and print PASS.