evan/pi-lsp
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(daemon): launch LSP servers with caller env

Browse Source
This commit is contained in:
Evan Reichard
2026-05-02 15:28:25 -04:00
parent 306771f92a
commit 04fd520438
5 changed files with 80 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
AGENTS.md
View File

@@ -21,14 +21,14 @@ The extension is **stateless** — it opens a fresh socket connection per reques
Communication is **newline-delimited JSON (NDJSON)** over a Unix socket at `$XDG_RUNTIME_DIR/pi-lsp-$UID.sock`. Each line is one independent request/response pair with an `id` field for matching. See `src/daemonProtocol.ts` for the type definitions (`DaemonRequest`, `DaemonResponse`).
Current ops: `request`, `diagnostics`, `status`, `shutdown`.
Current ops: `request`, `diagnostics`, `status`, `shutdown`, `destroy_server`. `request` and `diagnostics` include a `launch` context with the caller env. The env is used only when spawning a new server for `(server.id, rootDir)`; existing running servers keep their original process env until idle eviction or manual destroy/restart.
### Server Lifecycle
1. First LSP tool call for a file triggers `getOrCreateEntry()` in the daemon
2. `pickServer()` matches the file extension against `server.ts` registry
3. `findRoot()` walks upward looking for root markers (e.g., `go.mod`, `tsconfig.json`)
4. A new `LspClient` is spawned, initialized via LSP `initialize`/`initialized`, and waited on (`waitForReady()`)
4. A new `LspClient` is spawned with the caller/session environment from the daemon request, initialized via LSP `initialize`/`initialized`, and waited on (`waitForReady()`)
5. The file is synced via `didOpen` or `didChange` (based on mtime comparison)
6. On idle timeout (default 5 min), the entry is evicted and the server process killed