TL;DR Esa línea no es un aviso para ti, es un adjunto para Claude. Tu language server publica los errores y Claude Code se los inyecta en el turno siguiente, por eso corrige un tipo roto sin haber ejecutado
tsc. Cubre solo los archivos que Claude ha editado. Lo comprobé rompiendo un export: el archivo que lo consumía siguió en silencio hasta que Claude lo tocó. Después de cambiar una firma o un export, ejecuta tutsc --noEmito pídele explícitamente que abra los consumidores. Esa línea no es tu build.
Claude edita un archivo y aparece esto:
⎿ Found 3 new diagnostic issues in 1 file (ctrl+o to expand)
Pulsas Ctrl+O y se despliega el detalle:
service.ts:
✘ [Line 1:10] Module '"./reports"' declares 'scoreFor' locally, but it is not exported. [2459] (typescript)
Aparece porque tienes instalado un plugin de code intelligence (typescript-lsp, pyright-lsp, rust-analyzer-lsp). Si no te aparece nunca, no lo tienes encendido: ese es el otro tip.
Qué está pasando por debajo
El language server no te habla a ti. Publica los diagnósticos, Claude Code los recoge y los adjunta al turno siguiente dentro de un bloque que Claude lee como cualquier otro contenido:
<new-diagnostics>The following new diagnostic issues were detected:
service.ts:
✘ [Line 1:10] Module '"./reports"' declares 'scoreFor' locally, but it is not exported. [2459] (typescript)</new-diagnostics>
De ahí sale el comportamiento que ya habrás visto: introduce un import roto y lo corrige en el mismo hilo, sin volcarte la salida del compilador en el contexto. La línea de pantalla es solo el resumen colapsado de ese adjunto.
Qué archivos entran
Monté dos archivos para medirlo, reports.ts exportando scoreFor y service.ts importándolo, y le quité el export:
| Acción de Claude | Qué reportó |
|---|---|
Edita reports.ts (rompe el export) |
solo reports.ts, y con una pista menor |
Lee service.ts, que ya estaba roto |
nada |
Edita service.ts |
ahora sí: [2459] declares 'scoreFor' locally, but it is not exported |
Leer un archivo no cuenta. Solo entran los archivos que Claude edita. El consumidor que acabas de romper se queda callado hasta que Claude lo toque por otro motivo, y si no lo toca en toda la sesión, nunca se entera.
Por eso el adjunto es un buen detector de errores locales y un mal detector de regresiones. Un refactor que cambia una firma pública rompe archivos que Claude no llegará a abrir, y ninguno de ellos aparecerá en esa línea.
Los límites del adjunto
Antes de enviarse, los diagnósticos se ordenan por severidad y se recortan: por esta vía, 10 por archivo y 30 en total en cada adjunto. Lo que sobra se queda fuera de ese envío sin avisar, ni a ti ni a Claude.
Lo medí con un archivo de 15 errores de tipo idénticos. En el primer adjunto llegaron los de las líneas 1 a 10 y los cinco restantes se quedaron fuera, sin ninguna marca en el bloque que indicara que faltaba algo. Los cinco aparecieron más tarde, en un adjunto posterior, cuando el servidor volvió a publicar. El recorte no borra nada de forma definitiva, pero sí significa que lo que Claude tiene delante en un turno puede ser una parte del problema sin que nada lo indique.
| Severidad | Orden al recortar |
|---|---|
| Error | 1, siempre pasa |
| Warning | 2 |
| Info | 3 |
| Hint | 4, el primero en caerse |
El orden juega a tu favor: los errores sobreviven al recorte y lo que se queda fuera son las pistas. Aun así, en un archivo con 40 errores Claude ve como mucho 10 por turno y responde a esos. Los errores llevan ✘ y las pistas ★, así distingues de un vistazo si el adjunto trae trabajo real o ruido.
Si el error sigue ahí, vuelve a aparecer
Claude Code lleva la cuenta de lo que ya te ha entregado para no repetirlo, pero esa memoria se borra por archivo cada vez que lo edita. Práctica: si Claude edita service.ts, ignora el error y vuelve a editar service.ts, el mismo error se le entrega otra vez. No se pierde por haberlo visto una vez.
Qué hacer con esto
- Después de cambiar una firma o un export, no des el cambio por bueno con la línea de diagnósticos. Ejecuta
tsc --noEmit(o tu build) o pídele a Claude que abra y edite los consumidores. - Cuando aparezca la línea, pulsa Ctrl+O antes de dejarle seguir. Ver el
[Line L:C]exacto cuesta dos segundos y te dice si está corrigiendo lo que crees. - En monorepos, desconfía de los imports no resueltos. La documentación oficial avisa de que los language servers los reportan como falsos positivos cuando el workspace no está bien configurado.
Referencia
| Elemento | Qué significa |
|---|---|
Found N new diagnostic issues in M files |
Resumen colapsado del adjunto que recibirá Claude |
| Ctrl+O | Despliega el detalle en pantalla |
[Line 15:10] |
Línea y columna, en base 1 |
[2459] |
Código del diagnóstico, el del language server |
(typescript) |
Qué servidor lo reporta |
| Archivos incluidos | Solo los que Claude ha editado en la sesión |
| Tope | 10 por archivo y 30 en total en cada adjunto, por severidad (vía plugin LSP) |
Con la extensión de VS Code o JetBrains conectada hay una segunda vía que alimenta esa misma línea, con su propia lógica interna y con otro límite: en vez de un recuento de diagnósticos, un tope de caracteres sobre el bloque. Lo de arriba es el camino del plugin LSP, el que funciona en una terminal a secas.
El fondo del asunto es el mismo de siempre: Claude Code no indexa tu código, así que todo lo que sabe de tipos y símbolos entra por aquí o no entra.
Documentación oficial: Code intelligence