Andbox networkPolicy.allow does not allow HTTPS curl — proxy CONNECT reset for allowlisted hosts

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

With a workspace .cursor/sandbox.json that allowlists github.com (and related hosts), sandboxed curl https://github.com/ still fails.
Traffic is forced through the local sandbox HTTP proxy (https_proxy=http://127.0.0.1:<port>). The proxy resets the HTTPS CONNECT tunnel for allowlisted hosts.
This is not the auto-run / approval UX issue. The command already runs inside the sandbox without requesting full_network / network. The in-sandbox domain filter does not honor networkPolicy.allow for shell curl.
Related but different: Auto-Run network access `sandbox.json + Defaults` seems to not be working
That thread is about approval when the model requests generic network. Staff said the allowlist is a filter that applies once a command is running. In this case the filter still blocks allowlisted hosts.

Steps to Reproduce

  1. Use a workspace with .cursor/sandbox.json:
{
  "type": "workspace_readwrite",
  "networkPolicy": {
    "default": "deny",
    "allow": [
      "github.com",
      "www.github.com",
      "api.github.com",
      "codeload.github.com",
      "*.githubusercontent.com",
      "registry.terraform.io",
      "releases.hashicorp.com"
    ]
  }
}
Keep Auto-Run / agent policy such that Shell runs in the default sandbox (no required_permissions: ["network"] / ["full_network"] / ["all"]).
Ask the agent (or run in the sandboxed Shell tool):
curl -v --connect-timeout 5 --max-time 15 https://github.com/ -o /dev/null
Also try another allowlisted host:
curl -sS -o /dev/null -w "%{http_code}\n" https://releases.hashicorp.com/
Compare with Cursor WebFetch on https://github.com/ (same allowlist).

### Expected Behavior
curl https://github.com/ succeeds inside the sandbox because github.com is in networkPolicy.allow.
Other allowlisted hosts (e.g. releases.hashicorp.com) also succeed.
Non-allowlisted hosts remain blocked.

With default sandbox proxy env (https_proxy=http://127.0.0.1:<port>):
* Establishing HTTP proxy tunnel to github.com:443
> CONNECT github.com:443 HTTP/1.1
* Recv failure: Connection reset by peer
curl: (56) Recv failure: Connection reset by peer
Allowlisted releases.hashicorp.com also fails (Proxy CONNECT aborted / reset).
Unsetting proxy / --noproxy '*' fails differently: Could not resolve host: github.com (direct DNS blocked; expected if all egress must go through the proxy).
Cursor WebFetch to https://github.com/ succeeds under the same allowlist.
The same curl succeeds only after escalating to full_network (outside the restricted sandbox path).

Proxy-related env in the sandbox includes HTTP(S)_PROXY / http(s)_proxy pointing at 127.0.0.1, plus SOCKS vars.
Failure mode looks like broken/incomplete enforcement of networkPolicy.allow on the HTTPS CONNECT proxy used by Shell, not missing allowlist entries in sandbox.json.




### Operating System
Linux

### Version Information
Version: 3.21.18
VS Code Extension API: 1.128.0
Commit: c4730f7d93d787d9ab120af715999f0345ee5bc0
Date: 2026-09-22T02:04:34.641Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Linux x64 6.8.0-139-generic







### Does this stop you from using Cursor
No - Cursor works, but with this issue
5

Hey @ssmangilev, thanks for the report!

This matches an issue we’ve already reproduced on Ubuntu 24.04. The AppArmor profile that ships with the Cursor .deb (/etc/apparmor.d/cursor-sandbox) blocks the sandbox’s internal connection to its network proxy, so every proxied request gets reset before the allowlist is even checked. That’s why allowlisted hosts fail exactly like blocked ones, while WebFetch (which doesn’t run inside the sandbox) works fine. I’ve added your report to it.

To confirm it’s the same thing on your machine:

  1. Have the agent run the failing curl https://github.com/ once more.
  2. In a regular terminal outside Cursor, run: sudo journalctl -k --since "10 min ago" | grep 'apparmor="DENIED"' | grep cursor_sandbox
  3. If you see a line containing Failed name lookup - disconnected path and sandbox-proxy-http, it’s this issue.

In the meantime, patching the profile fixes it:

sudo cp /etc/apparmor.d/cursor-sandbox /etc/apparmor.d/cursor-sandbox.bak
sudo sed -i -E 's/^(profile [^ ]+ [^ ]+) \{$/\1 flags=(attach_disconnected) {/' /etc/apparmor.d/cursor-sandbox
sudo sed -i 's/^  network inet stream,$/  network inet stream,\n  network inet dgram,\n  network inet6 dgram,/' /etc/apparmor.d/cursor-sandbox
sudo apparmor_parser -r /etc/apparmor.d/cursor-sandbox

Then fully quit and reopen Cursor (a window reload isn’t enough). A Cursor update can reinstall the original profile, so if the resets come back after an update, just re-apply the patch.

Let me know what step 2 shows!