Security & Boundaries
Relevant source files
The following files were used as context for generating this wiki page:
Security and boundaries within the lsp-mcp-server are designed to protect the host system while facilitating semantic code intelligence. The system enforces strict path validation, resource limits, and process isolation to ensure that the bridge between Claude Code and Language Servers remains secure. By leveraging the Model Context Protocol (MCP), the server acts as a gatekeeper, validating every request before it reaches the underlying file system or language server processes.
The scope of these security measures covers input validation via Zod schemas, file system access control through workspace boundary checks, and the prevention of resource exhaustion. These boundaries ensure that tools like lsp_rename or lsp_format_document only modify files within authorized project roots, and that large or binary files do not cause memory instability or data corruption.
Path Validation and Workspace Isolation
The server enforces a strict "Absolute Path Only" policy for all file-related operations. Relative paths are explicitly rejected during the initial validation phase to prevent directory traversal attacks and ambiguity in file resolution.
Absolute Path Enforcement
Every MCP tool that accepts a file_path or workspace_root uses a Zod schema (FilePathSchema) that mandates the path be absolute. This validation occurs at the edge of the server before any logic is executed.
Sources: src/schemas/tool-schemas.ts:37-43, SKILL.md:25-26
Workspace Boundary Checks
To prevent unauthorized file modifications, the server implements validatePathWithinWorkspace(). This function ensures that any file intended for modification (e.g., via lsp_rename, lsp_format_document, or lsp_code_actions) resides strictly within the detected or configured workspace root.
Sources: src/utils/uri.ts:285-296, CLAUDE.md:104-106
The following diagram illustrates the path validation flow for a tool request:
The diagram shows how the system filters requests through multiple validation layers, separating read-only semantic queries from potentially destructive write operations. Sources: src/index.ts:792-808, src/utils/uri.ts:285-296
Content and Resource Security
The server protects itself and the host system from resource exhaustion by enforcing limits on file size and types. These constraints prevent the server from attempting to process massive data sets or non-textual information that could lead to crashes or undefined behavior.
File Size Constraints
A hard limit defined by MAX_FILE_SIZE_BYTES (10 MB) is enforced whenever a file is read into the DocumentManager. If a file exceeds this limit, an LSPError with code FILE_NOT_READABLE is thrown.
Sources: src/utils/uri.ts:208-220, CLAUDE.md:107-108
Binary File Detection
The server prevents the accidental processing of binary files through two primary mechanisms:
- Extension Blocklist: Known binary extensions (e.g.,
.exe,.png,.zip) are instantly rejected. - Null Byte Sampling: The server reads the first 1024 bytes (
BINARY_CHECK_BYTES) of a file to look for null bytes, which typically indicate non-textual data.
Sources: src/utils/uri.ts:143-162, src/utils/uri.ts:223-231
| Security Feature | Threshold / Implementation | Error Code |
|---|---|---|
| Max File Size | 10 MB (MAX_FILE_SIZE_BYTES) | FILE_NOT_READABLE |
| Binary Check Size | 1024 Bytes (BINARY_CHECK_BYTES) | FILE_NOT_READABLE |
| Path Format | Must be Absolute | INVALID_INPUT (Zod) |
| Spawn Method | shell: false | N/A (Process Isolation) |
Sources: src/constants.ts, src/utils/uri.ts:208-231, CLAUDE.md:109
Process and Execution Security
The lsp-mcp-server maintains a boundary between the MCP interface and the Language Server processes it manages.
Shell Execution Prevention
When spawning language server processes, the server explicitly sets shell: false. This measure is critical for preventing command injection attacks, as it ensures that arguments are passed directly to the operating system's execution API rather than being interpreted by a shell (like sh or cmd.exe).
Sources: CLAUDE.md:109
Sandboxed File Writing
For tools that modify the file system, the server does not rely on the Language Server's ability to write files. Instead, the server receives the proposed edits (e.g., WorkspaceEdit), validates the paths, and then performs the file write itself using fs.writeFile after secondary validation.
Sources: src/tools/formatting.ts:114-118, src/tools/code-actions.ts:110-120
This sequence demonstrates the server's role as a verifying intermediary that refuses to perform writes suggested by the LSP unless they meet local security criteria. Sources: src/tools/code-actions.ts:246-250, src/utils/uri.ts:285-296
Summary of Security Constants
Major security thresholds are centralized to ensure consistent enforcement across the codebase.
// From src/constants.ts
export const MAX_FILE_SIZE_BYTES = 10 * 1024 * 1024; // 10MB limit
export const BINARY_CHECK_BYTES = 1024; // Sample size for null-byte check
Sources: src/constants.ts
The enforcement of these boundaries ensures that the lsp-mcp-server provides a robust and secure environment for semantic code analysis without exposing the host to common file-system or process-level vulnerabilities. By combining strict Zod-based input validation with runtime workspace checks, the server effectively isolates language server capabilities within the intended project context.