Windows path on Unix

What mcp-scan saw

The config scanner matched an argument beginning with a drive letter followed by a colon and a backslash, case-insensitively, for example C:\Users\you. It reports the first such argument it finds and does not check whether the path exists.

Why it fires

A Windows path on a Unix host does not resolve, so the server either fails at launch or silently falls back to a default directory, and the second case is the dangerous one because it looks like it worked. It is graded LOW because the usual cause is a config copied between machines rather than anything hostile.

When this is a false positive

• A shared dotfiles or team config repo that carries entries for Windows, macOS, and Linux, where the Windows entry is correct on the machine it is for.
• A CI runner scanning a config that is deployed to Windows. The scan host is Unix and the target is not.
• A WSL setup where a Windows path is reachable through an interop mount, so the path is unusual but functional.
• The check tests only the argument prefix, so a Windows path appearing later in an argument, for example inside a --config= value, does not report.

How to fix it

1. Read the path from the finding and check whether it resolves on this machine: ls the POSIX equivalent.
2. Replace it with the POSIX path for this host, for example C:\Users\you\project becomes /Users/you/project.
3. If the config is shared across platforms, split it per platform rather than keeping both forms in one file.
4. Confirm the server actually starts after the change. A path that never resolved may have been masking a fallback the server was using instead.
5. To suppress, add 'windows-path-on-unix' to suppressRules in .mcp-scan.json.