VS Code extension: session history panel stops indexing new conversations (history.jsonl desyncs from actual .jsonl transcripts)

Bug: el panel de sesiones (VS Code extension) no muestra conversaciones recientes porque el índice global deja de sincronizarse, aunque las transcripciones sí se siguen guardando en disco

Resumen

El panel "sessions" / historial de la extensión de Claude Code para VS Code deja de listar conversaciones nuevas en algún momento, mientras que los archivos de transcripción reales (~/.claude/projects/<proyecto-encoded>/<sessionId>.jsonl) se siguen creando y actualizando con total normalidad. El usuario percibe esto como "se me borraron los chats", pero los datos nunca se pierden — el problema es puramente de indexación/visualización.

Causa raíz encontrada

El archivo ~/.claude/history.jsonl (usado para poblar el listado de sesiones recientes / picker de /resume) dejó de recibir entradas nuevas en una fecha concreta, mientras que las sesiones reales siguieron grabándose meses después sin ningún problema:

• Última entrada en ~/.claude/history.jsonl: 2026-06-02T10:50:30
• Sesiones reales con actividad posterior confirmada (ejemplos, mismo proyecto):
• 80ff1017-a09d-491e-954e-e654ebfb3e28.jsonl → actividad hasta 2026-09-04T06:55
• ee812771-f46b-42eb-8370-81c9fe0dead7.jsonl → actividad hasta 2026-09-04T05:35
• 1e70c4e8-532a-408f-9bb2-50a333c6fdd7.jsonl → actividad hasta 2026-09-04T04:58

Es decir: 3 meses de conversaciones reales y completas (junio–septiembre) nunca se reflejaron en el índice que alimenta el panel de la extensión, aunque el contenido en sí nunca se perdió.

También se observó que el campo lastSessionModified / lastSessionId dentro de ~/.claude.json → projects["<ruta>"] está igual de desactualizado (última fecha real: 2026-06-02), sugiriendo que ambos mecanismos de indexación dejaron de actualizarse al mismo tiempo, mientras el motor que escribe las transcripciones (~/.claude/projects/.../*.jsonl) siguió funcionando sin interrupción.

No se encontró ningún archivo sessions-index.json dedicado — el panel parece depender de history.jsonl / los campos de .claude.json, ambos huérfanos desde junio.

Pasos para reproducir

1. Usar Claude Code (CLI o extensión de VS Code) de forma continua durante varios meses, en el mismo proyecto/carpeta.
2. En algún punto (no identificado qué lo dispara), ~/.claude/history.jsonl deja de recibir nuevas líneas.
3. Las sesiones siguen funcionando con normalidad — se puede seguir chateando, y los .jsonl de sesión se siguen escribiendo y creciendo.
4. Abrir el panel de sesiones/historial en la extensión de VS Code (o el picker de /resume): solo se listan sesiones hasta la última fecha indexada (en este caso, junio), aunque hay meses de conversaciones más recientes en disco.

Impacto

El usuario cree que perdió conversaciones críticas de trabajo (sesiones de arquitectura, decisiones estratégicas, etc.) cuando en realidad siguen 100% intactas en ~/.claude/projects/, simplemente inaccesibles desde la UI normal. Solo se pueden recuperar manualmente vía claude --resume <sessionId> (conociendo el ID de antemano) o inspeccionando directamente los archivos .jsonl.

Entorno

• Claude Code CLI: 2.1.141
• Extensión VS Code: anthropic.claude-code-2.1.251-darwin-arm64 (también reproducido en 2.1.260-darwin-arm64)
• macOS: 14.7.6 (Build 23H626), Apple Silicon (arm64)
• El bug es visible independientemente de la versión de la extensión instalada — no se resuelve reinstalando ni haciendo downgrade, porque el problema vive en los datos de índice (~/.claude/history.jsonl / ~/.claude.json), no en el binario de la extensión.

Lo que se esperaría

• Que el panel de sesiones escanee directamente los .jsonl de ~/.claude/projects/<proyecto>/ (que sí están siempre al día) en vez de depender de un índice secundario que puede desincronizarse silenciosamente.
• Como mitigación mientras tanto: un comando o botón de "reconstruir índice" que regenere history.jsonl a partir de las transcripciones reales en disco.

Nota adicional (posiblemente relacionado, posiblemente aparte)

Durante la investigación también se encontró que instalar manualmente un .vsix de la extensión puede traer un binario nativo para la arquitectura equivocada (resources/native-binary/claude como ELF Linux/musl en vez de Mach-O macOS arm64), causando Error: spawn ENOEXEC al abrir el panel. Esto se resolvió reinstalando desde el Marketplace oficial. Lo menciono por separado porque no estoy seguro de que comparta causa con el bug de arriba, pero ambos aparecieron en la misma investigación.