cannot re-verify approved sandbox write grant `{}` (if the d

Error message

cannot re-verify approved sandbox write grant `{}` (if the directory was removed, remove the grant or recreate the directory)

What it means

User-approved extra write grants (extra_write_paths) are re-verified on every sandbox construction via granted_write_path_to_location; if the approved directory cannot be re-verified (typically removed or moved since approval), construction fails with this message, which also tells the user the two ways out: remove the grant or recreate the directory. Like writable_paths, this is deliberately fail-closed — a grant that cannot be verified is never silently downgraded.

Source

Thrown at crates/acp_thread/src/terminal.rs:288

            sandbox::SandboxFsPolicy::Unrestricted { protected_paths }
        } else {
            // Project worktree paths are captured fresh; user-approved grants are
            // rebuilt via the verifying reopen (or captured when legacy bare
            // strings) through `granted_write_path_to_location`. A path that
            // can't be captured fails the whole construction (never created).
            let mut locations = Vec::new();
            for path in &self.writable_paths {
                let location = sandbox::HostFilesystemLocation::capture(path).map_err(|error| {
                    anyhow::anyhow!(error).context(format!(
                        "cannot capture writable sandbox path `{}`",
                        path.display()
                    ))
                })?;
                locations.push(location);
            }
            for granted in &self.extra_write_paths {
                let location = granted_write_path_to_location(granted).map_err(|error| {
                    anyhow::anyhow!(error).context(format!(
                        "cannot re-verify approved sandbox write grant `{}` (if the \
                         directory was removed, remove the grant or recreate the \
                         directory)",
                        granted.requested.display()
                    ))
                })?;
                locations.push(location);
            }
            // Dedupe to a minimal cover on the captured canonical paths, so a
            // grant nested under a worktree root (or another grant) is dropped
            // rather than bound redundantly.
            let writable_paths =
                sandbox::normalize_host_filesystem_locations(locations.into_iter());
            sandbox::SandboxFsPolicy::Restricted {
                writable_paths,
                protected_paths,
            }
        };

View on GitHub (pinned to bc538def45)

Solutions

Recreate the directory named in the error (mkdir -p the printed path)
Or remove the stale grant via the agent's permissions UI/settings, exactly as the message instructs

Defensive patterns

Strategy: validation

Validate before calling

// Before terminal spawn, verify approved grants still point at real dirs
let stale: Vec<_> = extra_write_paths.iter()
    .filter(|g| !g.requested.exists())
    .cloned()
    .collect();
for grant in stale {
    prompt_user(format!(
        "approved write grant {} no longer exists; remove it?",
        grant.requested.display()
    ));
}

Type guard

fn grant_targets_exist(grants: &[WriteGrant]) -> bool {
    grants.iter().all(|g| g.requested.is_dir())
}

Prevention

Recreate directories named in the error (mkdir -p) before respawning the agent terminal
Prune approved grants for directories that a clean step routinely deletes
Prefer approving stable directories over ephemeral build output paths

When it happens

Trigger: The user approved a writable directory for the agent, that directory was later deleted/moved (clean task removed a build dir, worktree pruned), and the next agent terminal spawn re-verifies the grant and fails.

Common situations: Approved a temp/build output directory that a clean script removes; approved a path inside a worktree that got deleted; state persisted across sessions while the filesystem changed underneath.

Related errors

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