Filesystem scope
How to review filesystem paths and roots in MCP configurations
Check MCP roots, working directories, path defaults, traversal, and sibling-prefix escapes without overclaiming runtime containment.
- Published
- Reading time
- 7 minutes
Require an explicit comparison boundary
A pasted path cannot be called out of scope unless the document or review policy provides a root to compare against. Without one, static analysis can inventory path-like values but cannot establish containment.
When roots exist, normalize dot segments and separators before comparison. Compare complete path segments: /workspace/project-old is not inside /workspace/project even though it shares a textual prefix.
Lexical checks have limits
Lexical normalization can prove that an obvious relative or absolute path falls outside every declared root. It cannot resolve symbolic links, junctions, mount points, case-folding differences, or server-side canonicalization without filesystem access.
Path examples and defaults deserve review even when the schema accepts arbitrary strings. The runtime server must canonicalize against the actual allowed root after resolving platform-specific behavior.
Constrain the runtime identity
Grant the server only the roots it needs and run it under an identity that cannot read unrelated locations. Separate read and write capabilities where possible, and require confirmation for destructive changes.
Treat client cwd fields and command arguments as part of the same review. A narrow declared root does not help if the launched process receives broader host permissions.
Frequently asked questions
Can a static scanner resolve symlinks?
Not from pasted JSON alone. It can perform lexical normalization; symlinks and filesystem-specific canonicalization require runtime filesystem access.
Is a path beginning with the root always contained?
No. Containment must compare normalized path segments. A sibling such as /root-old must not be treated as inside /root.