CLI allowlist cannot auto-approve deleteToolCall or WebFetch (skipApproval stays false; print mode User Rejected)

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Under approvalMode: "allowlist", there is no documented config that auto-approves native Delete (deleteToolCall) or WebFetch. Headless agent --print maps the missing approval to User Rejected.

permissions.json only documents terminalAllowlist, mcpAllowlist, and autoRun. Native Delete is not a shell command and is not an MCP server:tool from mcp.json, so that file cannot express deleteToolCall. Unknown keys are ignored.

~/.cursor/cli-config.json permissions.allow tokens WebFetch(*), Delete(*), Delete(**), Write(**), Mcp(cursor:*), CallDynamicTool(*) do not set skipApproval: true on webFetchRequestQuery. autoAcceptWebSearch: true does auto-approve WebSearch. approvalMode: "unrestricted" auto-approves Delete (CallDynamicTool / cursor.Delete returned Successfully deleted file: …) but WebFetch still comes back User Rejected.

This looks like the same class of gap as ACP WebSearch never being pre-approvable, except here WebSearch does work via autoAcceptWebSearch, while Delete/WebFetch have no equivalent.

Steps to Reproduce

  1. macOS, Cursor CLI 2026.09.18-9a7762b, Enterprise, approvalMode: "allowlist", sandbox.mode: "disabled".
  2. In ~/.cursor/cli-config.json set:
    • "permissions": { "allow": ["WebFetch(*)", "WebSearch", "Delete(**)", "Write(**)", "Mcp(cursor:*)", "CallDynamicTool(*)"], "deny": [] }
    • "autoAcceptWebSearch": true
    • "webFetchDomainAllowlist": ["*", "example.com"] (also reproduced with [])
  3. Run (no --force / --yolo):
agent --print --stream-partial-output --output-format stream-json --trust --workspace /tmp/cursor-cli-perm-verify --sandbox disabled \
  "Call WebFetch on https://example.com then stop."
  1. Separately, ask the agent to use native Delete (not Shell/rm) on a file in that workspace.

Expected Behavior

  • WebFetch(*) and/or webFetchDomainAllowlist should auto-approve https://example.com (skipApproval: true).
  • There should be a documented allow token for native deleteToolCall (or permissions.json should grow a native-tool allowlist). Headless --print should not invent User Rejected when no TTY exists.

Actual Behavior
WebFetch stream-json:

{"type":"interaction_query","query_type":"webFetchRequestQuery",
 "query":{"webFetchRequestQuery":{"args":{"url":"https://example.com"},"skipApproval":false}}}
{"type":"interaction_query","response":{"webFetchRequestResponse":{"rejected":{"reason":"User Rejected"}}}}

Delete under allowlist: denied / missing as a built-in (only available as dynamic cursor.Delete). Under approvalMode: "unrestricted", the same CallDynamicTool Delete succeeds (Successfully deleted file: /tmp/cursor-cli-perm-verify/to-delete.txt (10 bytes)). WebSearch succeeds throughout via autoAcceptWebSearch. Init still reports "permissionMode":"default" even when approvalMode is unrestricted (session store had isRunEverything: true).

--sandbox disabled / sandbox.networkAccess is not this gate: reject happens at webFetchRequestQuery, not as a network error.

Operating System

MacOS

Version Information

Operating System

  • MacOS (darwin 25.6.0, arm64)

Version Information

  • Cursor IDE: 3.21.18
  • Cursor CLI: 2026.09.18-9a7762b (agent about, up to date)
  • Model: Composer 2.5
  • Subscription: Enterprise

Additional Information

Related:

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Hey @Michal_Kowalik, thanks for the detailed report! Confirmed on WebFetch, this isn’t intended behavior in --print. We’ve let the team know and it’s an issue we’re tracking.

Two workarounds:

  • Use the interactive CLI (drop --print), where WebFetch(*) / WebFetch(example.com) in permissions.allow is honored.
  • Or run headless with --force (note it also auto-approves shell, writes, and deletes, so use it only in a workspace you trust).

On Delete: that’s currently by design. It always prompts and there’s no allow token for it yet, so in --print it’s only auto-approved under unrestricted or --force. I’ve passed along your request for a dedicated Delete allow entry. The "permissionMode":"default" in the init event is just a fixed label, safe to ignore.

9

Hi @mohitjain

Thanks! I’m looking forward to the fix. WebFetch is what I’ve been missing the most!

The reason I submitted this bug report was that the workarounds were not sufficient for me:

  • I was too cautious to use the --force flag.

  • Interactive mode was not what I was targeting for my CLI use cases.