Automations fail with DNS resolution

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

• #15310
• #15878
• #15875

Powered by Codex Action

The subject of "Automations failing" is common with the potential duplicates, but none of them are talking about failed DNS resolutions, so I believe this issue is not a duplicate.

Same issue. tried:

• out of sandbox: ok
• full access: ok
• workspace-write: fail

added:
[sandbox_workspace_write]
network_access = true

as per docs, still the same issue

Yes, the Codex app local cron automations seem to ignore workspace-write network access config.

A local Codex cron automation appears to launch with network access disabled even when the user config enables network access for workspace-write sandboxes.

The same network probe succeeds in a normal Codex thread, but fails inside a Codex app local cron automation during DNS resolution.

This suggests the automation runner is not inheriting or applying [sandbox_workspace_write].network_access = true, or there is no exposed per-automation network setting.

So, expected behavior:
A local cron automation running under workspace-write should either:

1. inherit [sandbox_workspace_write].network_access = true, or
2. expose a per-automation network access option, or
3. clearly document that cron automations always run with network disabled.

Actual behavior:
The automation session launches with network access restricted. Network/DNS calls fail inside the automation with:
socket.gaierror: [Errno 8] nodename nor servname provided, or not known

This is still happening on Version 26.415.20818 (1727)

Still reproducible on version 26.415.40636 (1799)

Just have some script like:

#!/usr/bin/env bash
set -euo pipefail

python3 - <<'PY'
import socket
import urllib.request

print("probe=codex-network")

for host in ("example.com", "openai.com"):
    result = socket.getaddrinfo(host, 443)[0][4][0]
    print(f"dns_ok {host} {result}")

response = urllib.request.urlopen("https://example.com", timeout=10)
print(f"https_status={response.status}")
PY

And from a normal Codex thread, you get:

probe=codex-network
dns_ok example.com ...
dns_ok openai.com ...
https_status=200

While, if you create an automation with a prompt to run the script, you get:

probe=codex-network
Traceback (most recent call last):
  File "<stdin>", line 7, in <module>
  File ".../socket.py", line 983, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno 8] nodename nor servname provided, or not known

This is still happening with the latest Codex (Mac Version 26.707.31428). Specifically, I updated and restarted Codex and in a new thread I asked it to run the following in a shell and return the output:

echo $CODEX_SANDBOX_NETWORK_DISABLED
curl -I https://www.google.com

The output returned was:

$ echo $CODEX_SANDBOX_NETWORK_DISABLED
1

$ curl -I https://www.google.com
curl: (6) Could not resolve host: www.google.com

So it appears that there is a problem running tasks (and scheduled automations). I'm not sure how these tasks have been able to run previously; I've been running into this issue off and on for the past few weeks but it had to work sometimes to create the automation in the first place.Is this a known issue (obviously I'm not the only person running into it)? Is there any workaround besides setting the sandbox to full access (which I don't wish to do)?