›_ Codex Issues
Codex Issues / #14357

Worker spawn inheritance broken: child worker agents do not inherit parent runtime/ network policy

Resolved 💬 5 comments Opened Mar 11, 2026 by alexrwilliam Closed Mar 16, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

0.114.0

What subscription do you have?

pro max

Which model were you using?

5.3 codex x high

What platform is your computer?

Darwin 24.6.0 x86_64 i386

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

_No response_

What issue are you seeing?

Child workers spawned from an unrestricted parent session are running with
CODEX_SANDBOX_NETWORK_DISABLED=1 and CODEX_SANDBOX=seatbelt, causing DNS/network
failures. Parent session remains unrestricted and can resolve/connect normally.

What steps can reproduce the bug?

Uploaded thread: 019cdd84-c60e-7c23-ac40-18f03b46984c

  1. In parent session, run:

cd "/Users/alexwilliamson/Desktop/Development/Genloop/GTG BI AI/MVP"
echo "ROLE=parent"
echo "flag=${CODEX_SANDBOX_NETWORK_DISABLED:-<unset>}"
echo "sandbox=${CODEX_SANDBOX:-<unset>}"
echo "thread=${CODEX_THREAD_ID:-<unset>}"
python3 - <<'PY'
import socket
for h in ["example.com","www.ercot.com","data.sec.gov"]:
try:
print(h, "->", socket.getaddrinfo(h,443)[0][4][0])
except Exception as e:
print(h, "-> ERROR:", e)
PY
curl -I -m 15 https://example.com 2>&1 | head -n 6
curl -I -m 15 https://www.ercot.com 2>&1 | head -n 6
ping -c 1 www.ercot.com 2>&1 | head -n 6

  1. Spawn 2 child agents (agent_type=worker, fork_context=true).
  2. In each child, run the same block but with ROLE=child_1 / ROLE=child_2.

Expected Behavior

  • Children inherit parent runtime/network policy.
  • CODEX_SANDBOX_NETWORK_DISABLED unset in children.
  • DNS resolves (example.com, www.ercot.com).
  • curl and ping resolve/connect.

Actual Behavior

  • Parent passes all criteria.
  • Both children fail all network criteria and show restrictive env:
  • flag=1
  • sandbox=seatbelt
  • DNS errors
  • curl: (6) Could not resolve host
  • ping: cannot resolve ... Unknown host

Validation Matrix

  • Parent status: PASS
  • Child_1 status: FAIL
  • Child_2 status: FAIL
  • Inheritance verdict: FAIL

Worker spawn inheritance is broken in this environment.

———

### Exact outputs (verbatim)

Parent

ROLE=parent
flag=<unset>
sandbox=<unset>
thread=019cdd84-c60e-7c23-ac40-18f03b46984c
example.com -> 2606:4700::6812:1a78
www.ercot.com -> 45.60.45.66
data.sec.gov -> 2600:1404:1200:b8b::2374
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
HTTP/2 200
date: Wed, 11 Mar 2026 16:11:12 GMT
content-type: text/html
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
HTTP/2 200
date: Wed, 11 Mar 2026 16:11:12 GMT
server: Apache
PING x7nzsje.x.incapdns.net (45.60.45.66): 56 data bytes
64 bytes from 45.60.45.66: icmp_seq=0 ttl=55 time=29.247 ms

--- x7nzsje.x.incapdns.net ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 29.247/29.247/29.247/0.000 ms

Child_1

ROLE=child_1
flag=1
sandbox=seatbelt
thread=019cddab-08de-7f41-b88d-3567b1b5c59f
example.com -> ERROR: [Errno 8] nodename nor servname provided, or not known
www.ercot.com -> ERROR: [Errno 8] nodename nor servname provided, or not known
data.sec.gov -> ERROR: [Errno 8] nodename nor servname provided, or not known
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6)
Could not resolve host: example.com
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6)
Could not resolve host: www.ercot.com
ping: cannot resolve www.ercot.com: Unknown host

Child_2

ROLE=child_2
flag=1
sandbox=seatbelt
thread=019cddab-47c9-7801-a706-444b08d148b4
example.com -> ERROR: [Errno 8] nodename nor servname provided, or not known
www.ercot.com -> ERROR: [Errno 8] nodename nor servname provided, or not known
data.sec.gov -> ERROR: [Errno 8] nodename nor servname provided, or not known
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6)
Could not resolve host: example.com
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6)
Could not resolve host: www.ercot.com
ping: cannot resolve www.ercot.com: Unknown host

———

Additional evidence

  • Child session log shows turn_context.sandbox_policy={"type":"danger-full-access"}

while child shell env is sandbox=seatbelt + flag=1:

  • /Users/alexwilliamson/.codex/sessions/2026/03/11/rollout-2026-03-11T11-11-44-

019cddab-08de-7f41-b88d-3567b1b5c59f.jsonl

  • Likely mismatch between configured child policy and execution-time runtime policy

application.

What is the expected behavior?

  • Children inherit parent runtime/network policy.
  • CODEX_SANDBOX_NETWORK_DISABLED unset in children.
  • DNS resolves (example.com, www.ercot.com).
  • curl and ping resolve/connect.

Additional information

_No response_

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 5 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #12996
  • #13373
  • #12919

Powered by Codex Action

alexrwilliam · 5 months ago

This is not a duplicate.

Why this is different:

  • #12996 (Codex.app injecting restricted network access): app-level restricted network

behavior.
This issue reproduces in codex-cli and is specifically about child worker spawn
inheritance.
Core symptom in this issue:

  • Parent and child are in the same run, but child runtime policy does not match parent

policy.

  • Child turn_context reports sandbox_policy={"type":"danger-full-access"}, yet child

shell env is restricted (CODEX_SANDBOX_NETWORK_DISABLED=1, CODEX_SANDBOX=seatbelt)
and DNS fails.

alexrwilliam · 5 months ago

Additional Note. I can confirm this bug was introduced in version 0.113+

I tested on 0.112.0 and got

  • Parent: flag=<unset>, sandbox=<unset>, DNS/curl/ping all pass
  • Child_1: same, all pass
  • Child_2: same, all pass
137alpha · 5 months ago

I reproduced a closely related failure on Linux with codex-cli 0.114.0. The child-agent failure is not a genuine GitHub authentication problem; it is a child-only DNS/network restriction during shell execution.

Observed behavior

A parent session launched with --dangerously-bypass-approvals-and-sandbox successfully ran:

GH_DEBUG=api gh auth status

The parent:

  • made successful live requests to https://api.github.com/
  • received HTTP/2 200 OK
  • reported the configured GitHub accounts as logged in

I then had the parent spawn exactly one explorer child and run the exact same command. The child session metadata still reported:

  • approval_policy: never
  • sandbox_policy: danger-full-access

However, the child command failed at the network layer before reaching GitHub.

Key lines from the child trace:

* Request to https://api.github.com/
...
* dial tcp: lookup api.github.com on 8.8.8.8:53: dial udp 8.8.8.8:53: socket: operation not permitted

This happened twice in the same child run. After that, gh auth status reported the stored tokens as invalid, but that appears to be a downstream symptom of the DNS/network failure rather than the root cause.

Additional confirmation

I also ran a direct env-var probe in parent and child subprocesses.

Parent subprocess:

{"HOME":"..."}

Child subprocess:

{"CODEX_SANDBOX_NETWORK_DISABLED":"1","HOME":"..."}

So in this repro the child shell subprocess is explicitly running with CODEX_SANDBOX_NETWORK_DISABLED=1, while the parent subprocess is not.

Relevant implementation detail

The source suggests a likely mismatch between visible child sandbox metadata and actual child shell runtime behavior:

  • core/src/tools/handlers/multi_agents.rs copies visible runtime sandbox fields from parent turn to child config, including sandbox_policy, file_system_sandbox_policy, and network_sandbox_policy
  • core/src/tools/orchestrator.rs separately computes has_managed_network_requirements from turn_ctx.config.config_layer_stack.requirements_toml().network.is_some()
  • core/src/sandboxing/mod.rs forces a platform sandbox whenever managed network requirements are active
  • core/src/spawn.rs sets CODEX_SANDBOX_NETWORK_DISABLED=1 when the final network_sandbox_policy is restricted

This suggests the child may inherit the parent’s visible danger-full-access policy correctly, while still carrying hidden managed-network requirement state in its config layer stack that causes the actual shell runtime to reintroduce restricted networking underneath.

Summary

This reproduction matches the same core pattern reported here, with explicit network-layer evidence:

  • parent shell execution reaches GitHub successfully
  • child shell execution fails at DNS/UDP
  • child metadata still claims full access

That points to a child runtime/network inheritance bug or to a mismatch between recorded child policy and actual child shell enforcement.

jif-oai contributor · 5 months ago

https://github.com/openai/codex/pull/14650