Description

After applying the pypi network policy preset via nemoclaw policy-add, GET requests to pypi.org and files.pythonhosted.org from inside the sandbox still fail with HTTP code 000 (blocked), and only succeed after manual approval in the OpenShell terminal. The preset alone does not open the expected egress, although POST to pypi.org correctly remains blocked with 403.

Component area: Security (network policy) / Policy&Network.

Environment

Platforms verified: WSL2 (Ubuntu 22.04 in WSL2 on Windows), DGX Spark, Ubuntu 26.04
openshell:          0.0.39
nemoclaw:           v0.0.48
docker:             29.4.3
node:               v22.22.3
npm:                10.9.8
OpenClaw:           2026.4.24 (cbcfdf6)

Steps to Reproduce

Pre-condition: NemoClaw has been successfully onboarded against any cloud provider and at least one sandbox is running, with no extra policy presets applied yet.

On the host:

# 1. Add the pypi preset
nemoclaw policy-add
# 2. In the interactive menu, select "pypi"
# 3. Confirm application
# 4. Connect to the sandbox
nemoclaw connect

Inside the sandbox shell:

# 5. Test GET to pypi.org
curl -s -o /dev/null -w "%{http_code}" --max-time 10 https://pypi.org/simple/requests/

# 6. (Optional) Test GET to files.pythonhosted.org
curl -s -o /dev/null -w "%{http_code}" --max-time 10 https://files.pythonhosted.org/rg/

# 7. Test POST to pypi.org (should remain blocked)
curl -s -o /dev/null -w "%{http_code}" -X POST --max-time 10 https://pypi.org/simple/le/

Important: All three commands above are run WITHOUT approving any network prompts in the OpenShell terminal. This test validates the behavior of the pypi preset alone, not runtime approvals.

Expected Result

With the pypi preset applied:

• Interactive preset selection is shown when running nemoclaw policy-add.
• The pypi preset is applied successfully to the sandbox policy.
• nemoclaw connect succeeds.
• GET to https://pypi.org/simple/requests/ succeeds (returns 200 or other valid HTTP status) under the preset alone — no manual OpenShell approval needed.
• GET to https://files.pythonhosted.org/... also succeeds (returns a valid HTTP status) under the preset alone.
• POST to pypi.org remains blocked (e.g., 403 or a policy error), because the preset is intended to be GET-only.

This case validates network policy egress only and must NOT rely on pip install behavior, because pip may fail for environment reasons unrelated to network access.

Actual Result

Inside the sandbox, with the pypi preset applied and no OpenShell terminal approvals:

sandbox@16e7a8836031:~$ curl -s -o /dev/null -w "%{http_code}" --max-time 10 https://pypi.org/simple/requests/
000
sandbox@16e7a8836031:~$ curl -s -o /dev/null -w "%{http_code}" --max-time 10 https://files.pythonhosted.org/rg/
000
sandbox@16e7a8836031:~$ curl -s -o /dev/null -w "%{http_code}" -X POST --max-time 10 https://pypi.org/simple/le/
403

Observed behavior:

• GET to https://pypi.org/simple/requests/ returns 000 (no response / blocked) even after applying the pypi preset.
• GET to https://files.pythonhosted.org/rg/ returns 000 (no response / blocked) under the same conditions.
• POST to https://pypi.org/simple/le/ returns 403 as expected.

If the same GETs are then manually approved in the OpenShell terminal (OpenShell TUI), subsequent requests return a real HTTP status (e.g., 200), confirming that the underlying connectivity works and that the blockage is due to policy, not network or DNS. However, this test is meant to validate the pypi preset alone, without relying on per-request approvals.

The pypi preset does not currently grant the expected GET access on its own and effectively requires interactive approvals to behave as described in the test plan.

Logs

No additional logs captured beyond the curl output in Actual Result above.