Why sandboxed codex cannot run uv add? Fails on network request to pypi.org

[jsynowiec]

I have a problem with codex in the nono sandbox not being able to fetch packages from pypi.org using uv.

This is my local override. I had to add the ~/.cache/codex-runtimes and ~/.cache/uv. Otherwise it was complaining. The first one, I think, is part of the codex plugins. The latter, the uv cache path, is missing from the python_runtime group.

Also, I had to add two domains: chatgpt.com and ab.chatgpt.com. Otherwise nono was reporting blocked requests.

{
  "extends": [
    "always-further/codex"
  ],
  "meta": {
    "name": "codex",
    "version": "1.0.0",
    "description": "Profile for Codex",
    "author": null
  },
  "filesystem": {
    "allow": [
      "$HOME/.cache/codex-runtimes",
      "$HOME/.cache/uv"
    ]
  },
  "network": {
    "network_profile": "codex",
    "allow_domain": [
      "chatgpt.com",
      "ab.chatgpt.com",
    ]
  }
}

The URL seems to be allowed in the sandbox:

nono why --profile codex --host https://pypi.org/simple/dummy_test/
ALLOWED
  Reason: network_allowed
  Access: Connection to pypi.org:443 would be allowed

And indeed, running uv add dummy_test works

nono run --profile codex --allow-cwd -- uv add dummy_test
...
Resolved 2 packages in 997ms
      Built dummy-test==0.1.3
Prepared 1 package in 91ms
Installed 1 package in 0.74ms
 + dummy-test==0.1.3

or

nono run -v --profile codex --allow-cwd -- /bin/zsh -c 'uv add requests'
Resolved 1 package in 4ms
Uninstalled 5 packages in 6ms
 - certifi==2026.6.17
 - charset-normalizer==3.4.7
 - idna==3.18
 - requests==2.34.2
 - urllib3==2.7.0

However, if I ask codex to add a package using uv, it fails on the network request.

nono run --allow-cwd --profile codex -- codex --sandbox danger-full-access --ask-for-approval on-request exec --skip-git-repo-check "Run the following command, nothing else: `uv add --dev dummt_test`"
...
exec
/bin/zsh -c 'uv add --dev dummt_test' in /Volumes/Storage/workspace/minimal-test
 exited 2 in 6482ms:
error: Request failed after 3 retries in 6.5s
  Caused by: Failed to fetch: `https://pypi.org/simple/dummt-test/`
  Caused by: error sending request for url (https://pypi.org/simple/dummt-test/)
  Caused by: client error (Connect)
  Caused by: tcp connect error
  Caused by: Operation not permitted (os error 1)
codex
`uv add --dev dummt_test` failed while trying to reach PyPI: `Failed to fetch: https://pypi.org/simple/dummt-test/`

And nono reports:

Sandbox blocked system services:
  network-outbound (remote:*:443)

It fails regardless of the package.

Update: I'm running into the same issue when codex is trying to install packages using npm.

nono why --profile codex --host https://registry.npmjs.org
ALLOWED
  Reason: network_allowed
  Access: Connection to registry.npmjs.org:443 would be allowed

However, when codex is executing the npm install, it's failing with EPERM

And nono reports:

Sandbox blocked system services:
  network-outbound (remote:*:443)

Why is that? What am I missing?

Update July 6, 2026:

Both opencode and pi can install packages using npm and uv/pip, so this is something specific to codex and the codex profile.

I asked Codex/GPT-5.5 to self-diagnose, and it returned:

RCA: npm i is not failing because the codex Nono profile denies registry.npmjs.org. It is failing because the commands I run through Codex’s exec_command tool are not actually inside Nono.

Evidence:

nono why --self --host registry.npmjs.org --port 443
NOT SANDBOXED
Not running inside a nono sandbox

At the same time, raw connects from this command process are denied universally:

registry.npmjs.org EPERM
github.com EPERM
api.openai.com EPERM
example.com EPERM
127.0.0.1:9 EPERM

So the failing layer is not the npm registry allowlist. It is the active Codex command runner / macOS sandbox path denying connect(2) before Nono policy matters.

Why nono why --profile codex --host registry.npmjs.org says allowed:

ALLOWED
Reason: network_allowed

That is a static query against the named Nono profile. It does not describe the live process unless the command was launched under nono run/nono wrap. Here it was not.

The decisive mismatch is:

PATH includes: /Users/jakub/.codex/tmp/.../codex-execve-wrapper
codex-execve-wrapper -> /opt/homebrew/bin/codex
nono --self: NOT SANDBOXED

Also, the environment has no proxy variables:

HTTP_PROXY / HTTPS_PROXY / ALL_PROXY / NONO_*: absent

nono run --dry-run --profile codex ... shows that a real Nono launch would apply net proxy, but this Codex exec session did not inject that proxy environment into child commands.

My best current explanation: opencode/pi work because they are launched through their actual Nono runtime path, while this Codex tool session is using Codex’s own command execution sandbox/wrapper. That runner is blocking outbound sockets, and it is not applying the Nono network proxy or the Nono codex profile to the child process.

[jsynowiec]

TLDR; Don't set allow_login_shell = false in Codex when wrapping in nono sandbox or the exec tool will fail on network requests.

---

The issue appears to be the allow_login_shell = false Codex setting.

Codex's allow_login_shell = false appears to change the tool-command launch path so commands are not executed as normal descendants of the nono-launched shell environment.

After setting:

allow_login_shell = false

tool commands no longer appear to run inside nono:

nono why --self --host registry.npmjs.org --port 443

returned:

NOT SANDBOXED
  Not running inside a nono sandbox

Codex diagnostics showed that nono proxy variables were missing:

proxy env vars: none

Codex still reported its own network sandbox as active:

filesystem sandbox: restricted
network sandbox: enabled

This failure mode is confusing because the nono profile can be correct and domains can be allowed, but Codex tool commands still fail because they no longer appears to run in the nono context and disregards the nono proxy.

I don't know if this is a bug in Codex, or an expected behavior.