-
Notifications
You must be signed in to change notification settings - Fork 9.9k
Open
Description
Problem
Filesystem startup and path-validation failures currently surface as free-form text, which makes it hard for clients to distinguish startup misconfiguration from a request that is outside allowed roots.
Why now
The filesystem server is a reference safety boundary for MCP clients. Explicit error taxonomy matters here because clients use it to validate fail-closed behavior.
Evidence packet
- Commit under test:
c4b38bc6382c247a307ace49ede95f9c3e134592 - Runtime: macOS 15.3 / Darwin 25.3.0 arm64, Node
v22.19.0 - Relevant codepaths:
src/filesystem/index.tssrc/filesystem/lib.tssrc/filesystem/path-validation.ts
- Minimal repro:
- Start the server with no accessible root directories.
- Start it with valid roots, then request a path outside those roots.
- Compare the resulting startup/tool failure surfaces.
- Expected: distinct machine-readable classifications for missing roots, invalid path, and out-of-scope path denial.
- Actual: startup uses plain stderr strings such as
Error: None of the specified directories are accessible, while path denial throws genericAccess denied ...messages fromvalidatePath.
Scope
This is a platform contract issue in the filesystem reference server.
Validation target
Startup and path-validation tests should assert stable error codes or other machine-readable classifiers for each failure class.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels