Windows Codex app: npm/network DNS fails in sandbox despite network enabled; cannot reach local proxy

Open 💬 6 comments Opened Apr 20, 2026 by re-gion

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On Windows, commands run from the Codex app cannot resolve DNS or install npm packages, even though the host PowerShell can run npm normally. The failure persists across workspace-write with sandbox_workspace_write.network_access = true and Full Access / danger-full-access mode.

The current evidence suggests a Codex Windows sandbox/network isolation issue rather than an npm registry, TLS, or package install-script problem.

Environment

OS: Windows 10.0.26200
Codex app package observed in PATH: OpenAI.Codex_26.415.4716.0_x64__2p2nqsd0c76g0
Shell: PowerShell
Node: v22.19.0
npm: 10.9.3
npm registry: https://registry.npmmirror.com
npm proxy: null
npm https-proxy: null
Project trusted in config
Tested sandbox modes:
workspace-write with [sandbox_workspace_write] network_access = true
Full access / danger-full-access
Approval policy: never

Redacted config shape

model = "gpt-5.4"
model_reasoning_effort = "high"
sandbox_mode = "workspace-write" # also tested full access / danger-full-access
approval_policy = "never"

[shell_environment_policy]
inherit = "core"

[sandbox_workspace_write]
network_access = true

[shell_environment_policy.set]
APPDATA = "C:\\Users\\user\\AppData\\Roaming"
LOCALAPPDATA = "C:\\Users\\user\\AppData\\Local"
USERPROFILE = "C:\\Users\\user"
HOME = "C:\\Users\\user"
TEMP = "C:\\Users\\user\\AppData\\Local\\Temp"
TMP = "C:\\Users\\user\\AppData\\Local\\Temp"
NPM_CONFIG_CACHE = "D:\\a311\\系统赛\\2026系统赛\\信安\\.npm-cache"
# Anthropic/OpenAI-compatible API credentials omitted/redacted

[windows]
sandbox = "elevated"

Expected behavior

From a Codex shell with network access enabled, npm should be able to resolve the configured registry and install a simple package such as lodash, or at least connect to the host's configured local proxy when explicitly configured.

Actual behavior

Host PowerShell works

The user's normal PowerShell reports:

npm config get registry  # https://registry.npmmirror.com
npm config get proxy     # null
npm config get https-proxy # null
npm ping                 # succeeds, PONG around 176ms
node -v                  # v22.19.0
npm -v                   # 10.9.3

The host also has a local proxy listening on port 7897:

TCP    0.0.0.0:7897    0.0.0.0:0    LISTENING    <pid>
TCP    [::]:7897       [::]:0       LISTENING    <pid>

Codex shell fails DNS resolution

In the Codex shell:

const dns = require('node:dns');
console.log('servers', dns.getServers());
for (const host of ['registry.npmmirror.com','registry.npmjs.org','github.com']) {
  dns.lookup(host, (err, address, family) => {
    console.log(host, err ? ('ERR ' + err.code + ' ' + err.message) : ('OK ' + address + ' IPv' + family));
  });
}
setTimeout(() => {}, 1000);

Output:

servers [ '223.5.5.5', '223.6.6.6', '198.18.0.2' ]
registry.npmmirror.com ERR EAI_FAIL getaddrinfo EAI_FAIL registry.npmmirror.com
registry.npmjs.org ERR EAI_FAIL getaddrinfo EAI_FAIL registry.npmjs.org
github.com ERR EAI_FAIL getaddrinfo EAI_FAIL github.com

npm ping --verbose fails with:

npm notice PING https://registry.npmmirror.com/
npm http fetch GET https://registry.npmmirror.com/-/ping attempt 1 failed with EAI_FAIL
npm http fetch GET https://registry.npmmirror.com/-/ping attempt 2 failed with EAI_FAIL
npm http fetch GET https://registry.npmmirror.com/-/ping attempt 3 failed with EAI_FAIL
npm error code EAI_FAIL
npm error syscall getaddrinfo
npm error network request to https://registry.npmmirror.com/-/ping failed, reason: getaddrinfo EAI_FAIL registry.npmmirror.com

npm install lodash --verbose --no-audit --no-fund fails before package metadata is fetched:

npm http fetch GET https://registry.npmmirror.com/npm attempt 1 failed with EAI_FAIL
npm http fetch GET https://registry.npmmirror.com/lodash attempt 1 failed with EAI_FAIL
...
npm error network request to https://registry.npmmirror.com/lodash failed, reason: getaddrinfo EAI_FAIL registry.npmmirror.com

npm install esbuild --verbose --no-audit --no-fund fails the same way, before any secondary binary download is reached.

Local proxy is not reachable from Codex shell

The host proxy is listening on 7897, but the Codex shell cannot connect to it:

127.0.0.1 ERROR UNKNOWN connect UNKNOWN 127.0.0.1:7897 - Local (undefined:undefined)
172.17.132.84 ERROR UNKNOWN connect UNKNOWN 172.17.132.84:7897 - Local (undefined:undefined)

When HTTP_PROXY and HTTPS_PROXY are set manually inside the Codex shell:

$env:HTTP_PROXY='http://127.0.0.1:7897'
$env:HTTPS_PROXY='http://127.0.0.1:7897'
npm ping --verbose

The failure changes from DNS EAI_FAIL to proxy connection failure:

reason: connect UNKNOWN 127.0.0.1:7897 - Local (undefined:undefined)

This suggests npm obeys the explicit proxy env vars, but Codex cannot reach the host-local proxy endpoint.

Additional observations

In workspace-write, the shell cwd appears under C:\Users\CodexSandboxOnline\.codex\.sandbox\cwd\....
In Full Access / danger-full-access, the environment variables from shell_environment_policy.set are correctly injected:
APPDATA=C:\Users\user\AppData\Roaming
LOCALAPPDATA=C:\Users\user\AppData\Local
NPM_CONFIG_CACHE=...\.npm-cache
Full Access fixes npm cache/log path issues, but DNS still fails with EAI_FAIL.
With Clash TUN enabled, route/DNS state changes are visible in Codex (198.18.0.2 appears), but DNS resolution still fails.
Toggling TUN on/off, enabling global proxy mode, changing TUN MTU to 1500, switching between workspace-write and Full Access, and setting network_access = true did not restore npm networking.

Why this looks like a Codex Windows networking issue

The same Node/npm versions and npm registry settings work in the user's normal PowerShell. In the Codex shell, DNS fails for multiple unrelated domains and direct connections to the host's local proxy also fail. The failure happens before npm can reach package metadata or any install-script secondary download.

Request

Please investigate Codex app on Windows sandbox networking / DNS / host-local proxy access. Specifically:

Why does DNS resolution return EAI_FAIL in Codex shells when the host PowerShell can resolve and npm ping succeeds?
Why can the host connect to 127.0.0.1:7897, while the Codex shell cannot connect to 127.0.0.1:7897 or the host LAN IP 172.17.132.84:7897?
Is there a supported config option to allow Codex Windows sandbox sessions to use host system proxy / local loopback proxy?
Is [sandbox_workspace_write] network_access = true expected to work in the Windows app, and does it cover DNS plus host-local proxy access?

Sensitive tokens and API credentials have been omitted from this report.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 3 months ago

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

#18647

Powered by Codex Action

mickitty0511 · 3 months ago

I've been encountering this issue since one or two months ago. can't endure it when my workloads get heavier. hope it will solve quickly.

re-gion · 2 months ago

I have a practical Windows workaround that is now working reliably for me. Sharing it here in case it helps others until the Codex App Windows sandbox networking behavior is fixed.

Environment / symptom

Codex App on Windows: 26.422.2339.0
The problem can affect both Windows-native PowerShell/CMD sessions and WSL2/Linux sessions launched by Codex.
Host Windows PowerShell can access npm normally (npm ping succeeds).
Commands launched by Codex inside the sandbox may fail to access the network, even though the same command works in the user's own terminal.

In one affected WSL2/Linux Codex session, the spawned command was clearly running under:

codex-linux-sandbox
sandbox type: workspace-write
network_access: false
network-sandbox-policy: restricted

This was true even though my ~/.codex/config.toml contained settings such as:

sandbox_mode = "danger-full-access"
network_access = "enabled"

[sandbox_workspace_write]
network_access = true

So the important point is not only WSL2. The broader issue is that the Codex Windows app sandbox can prevent network access for commands that would otherwise work in the normal Windows terminal environment.

What failed inside the sandbox

Running npm directly inside the Codex sandbox failed before package installation logic or postinstall scripts were reached:

npm ping -> getaddrinfo EAI_AGAIN registry.npmjs.org
npm install lodash -> getaddrinfo EAI_AGAIN registry.npmjs.org
npm install esbuild -> getaddrinfo EAI_AGAIN registry.npmjs.org

Manually injecting my local proxy inside the sandbox also failed in that session:

HTTP_PROXY=http://127.0.0.1:7897 HTTPS_PROXY=http://127.0.0.1:7897 npm ping
-> connect EPERM 127.0.0.1:7897 - Local

So this does not look like an npm package issue, an esbuild/sharp binary-download issue, or a TLS certificate issue. The failure happens at the registry/DNS/proxy-access layer inside the Codex sandbox.

Windows-wide workaround that works

For network-dependent commands, run only that command outside the Codex sandbox instead of retrying inside the restricted sandbox.

For Windows-native PowerShell/CMD commands, run the command in the host Windows environment, where normal Windows proxy/network settings apply. Example:

npm ping
npm install
pip install <package>
git fetch

For WSL2/Linux commands, run the command outside the Codex sandbox and explicitly inject the Windows local proxy if needed:

HTTP_PROXY=http://127.0.0.1:7897 \
HTTPS_PROXY=http://127.0.0.1:7897 \
npm install

The proxy port may differ for other users. In my case the Windows local proxy was listening on 127.0.0.1:7897.

With this approach, all of the following succeeded after being run outside the Codex sandbox:

Windows PowerShell npm ping -> OK
WSL2/Linux npm ping with explicit proxy -> OK
WSL2/Linux npm install lodash --prefix /tmp/codex-net-ok-lodash -> OK
WSL2/Linux npm install esbuild --prefix /tmp/codex-net-ok-esbuild -> OK
esbuild postinstall -> code 0

Recommended operational pattern

The safest pattern for now is:

Keep normal read/search/edit/static-check commands inside the Codex sandbox.
Use an out-of-sandbox/elevated command only for network-dependent steps, such as npm install, pip install, git fetch/pull/push, dependency downloads, or external API calls.
If the command is Windows-native, run it in the host PowerShell/CMD environment.
If the command is WSL2/Linux-based, run it outside the Codex sandbox and explicitly set the proxy when needed:

HTTP_PROXY=http://127.0.0.1:7897 HTTPS_PROXY=http://127.0.0.1:7897

After the network command finishes, return to normal sandboxed execution for non-network work.
Verify with a minimal read-only probe first, for example:

npm ping
curl -I https://registry.npmjs.org/

This is a Windows Codex sandbox networking workaround, not a WSL2-only workaround. WSL2 was just the environment used in my latest reproduction; the same operational pattern applies to native PowerShell/CMD tasks on Windows as well.

mickitty0511 · 2 months ago

I have a practical Windows workaround that is now working reliably for me. Sharing it here in case it helps others until the Codex App Windows sandbox networking behavior is fixed. ## Environment / symptom Codex App on Windows: 26.422.2339.0 The problem can affect both Windows-native PowerShell/CMD sessions and WSL2/Linux sessions launched by Codex. Host Windows PowerShell can access npm normally (npm ping succeeds). Commands launched by Codex inside the sandbox may fail to access the network, even though the same command works in the user's own terminal. In one affected WSL2/Linux Codex session, the spawned command was clearly running under: `` codex-linux-sandbox sandbox type: workspace-write network_access: false network-sandbox-policy: restricted ` This was true even though my ~/.codex/config.toml contained settings such as: sandbox_mode = "danger-full-access" network_access = "enabled" [sandbox_workspace_write] network_access = true So the important point is not only WSL2. The broader issue is that the Codex Windows app sandbox can prevent network access for commands that would otherwise work in the normal Windows terminal environment. ## What failed inside the sandbox Running npm directly inside the Codex sandbox failed before package installation logic or postinstall scripts were reached: ` npm ping -> getaddrinfo EAI_AGAIN registry.npmjs.org npm install lodash -> getaddrinfo EAI_AGAIN registry.npmjs.org npm install esbuild -> getaddrinfo EAI_AGAIN registry.npmjs.org ` Manually injecting my local proxy inside the sandbox also failed in that session: ` HTTP_PROXY=http://127.0.0.1:7897 HTTPS_PROXY=http://127.0.0.1:7897 npm ping -> connect EPERM 127.0.0.1:7897 - Local ` So this does not look like an npm package issue, an esbuild/sharp binary-download issue, or a TLS certificate issue. The failure happens at the registry/DNS/proxy-access layer inside the Codex sandbox. ## Windows-wide workaround that works For network-dependent commands, run only that command outside the Codex sandbox instead of retrying inside the restricted sandbox. For Windows-native PowerShell/CMD commands, run the command in the host Windows environment, where normal Windows proxy/network settings apply. Example: npm ping npm install pip install <package> git fetch For WSL2/Linux commands, run the command outside the Codex sandbox and explicitly inject the Windows local proxy if needed: HTTP_PROXY=http://127.0.0.1:7897 \ HTTPS_PROXY=http://127.0.0.1:7897 \ npm install The proxy port may differ for other users. In my case the Windows local proxy was listening on 127.0.0.1:7897. With this approach, all of the following succeeded after being run outside the Codex sandbox: ` Windows PowerShell npm ping -> OK WSL2/Linux npm ping with explicit proxy -> OK WSL2/Linux npm install lodash --prefix /tmp/codex-net-ok-lodash -> OK WSL2/Linux npm install esbuild --prefix /tmp/codex-net-ok-esbuild -> OK esbuild postinstall -> code 0 ` ## Recommended operational pattern The safest pattern for now is: 1. Keep normal read/search/edit/static-check commands inside the Codex sandbox. 2. Use an out-of-sandbox/elevated command only for network-dependent steps, such as npm install, pip install, git fetch/pull/push`, dependency downloads, or external API calls. 3. If the command is Windows-native, run it in the host PowerShell/CMD environment. 4. If the command is WSL2/Linux-based, run it outside the Codex sandbox and explicitly set the proxy when needed: HTTP_PROXY=http://127.0.0.1:7897 HTTPS_PROXY=http://127.0.0.1:7897 5. After the network command finishes, return to normal sandboxed execution for non-network work. 6. Verify with a minimal read-only probe first, for example: npm ping curl -I https://registry.npmjs.org/ This is a Windows Codex sandbox networking workaround, not a WSL2-only workaround. WSL2 was just the environment used in my latest reproduction; the same operational pattern applies to native PowerShell/CMD tasks on Windows as well.

@re-gion thanks, wow... will try it!

mickitty0511 · 2 months ago

Thank you for your workaround tips!
As I looked over my logs in codex, I found executing commands out of sandboxes was what my Codex always does.
Yeah, nothing new was found for me, so still hope this issue will be fixed asap.

proto-git · 2 months ago

Evidence on my end if a maintainer finds it useful:

```Host PowerShell:
npm ping -> PONG
Invoke-WebRequest https://registry.npmjs.org/typescript -> 200
nslookup registry.npmjs.org -> resolves

Codex shell:
npm ping -> timeout
node dns.lookup("registry.npmjs.org") -> EAI_FAIL
cmd /c nslookup registry.npmjs.org -> no response from same DNS server
npm config proxy/https-proxy -> null
sandbox_mode = danger-full-access
network access enabled