Linux sandbox blocks local X11 AF_UNIX connect when network_access=false

What version of Codex CLI is running?

codex-cli 0.98.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.3-codex

What platform is your computer?

Linux tp2022 6.12.63+deb13-amd64 x86_64 GNU/Linux (Debian 13), running Codex in a systemd-nspawn container

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

tmux (TERM=tmux-256color, TERM_PROGRAM=tmux), shell: fish

What issue are you seeing?

When Codex sandbox is in workspace-write with network_access=false, commands
that need local AF_UNIX socket connect (example: xdotool -> X11
/tmp/.X11-unix/X0) fail.

Observed error:
Error: Can't open display: (null)
Failed creating new xdo instance

The same command works:
1) directly in the same nspawn container shell
2) in Codex when escalated
3) in Codex when sandbox_workspace_write.network_access=true

What steps can reproduce the bug?

1. Start Codex CLI 0.98.0 on Linux with sandbox mode workspace-write

and network_access=false (default).

1. Ensure DISPLAY and XAUTHORITY are present in shell_environment_policy.
2. Run: xdotool selectwindow
3. Result: fails with "Can't open display: (null)".

Control checks:

• Running xdotool selectwindow directly in container shell works.
• Running Codex with -c sandbox_workspace_write.network_access=true makes

xdotool selectwindow succeed.

What is the expected behavior?

With network_access=false, local AF_UNIX IPC should still work (at least
for allowed local sockets like X11) so xdotool can connect to DISPLAY.

Additional information

Likely code mismatch in rust-v0.98.0:

• Comment says AF_UNIX should be allowed:

codex-rs/linux-sandbox/src/landlock.rs (around line 121)

• But connect(2) is denied unconditionally:

codex-rs/linux-sandbox/src/landlock.rs (around line 135)

This appears to block X11/local UNIX-socket clients when network_access=false.
Workaround: run with -c sandbox_workspace_write.network_access=true.