codex exec with danger-full-access still hits EPERM/loopback restrictions while interactive Codex in same shell succeeds

Summary

codex exec on Linux/WSL2 appears to run commands under materially different runtime restrictions than an interactive codex session, even when both are launched from the same ordinary shell and the exec run is configured with -a never -s danger-full-access.

In the same shell on the same machine:

• direct interactive Codex session: pnpm test:integration passes
• nested non-interactive codex exec --json --output-schema --output-last-message -: the same integration suite fails with EPERM / loopback / interface enumeration / Chromium sandbox errors

This surfaced for me through Taskward, which launches Codex exactly this way for agent execution, but I reproduced it directly without Taskward by invoking codex exec myself.

Environment

• Codex CLI: 0.116.0
• OS: Linux lemnos 6.6.87.2-microsoft-standard-WSL2 x86_64
• Shell: bash
• Launched from a normal shell prompt, not CI

Repro

From a repository that contains an integration suite with local process spawning, localhost binding, and Playwright browser coverage:

codex -a never -s danger-full-access exec \
  --json \
  --output-schema /tmp/final-result.schema.json \
  --output-last-message /tmp/final-result.json \
  -

Prompt:

Run `pnpm test:integration` from the repository root and report whether it passed. Do not modify repository files.

I reproduced this from /home/timoch/taskward.

Expected

If danger-full-access is set, I expect the nested codex exec run to have command/runtime behavior consistent with the interactive Codex session launched from the same shell, or at least for the docs to explain any remaining restrictions.

Actual

The outer codex exec process itself completes and writes JSONL progress plus the sidecar result, but the command it runs fails with permission/runtime errors that do not occur when running the same command directly in the interactive Codex session.

Observed failures inside the nested codex exec run included:

spawnSync /home/timoch/.nvm/versions/node/v22.17.1/bin/node EPERM
uv_interface_addresses returned Unknown system error 1
listen EPERM: operation not permitted 127.0.0.1
sandbox_host_linux.cc:41 ... Operation not permitted (1)

The suite summary from the nested run was:

• 19 failed test files
• 17 passed test files
• 73 failed tests
• 108 passed tests
• 4 skipped tests

Important control case

In this same environment, outside codex exec, I ran the same integration suite directly and it passed:

pnpm test:integration

Result:

• 36 passed test files
• 185 passed tests
• exit code 0

So this does not look like a repository bug. It looks like a behavioral difference in the nested codex exec runtime.

Notes

There is a possibly related issue, but it is narrower in scope:

• #8343 (tsx IPC pipe fails in Codex sandbox with EPERM)

My repro is broader:

• it happens under danger-full-access
• it affects node child process spawning, interface enumeration, localhost listen/bind behavior, and Playwright/Chromium
• it is specifically the difference between interactive Codex and nested codex exec

Question

Is codex exec --sandbox danger-full-access still expected to run commands under a different Linux isolation path than interactive codex? If so, can that behavior be documented? If not, this seems like a bug/regression in the non-interactive execution path.