Cannot list directory because its path matches the user's…

Error message

Cannot list directory because its path matches the user's global `private_files` setting: {}

What it means

The second guard in list_directory: after the global file_scan_exclusions check, paths matched by the global private_files setting are refused (crates/agent/src/tools/list_directory_tool.rs:285). private_files marks directories whose contents must never reach agent context (secrets, credentials). The bail is by design and names the setting and path.

Solutions

Do not bypass it: private_files exists to keep secrets out of agent context.
If the directory is not actually sensitive, remove or narrow the glob under private_files in settings.json.
Copy the specific non-secret files you need out of the protected directory and point the agent at the copies.
Audit broad patterns for accidental matches on ordinary working paths.

Example fix

// settings.json — before
"private_files": ["**/.config/**"]

// after (narrowed to actual secrets)
"private_files": ["**/.ssh/**", "**/.aws/**"]

Defensive patterns

Strategy: validation

Validate before calling

// before invoking the tool on a path (tool integrations):
let settings = WorktreeSettings::get_global(cx);
if settings.is_path_private(&project_path.path) {
    // path is protected by private_files; do not attempt to list it
}

Prevention

Never try to bypass private_files — it keeps secrets out of agent context.
Keep private_files patterns narrowly scoped to actual secret directories.
Copy specific non-secret files out of protected directories when the agent needs them.
Audit broad patterns (e.g. **/.config/**) for accidental matches on working paths.

When it happens

Trigger: Asking the agent to list a directory matched by a private_files glob in settings.json — typical patterns include **/.ssh, **/.gnupg, **/.aws, or user-added secrets directories.

Common situations: Agent asked to inspect configuration that lives inside a protected directory; overly broad user patterns that accidentally cover working directories.

Related errors

AI-assisted analysis of zed-industries/zed@f4178619ac (2026-08-20). Data as JSON: /api/errors/6605e61b1f448866. Report an issue: GitHub.

Appendix: source

Thrown at crates/agent/src/tools/list_directory_tool.rs:285

            // Check settings exclusions synchronously
            project.read_with(cx, |project, cx| {
                let worktree = project
                    .worktree_for_id(project_path.worktree_id, cx)
                    .with_context(|| {
                        format!("{} is not in a known worktree", input.path)
                    })?;

                let global_settings = WorktreeSettings::get_global(cx);
                if global_settings.is_path_excluded(&project_path.path) {
                    anyhow::bail!(
                        "Cannot list directory because its path matches the user's global `file_scan_exclusions` setting: {}",
                        input.path
                    );
                }

                if global_settings.is_path_private(&project_path.path) {
                    anyhow::bail!(
                        "Cannot list directory because its path matches the user's global `private_files` setting: {}",
                        input.path
                    );
                }

                let worktree_settings = WorktreeSettings::get(Some((&project_path).into()), cx);
                if worktree_settings.is_path_excluded(&project_path.path) {
                    anyhow::bail!(
                        "Cannot list directory because its path matches the user's worktree `file_scan_exclusions` setting: {}",
                        input.path
                    );
                }

                if worktree_settings.is_path_private(&project_path.path) {
                    anyhow::bail!(
                        "Cannot list directory because its path matches the user's worktree `private_paths` setting: {}",
                        input.path
                    );

View on GitHub (pinned to f4178619ac)