Feature request for product/service
Cursor CLI
Describe the request
We ship a CLI tool that agents call through a skill file. On Windows with
Cursor 3.21.16 in agent mode, every session’s first invocation of that binary goes
through the same sequence:
- The Agent runs the command with “sandbox”: true in the beforeShellExecution
payload. Our hook answers {“permission”: “allow”}. The command fails, because
the tool needs network and writes under its own directory, and the agent reports
the binary as “blocked”. - The Agent retries with required_permissions: [“all”]. Smart mode refuses it
before any hook runs: “runs an unrecognized external binary from an unverified
path”. - The Agent retries with request_smart_mode_approval. The human is prompted,
approves, and the command runs unsandboxed.
So every session costs one failed run and one prompt before the tool works, and in
our measurement the agent answered the user’s question after step 3 without the
tool ever having succeeded — the failure in step 1 invited it to answer from
memory.
What we ask for, any one of:
- A documented way for a beforeShellExecution hook that answers “allow” to also
say that the exact command it approved may run unsandboxed. Today the hook sees
the “sandbox” boolean on input and has no way to influence it. - A per-user or per-workspace trust list for a binary path, so an installer can
register the executable it just installed and the Agent treats it as recognized. - Failing both, documentation of how smart mode decides a binary is “unrecognized”
or a path “unverified”, so a tool can meet the bar.
Why it matters beyond us. Any tool installed outside the workspace and called by
name from a skill hits the same wall, and the model’s reaction to the first
failure is not something a tool author can control.
Operating System (if it applies)
Windows 10/11