Linux sandbox blocks AF_UNIX before configured unix_sockets allowlist

What version of Codex CLI is running?

codex-cli 0.147.0

What subscription do you have?

Pro 20X

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Linux 7.0.13+deb13-amd64 x86_64 unknown

Debian 13 (trixie).

What terminal emulator and version are you using?

SSH terminal, TERM=xterm-256color.

Codex doctor report

Relevant redacted fields from codex doctor --json:

{
  "overallStatus": "ok",
  "codexVersion": "0.147.0",
  "config.load": {
    "status": "ok",
    "summary": "config loaded",
    "enabled feature flags": "... network_proxy ...",
    "feature flag overrides": "memories=true, network_proxy=true, prevent_idle_sleep=true"
  },
  "sandbox.helpers": {
    "status": "ok",
    "summary": "sandbox configuration is readable",
    "approval policy": "OnRequest",
    "filesystem sandbox": "restricted",
    "network sandbox": "enabled"
  },
  "runtime.provenance": {
    "platform": "linux-x86_64",
    "version": "0.147.0"
  }
}

The full doctor report is available if needed. It reports all checks as ok and contains no additional sandbox or configuration warning.

What issue are you seeing?

The Linux workspace-write sandbox rejects creation of every AF_UNIX socket with EPERM, even when the exact destination is allowed by features.network_proxy.unix_sockets.

The rejection occurs during socket(AF_UNIX, SOCK_STREAM, 0), before connect() receives the configured path. The Unix-socket allowlist therefore cannot take effect.

This prevents PostgreSQL/libpq and Redis clients from using explicitly allowed local Unix sockets. The same PostgreSQL connection succeeds outside the Codex sandbox.

The project configuration is loaded. Its HTTP domain policy takes effect, and codex doctor reports network_proxy=true. This is not a stale session or a managed configuration override.

What steps can reproduce the bug?

Configure workspace-write networking and an exact Unix socket:

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true

[features.network_proxy]
enabled = true
dangerously_allow_all_unix_sockets = false

[features.network_proxy.unix_sockets]
"/var/run/postgresql/.s.PGSQL.5432" = "allow"

Restart Codex, then run this through a normal sandboxed shell tool call:

import socket

for family, name in [
    (socket.AF_UNIX, 'AF_UNIX'),
    (socket.AF_INET, 'AF_INET'),
    (socket.AF_INET6, 'AF_INET6'),
]:
    try:
        sock = socket.socket(family, socket.SOCK_STREAM)
    except OSError as e:
        print('%s create errno=%r strerror=%r' % (name, e.errno, e.strerror))
        continue
    print('%s create ok' % name)
    sock.close()

Actual output:

AF_UNIX create errno=1 strerror='Operation not permitted'
AF_INET create ok
AF_INET6 create ok

The configured socket is present inside the sandbox:

srwxrwxrwx ... /var/run/postgresql/.s.PGSQL.5432

But a sandboxed readiness check fails:

$ pg_isready -h /var/run/postgresql -p 5432
/var/run/postgresql:5432 - no response

The identical command outside the sandbox succeeds:

/var/run/postgresql:5432 - accepting connections

A Django/libpq query outside the sandbox also succeeds and returns the expected database and user. Inside the sandbox it fails with psycopg.OperationalError: connection is bad: no error details available.

What is the expected behavior?

When an exact path is allowed under features.network_proxy.unix_sockets, sandboxed processes must be able to create an AF_UNIX socket and connect to that allowed path. Other Unix-socket paths should remain denied.

At minimum, Codex should not advertise or accept a Unix-socket allowlist in a Linux restricted profile that unconditionally blocks socket(AF_UNIX, ...) before evaluating the destination.

Additional information

The configuration reference documents features.network_proxy.unix_sockets as the Unix-socket policy for sandboxed networking:

https://developers.openai.com/codex/config-reference

This differs from #16910, which requests sandbox-local Unix socket IPC. This report concerns connecting to an explicitly allowed host socket through the documented network proxy policy.

It also differs from #33793, which concerns sendto(2) on already-connected Unix sockets. This failure happens earlier, while creating the socket.