dev-env: enable Deno LSP code-intelligence in Claude Code (CLI / VS Code / Zed)

[rickylabs]

Goal

Give Claude Code real Deno code-intelligence (goToDefinition / findReferences / hover / documentSymbol / live diagnostics) in netscript projects, consistently across the CLI, VS Code, and Zed harnesses — so agents and devices all get the same LSP tooling.

Verified working on eis-chat (Deno 2.9, @netscript/fresh alpha.18, Fresh/preact) on 2026-07-01.

Setup (one-time, per machine — applies to every session & harness)

1. Install the Deno LSP plugin into the skills dir (auto-loads every session; no marketplace, no /plugin install):

   git clone https://github.com/wyattjoh/deno-lsp-claude-plugin ~/.claude/skills/deno-lsp

   It ships .claude-plugin/plugin.json (name claude-deno-lsp) + .lsp.json (command: "deno", args: ["lsp"], .ts/.tsx/.js/.jsx/.mts/.cts/.mjs/.cjs mapped, unstable: true). A plugin placed in ~/.claude/skills/<name>/ loads automatically as <name>@skills-dir — the documented cross-harness mechanism.
2. Enable the LSP tool in global ~/.claude/settings.json:

   { "env": { "ENABLE_LSP_TOOL": "1" } }

   Also set it as a real user env var for terminal/GUI launches — Windows: [Environment]::SetEnvironmentVariable('ENABLE_LSP_TOOL','1','User'); macOS/Linux: export ENABLE_LSP_TOOL=1 in your shell profile.
3. deno on PATH (2.9+).
4. Restart Claude Code completely to load the LSP plugin — /reload-plugins is NOT sufficient for LSP servers.

Harness notes

• CLI: the above is enough. (--plugin-dir <path> also works for a one-off, but the skills-dir install is the durable, cross-harness path.)
• VS Code & Zed: both launch the same claude binary + ~/.claude config, so the global setup covers them. Zed runs Claude Code via ACP over the $PATH binary (Zed ≥ 0.202.5) — same config applies; if Zed can't find the binary (e.g. WSL), set CLAUDE_CODE_EXECUTABLE. The CLI-only --plugin-dir flag does not apply in VS Code/Zed — use the skills-dir install.

⚠️ Gotcha: config-discovery is scoped to Claude's workspace root (cwd/rootUri)

The Deno LSP only discovers deno.json for files inside Claude Code's workspace root. Files in a sibling git-worktree outside cwd are treated as detached → no deno.json → false positives (document/useState inferred as any, "This JSX tag requires 'React' to be in scope"). This is expected LSP behavior / a misconfiguration, not a Deno bug (related deno#24476 issues are closed) and not an .lsp.json gap.

Fix — root Claude where the code lives:

• Keep the current session: claude --continue --add-dir "<worktree-abs-path>" (adds the worktree as an LSP workspace folder), or
• Launch Claude with cwd = the worktree/repo root you're editing.

For Fresh/preact the app-level deno.json (jsx: "precompile", jsxImportSource: "preact", lib: ["dom", …]) must be in the discovered scope, or JSX/DOM types won't resolve.

When LSP diagnostics look wrong inside a worktree, trust deno task check — it's the source of truth.

Suggestion

Consider shipping a small netscript-blessed .lsp.json/skills-dir plugin (or docs) so every agent/device gets identical Deno code-intelligence out of the box for netscript apps.