zed-industries/zed · info

Windows-drive write aborted by user

Error message

Windows-drive write aborted by user

What it means

After the Windows-drive warning, any outcome other than AllowOnce maps to this error, meaning the user declined the cross-drive write. This is deliberate refusal, not a malfunction: the sandbox will not perform the write and the tool call reports the abort.

Source

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

                        response: response_tx,
                        context: None,
                        kind: acp_thread::AuthorizationKind::PermissionGrant,
                    },
                )))
            {
                log::error!("Failed to send Windows-drive sandbox warning: {error}");
                return Err(anyhow!(
                    "Failed to send Windows-drive sandbox warning: {error}"
                ));
            }

            let outcome = response_rx
                .await
                .map_err(|_| anyhow!("authorization channel closed"))?;
            ensure_tool_call_authorization_not_interrupted(&outcome)?;
            match acp_thread::SandboxPermission::from_id(outcome.option_id.0.as_ref()) {
                Some(acp_thread::SandboxPermission::AllowOnce) => Ok(()),
                _ => Err(anyhow!("Windows-drive write aborted by user")),
            }
        })
    }

    fn sandbox_request_covered_by_grants(
        request: &SandboxRequest,
        sandbox_grants: &Rc<RefCell<ThreadSandboxGrants>>,
        cx: &App,
    ) -> bool {
        let settings = AgentSettings::get_global(cx);
        sandbox_grants
            .borrow()
            .covers_with_persistent(request, &settings.sandbox_permissions)
    }

    fn handle_sandbox_permission_outcome(
        outcome: &acp_thread::SelectedPermissionOutcome,
        request: &SandboxRequest,

View on GitHub (pinned to bc538def45)

Solutions

1. Inform the user the write was skipped; do not auto-retry
2. Re-issue the operation with a path inside the project drive if the user actually intended it
3. If the denial was accidental, let the user rerun the tool and approve it
4. Log it as a normal denial in the transcript, not as a failure

match windows_drive_outcome {
    Ok(()) => proceed_with_write(),
    Err(err) if err.to_string() == "Windows-drive write aborted by user" => {
        // Expected refusal: report and continue the turn.
        report_to_user("Cross-drive write skipped by user");
    }
    Err(err) => return Err(err),
}

When it happens

Trigger: The user picks a non-AllowOnce outcome for a write outside the sandbox's project drive on Windows, declining the operation.

Common situations: Users declining unexpected absolute-path writes to another disk prompted by the sandbox; cautious responses to tool calls touching system drives.

Related errors

• Failed to send Windows-drive sandbox warning: {error}
• Permission to run tool denied by user
• Failed to send sandbox authorization: {error}
• authorization channel closed
• Failed to send sandbox fallback authorization: {error}

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