LSP Navigation

LSP Navigation

Not implemented — upstream semantic code navigation is unavailable in the current Edge deployment.

Upstream reference: LSP Navigation

What Upstream Provides

The LSP seam is an optional capability layer exposing semantic code navigation through ctx.lsp. It distributes across three packages:

• dsh-lsp — service definition: LspService with provider registration and query dispatch
• dsh-lsp-stdio — stdio host: spawns language server processes (TypeScript, Python, Go, etc.) via node:child_process
• dsh-tool-lsp — tool consumer: registers model-facing tools for the four semantic queries

Four operations in a closed union: goToDefinition, findReferences, goToImplementation, hover. Each provider registers a stable ID and extension-to-language mapping. The service is optional and external to the agent loop's core execution path.

Current Edge Status

Not implemented None of the three LSP packages are in Edge's dependencies. No ctx.lsp service is available. The model cannot perform go-to-definition, find-references, or hover queries.

The primary blocker is the stdio host (dsh-lsp-stdio): it spawns long-running language server processes via node:child_process, which is unavailable in Cloudflare Workers.

Cloudflare Enablers

Approach	Capability	Plan Required	Complexity
Cloudflare Containers	Full LSP — run real language servers (tsserver, pylsp, gopls) in Linux containers. Process persists across turns for fast responses after warmup.	Workers Paid or Enterprise	High — need container lifecycle, stdio bridging, workspace sync
Tree-sitter WASM	Partial — symbol extraction, go-to-definition for common languages. No hover docs, limited cross-file references. Runs in Workers without containers.	Free plan compatible	Medium — implement an LspProvider backed by Tree-sitter WASM parsers

Container approach: A ContainerLspProvider would implement the upstream LspProvider interface, launching language servers inside Containers instead of via stdio. The container lifecycle could be managed per-workspace — start on first LSP query, keep alive for the session duration, dispose on session end. Workspace files would need to be synced from the DO's VFS to the container filesystem.

Tree-sitter approach: A lighter alternative that works within the free plan. Tree-sitter WASM parsers can extract symbols, navigate definitions within a file or project, and provide basic structural information. This would not match full LSP fidelity (no type inference, no hover documentation from language servers) but would cover the most common navigation needs.

Architecture Summary

Component	Status	Notes
LspService (dsh-lsp)	Missing	Service definition — no platform dependency, could install
Stdio host (dsh-lsp-stdio)	Missing	Requires node:child_process — needs Container replacement
Tool consumer (dsh-tool-lsp)	Missing	No platform dependency — could install once service exists

Key observation: The service definition and tool consumer packages have no platform dependencies — they could be installed as-is. Only the stdio host needs a platform-specific replacement (Container-backed or Tree-sitter-backed provider). The upstream LspProvider interface is the correct extension point.

TODO

Evaluate Container-backed LSP provider. Can Cloudflare Containers run tsserver/pylsp with acceptable startup latency? What is the workspace-sync overhead from DO VFS to container filesystem? Does the container persist long enough for interactive development sessions?

Evaluate Tree-sitter WASM as a free-plan alternative. Which languages have mature Tree-sitter WASM parsers? Can go-to-definition and find-references work across files using only Tree-sitter queries? What is the bundle size impact of including WASM parsers?