zed-industries/zed · error

Could not resolve path {}

Error message

Could not resolve path {}

What it means

The second step of resolve_project_path: find_project_path returned a worktree id, but worktree_for_id can no longer resolve it. Both lookups consult live project state, so this only happens when the worktree is removed between the two calls — a close-vs-tool-call race, not a bad path.

Source

Thrown at crates/agent/src/tools/tool_permissions.rs:404

/// - `Ok(ResolvedProjectPath::SymlinkEscape { .. })` — the path resolves
///   through a symlink to a location outside the project. Agent tools should
///   prompt the user before proceeding.
/// - `Err(..)` — the path could not be found in the project or could not be
///   verified. The error message is suitable for returning to the model.
pub fn resolve_project_path(
    project: &Project,
    path: impl AsRef<Path>,
    canonical_worktree_roots: &[PathBuf],
    cx: &App,
) -> Result<ResolvedProjectPath> {
    let path = path.as_ref();
    let project_path = project
        .find_project_path(path, cx)
        .ok_or_else(|| anyhow!("Path {} is not in the project", path.display()))?;

    let worktree = project
        .worktree_for_id(project_path.worktree_id, cx)
        .ok_or_else(|| anyhow!("Could not resolve path {}", path.display()))?;
    let snapshot = worktree.read(cx);

    // Fast path: if the entry exists in the snapshot and is not marked
    // external, we know it's safe (the background scanner already verified).
    if let Some(entry) = snapshot.entry_for_path(&project_path.path) {
        if !entry.is_external {
            return Ok(ResolvedProjectPath::Safe(project_path));
        }

        // Entry is external (set by the worktree scanner when a symlink's
        // canonical target is outside the worktree root). Return the
        // canonical path if the entry has one, otherwise fall through to
        // filesystem-level canonicalization.
        if let Some(canonical) = &entry.canonical_path {
            if is_within_any_worktree(canonical.as_ref(), canonical_worktree_roots) {
                return Ok(ResolvedProjectPath::Safe(project_path));
            }

View on GitHub (pinned to bc538def45)

Solutions

1. Retry the tool call — resolution then runs against the updated worktree set
2. Confirm the folder is still open in the project panel
3. Re-issue the agent request after the project layout change settles

let resolved = match resolve_project_path(&project, &path, &canonical_roots, cx) {
    Err(e) if e.to_string().contains("Could not resolve path") => {
        // worktree set changed mid-resolution; re-resolve once against fresh state
        resolve_project_path(&project, &path, &canonical_roots, cx)?
    }
    result => result?,
};

When it happens

Trigger: A worktree is closed or removed from the project concurrently with an agent tool call being resolved; the id from the first lookup is stale by the time of the second.

Common situations: The user closes a folder tab in a multi-root workspace while the agent is mid-request.

Related errors

• Path {} is not in the project
• Context server not initialized
• Failed to convert {} to absolute path
• `cd` directory {cd:?} was not in any root directory in the p
• HTTP error! status: ${response.status}

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