What causes "Permission to run tool denied by user" in zed-industries/zed?

Surface 'denied by user' in the transcript and continue the conversation; do not retry automatically

Permission to run tool denied by user

Error message

Permission to run tool denied by user

What it means

When a sandbox permission prompt resolves to Deny, the tool call fails with this error. It is the expected control flow for user refusal: the sandboxed request is not executed and no grant is recorded, unlike AllowThread and AllowAlways which persist permission.

Source

Thrown at crates/agent/src/thread.rs:6042

    ) -> Result<()> {
        debug_assert!(
            outcome.params.is_none(),
            "unexpected params for sandbox permission"
        );

        match acp_thread::SandboxPermission::from_id(outcome.option_id.0.as_ref()) {
            Some(acp_thread::SandboxPermission::AllowOnce) => Ok(()),
            Some(acp_thread::SandboxPermission::AllowThread) => {
                sandbox_grants.borrow_mut().record(request);
                Self::persist_thread_grants(&thread, cx);
                Ok(())
            }
            Some(acp_thread::SandboxPermission::AllowAlways) => {
                Self::persist_sandbox_always_permission(request, fs, cx);
                Ok(())
            }
            Some(acp_thread::SandboxPermission::Deny) => {
                Err(anyhow!("Permission to run tool denied by user"))
            }
            None => {
                let other = outcome.option_id.0.as_ref();
                debug_assert!(false, "unexpected sandbox permission option_id: {other}");
                Err(anyhow!("Permission to run tool denied by user"))
            }
        }
    }

    fn persist_sandbox_always_permission(
        request: &SandboxRequest,
        fs: Option<Arc<dyn Fs>>,
        cx: &AsyncApp,
    ) {
        let Some(fs) = fs else {
            log::error!(
                "Cannot persist \"allow always\" sandbox permission: no filesystem available"
            );

View on GitHub (pinned to bc538def45)

Solutions

Surface 'denied by user' in the transcript and continue the conversation; do not retry automatically
If the denial blocks legitimate work, narrow the tool invocation or adjust sandbox settings so the request is more specific
Let the user rerun the tool if they change their mind
Treat it as expected control flow, not as a bug or failure metric

Defensive patterns

Strategy: try-catch

Try / catch

match sandbox_permission_outcome {
    Ok(()) => run_sandboxed_request(),
    Err(err) if err.to_string() == "Permission to run tool denied by user" => {
        // Expected denial: report and continue the conversation.
        report_to_user("Tool call denied");
    }
    Err(err) => return Err(err),
}

Prevention

Treat user denials as expected control flow, not as errors to suppress or retry
Narrow tool invocations so sandbox requests look specific and trustworthy
Let users rerun a denied tool instead of retrying it automatically
Record denials in the transcript; do not count them as failures in health metrics

When it happens

Trigger: The user selects the Deny option on a sandbox authorization request for a tool call, so handle_sandbox_permission_outcome returns Err.

Common situations: Users declining commands whose sandbox request looks too broad; review or pairing flows where a reviewer denies an action; automated policies that answer prompts with Deny.

Related errors

AI-assisted analysis of zed-industries/zed@bc538def45 (2026-08-16). Data as JSON: /api/errors/eaafbf4377c51bf3. Report an issue: GitHub.