Executable not found in $PATH: por qué tu plugin de LSP en Claude Code no arranca

Instalas el plugin de TypeScript, abres un `.ts` y Claude Code te suelta `Executable not found in $PATH`. No es un bug ni una instalación rota: al plugin le falta la pieza que de verdad entiende tu código, y no la instala él.

Diagrama de code intelligence en Claude Code: a la izquierda grep devuelve ruido textual con falsos positivos tachados, a la derecha un grafo semántico limpio con goToDefinition y findReferences conectando la definición con sus referencias reales, y abajo la ecuación motor (binario) + cable (plugin) = navegación semántica

TL;DR Si instalaste el plugin de TypeScript y Claude Code te devuelve Executable not found in $PATH en la pestaña Errors de /plugin, no tienes nada roto: el plugin es solo el adaptador y nunca instala el language server. Lo dice su propio README. Te faltan dos comandos: npm install -g typescript-language-server typescript (el motor) y luego /reload-plugins. A partir de ahí Claude navega tu código con precisión de compilador (goToDefinition, findReferences y diagnósticos de tipos tras cada edición), que es la herramienta LSP integrada que traías apagada sin saberlo.

Soy heavy user de Claude Code y descubrí esto hace literalmente una hora. Al probar la herramienta LSP sobre un archivo .ts me devolvía No LSP server available for file type: .ts: la navegación con precisión de IDE estaba ahí, integrada, pero apagada. La encendimos para TypeScript en tres pasos — y hay plugins oficiales para Rust, Python, Go y ocho lenguajes más.

El malentendido que te va a morder

El plugin no instala el language server. Su README oficial lo deja claro — su sección de instalación es literalmente npm install -g typescript-language-server typescript. Hay dos piezas distintas:

Pieza	Qué es	Quién la instala
El binario (`typescript-language-server`)	El motor que entiende los tipos	Tú, vía `npm install -g`
El plugin (`typescript-lsp`)	El adaptador: ~15 líneas que dicen "para `.ts`, lanza este binario"	`/plugin install`

Si instalas solo el plugin, verás Executable not found in $PATH en la pestaña Errors de /plugin. El plugin es el cable, no el aparato.

Encenderlo (TypeScript, 3 pasos)

# 1. El motor (lo instalas tú, prerequisito)
npm install -g typescript-language-server typescript

# 2. El adaptador (plugin oficial de Anthropic)
/plugin install typescript-lsp@claude-plugins-official

# 3. Activar en la sesión actual
/reload-plugins

A partir de ahí, abre cualquier .ts/.tsx/.js/.jsx y Claude navega con precisión de compilador y ve los errores de tipo al instante. Pulsa Ctrl+O cuando aparezca el indicador "diagnostics found" para verlos inline.

El motivo de fondo es que Claude Code no indexa tu código: no hay símbolos resueltos esperando en ninguna parte, solo búsqueda de texto.

Sin LSP, cuando le pides a Claude "¿dónde se define greet y quién la llama?", la respuesta sale de grep: te devuelve todas las coincidencias textuales — comentarios, strings, greeting, greetUser, la definición y las llamadas, todo mezclado. Claude tiene que abrir varios archivos para desambiguar, cargando contexto que no necesita. Con LSP, goToDefinition devuelve una ubicación exacta, resuelta semánticamente. Cero falsos positivos, cero lecturas de desambiguación.

Lo que gana Claude

Capacidad	Qué hace
`goToDefinition`	Salta a la definición exacta de un símbolo (no la primera coincidencia de texto)
`findReferences`	Lista las referencias reales, resueltas por scope — no `grep`
`hover`	Firma de tipos e info al vuelo: `function greet(user: User): string`
Diagnósticos automáticos	Tras cada edición, el server reporta errores de tipo en el mismo turno

El beneficio más infravalorado son los diagnósticos automáticos. Sin LSP, el bucle para validar un cambio es: edito → corro tsc (que vuelca muchísimo output a contexto) → leo errores → re-edito. Con LSP, si introduzco un import roto o un tipo incorrecto, Claude lo ve y lo arregla en el mismo turno, sin el volcado del compilador. Ese aviso tiene sus propias reglas sobre qué archivos revisa y cuáles no.

Lenguajes con plugin oficial

Cada uno necesita su binario instalado aparte:

Lenguaje	Plugin	Binario
TypeScript	`typescript-lsp`	`typescript-language-server`
Python	`pyright-lsp`	`pyright-langserver`
Rust	`rust-analyzer-lsp`	`rust-analyzer`
Go	`gopls-lsp`	`gopls`
C/C++	`clangd-lsp`	`clangd`
C#	`csharp-lsp`	`csharp-ls`
Java	`jdtls-lsp`	`jdtls`
PHP	`php-lsp`	`intelephense`
Lua, Kotlin, Swift	`lua-lsp`, `kotlin-lsp`, `swift-lsp`	(ver docs)

El matiz "semi-automático"

Si Claude Code detecta que ya tienes el binario en el PATH al abrir un proyecto, te ofrece instalar el plugin correspondiente. No se instala solo en silencio — tú apruebas. Pero el binario sigue siendo prerequisito tuyo: Claude Code nunca lo instala por ti.

Aviso honesto: los language servers consumen memoria (rust-analyzer y pyright notablemente en monorepos grandes). Si te da problemas, /plugin disable <plugin> y Claude vuelve a sus herramientas de búsqueda. El ahorro es de tokens y precisión, no de RAM.

Combina esto con /run-skill-generator para cerrar el bucle: navegación semántica + ejecución real de la app.

Documentación oficial: Code intelligence — Claude Code Docs · Catálogo: claude.com/plugins