The agent will not run the curl apache.org command when ‘Auto-Run in Sandbox’ is set, and the network access setting is sandbox.json + Defaults. I would expect it would run because apache.org is in the default domains.
The agent will run curl apache.org when the Auto-Run network access setting is set to Allow All
Steps to Reproduce
Set the same Auto-Run settings, do not have a sandbox.json defined, do not have the curl command on the allow list. Ask the agent to run curl apache.org
Expected Behavior
I expect the agent to run the command since apache.org is in the list of Default domains
Hey, thanks for the detailed report. I can reproduce it.
In short: the sandbox.json + Defaults mode controls network filtering inside the sandbox which domains are allowed while the command is running, but it does not affect the auto-run or approval decision. The model, in the shell tool call, requests a generic network permission without knowing which specific domains are in the default allowlist. The system treats that as an escalation beyond your configured policy where networkAccess: false and asks for approval. In Allow All mode, the policy already allows full network access, so it matches and auto-runs.
So yeah, the UX is confusing. The name Defaults suggests commands to default domains should auto-run, but this toggle is about something else.
Workarounds:
Use Allow All if you’re OK with unrestricted network access inside the sandbox.
Add the needed commands like curl apache.org to the command allowlist. Then auto-run will work regardless of the network policy.
I logged this as a UX gap so the team can consider auto-resolving approval when the target domain is already in the merged allowlist. I can’t share an ETA for a fix yet.
The model requests a network permission, before it attempts to run curl. This is treated as an escalation beyond the networkAccess: false policy that is in place when the sandbox.json + Defaults mode is chosen. That makes sense.
So what is the purpose of the defaults? Is that used when the model does not request a network permission, but runs a command that does attempt to access a domain, and that is then potentially blocked based on the sandbox.json + Defaults settings?
I also was attempting to get the agent to run gh pr list, I had whitelisted the api.github.com domain in sandbox.json but it would not auto-run that command. (I realize that a github mcp server is likely preferred, but I was just using this as a test to understand the sandbox better).
Defaults and allowlist are a network filter inside the sandbox. Once a command is already running, it controls which domains it can reach over the network. This is a separate layer from auto-run approval, which decides whether Cursor should ask you before running the command at all.
The approval decision happens earlier. It compares the requested permissions from the tool call with your configured policy. In a shell tool call, the model requests a generic network permission with no specific domain, which is the same as networkAccess: true. Your policy in sandbox.json + Defaults mode is networkAccess: false plus an allowlist. The model request is broader than your policy, so it counts as an escalation and triggers a prompt.
When in-sandbox filtering is the part that matters:
The command is already in the command allowlist so auto-run happens with no network question, but during execution it tries to use the network. Then the sandbox network filter decides which domains to allow.
The command spawns subprocesses or has side network calls like a package manager downloading dependencies. Those are also filtered by the allowlist.
The gh pr list case is exactly the same as curl apache.org. The model requests generic network, and your allowlist for api.github.com does not help because the approval gate runs before the command reaches the network filter. Same workaround. Add gh pr list or gh with the right pattern to the command allowlist. Then auto-run will pass, and the network filter will allow access to api.github.com based on your sandbox.json.