pbakaus/impeccable · warning

Warning: cannot access {target}

Error message

Warning: cannot access {target}

What it means

When `impeccable detect` is given a local path target that is neither a URL nor resolvable on disk, scan_targets calls std::fs::metadata on the resolved path. If that fails (missing path, broken symlink, or permission error), it prints "Warning: cannot access <target>" to stderr, sets had_operational_failure (forcing a non-zero exit), and skips that target, continuing with any remaining targets.

Source

Thrown at crates/detect/src/cli.rs:702

                (None, None) => crate::engines::UrlEngine::detect_url(
                    &crate::engines::MissingUrlEngine,
                    target,
                    &url_options,
                ),
            };
            match result {
                Ok(f) => all.extend(f),
                Err(e) => {
                    ctx.had_operational_failure = true;
                    ctx.io.err(&format!("Error: {}\n", e.message));
                }
            }
            continue;
        }
        let resolved = jsp::resolve(&ctx.cwd, &[target]);
        let Ok(stat) = std::fs::metadata(&resolved) else {
            ctx.had_operational_failure = true;
            ctx.io.err(&format!("Warning: cannot access {target}\n"));
            continue;
        };
        if stat.is_dir() {
            if !ctx.json_mode && !ctx.quiet_mode {
                if let Some(fw) = detect_framework_config(&resolved) {
                    let probe = is_port_listening(fw.port, Some(fw.fingerprint));
                    let msg = if probe.listening && probe.matched {
                        format!(
                            "\n{} dev server detected on localhost:{}.\nFor more accurate results, scan the running site:\n  npx impeccable detect http://localhost:{}\n\n",
                            fw.name, fw.port, fw.port
                        )
                    } else if probe.listening && !probe.matched {
                        format!(
                            "\n{} project detected ({}).\nPort {} is in use by another service. Start the {} dev server and scan via URL for best results.\n\n",
                            fw.name,
                            jsp::basename(&fw.config_path),
                            fw.port,
                            fw.name

View on GitHub (pinned to 2bc2879276)

Solutions

  1. Re-run `ls`/`test -e` on the exact path argument to confirm it exists relative to the current working directory
  2. Run the command from the project root or pass an absolute path instead of a relative one
  3. Check filesystem permissions on the path (read access for the invoking user)
  4. If the target was meant to be a URL, pass a full http(s):// URL so it is routed to the URL engine instead of the filesystem

Example fix

// before
$ impeccable detect ./srcc  # typo'd directory
Warning: cannot access ./srcc

// after
$ ls ./src  # verify the path first
$ impeccable detect ./src
Defensive patterns

Strategy: validation

Validate before calling

const fs = require('fs');
function targetExists(target, cwd = process.cwd()) {
  const resolved = require('path').resolve(cwd, target);
  try { fs.accessSync(resolved, fs.constants.R_OK); return true; }
  catch { return false; }
}
if (!targetExists('./src')) throw new Error('scan target missing or unreadable');

Type guard

function isAccessiblePath(p) {
  try { return fs.statSync(p) !== undefined; } catch { return false; }
}

Prevention

When it happens

Trigger: Running `impeccable detect <path>` where <path> (resolved against cwd via jsp::resolve) does not exist, is a broken symlink, or is not readable by the current user, and the target is not matched by URL_RE as a URL.

Common situations: Typos in a file/directory argument; running the scan from the wrong working directory so relative paths miss; deleting or renaming a folder between composing and running the command; scanning a mounted/removed volume; scanning a path the CI user cannot read due to permissions.

Understand the failure class

Background: "File not found" and ENOENT errors: why libraries can't find a file that should exist — this error's family across 50 libraries.

Related errors


AI-assisted analysis of pbakaus/impeccable@2bc2879276 (2026-09-08). Data as JSON: /api/errors/5d9675b5c841bca5. Report an issue: GitHub.