Claude Code 2.1.158: regresión del harness, no es Opus 4.8

TL;DR: Las versiones 2.1.154 a 2.1.158 de Claude Code tienen una regresión real en la capa cliente (harness) que corrompe la entrega de resultados de tool_use al modelo. Los comandos se ejecutan una vez, pero los resultados llegan vacíos, tarde o fuera de orden, y el modelo reacciona con lecturas duplicadas, llamadas inventadas y gasto excesivo de tokens. No es Opus 4.8 volviéndose tonto. El fix temporal es fijar la versión a 2.1.157 con npm install -g @anthropic-ai/claude-code@2.1.157 hasta que Anthropic publique una versión limpia.

El síntoma que despista: parece el modelo, es el cliente

Esta semana se ha repetido el mismo patrón en foros: gente actualizando a Opus 4.8, abriendo Claude Code y notando comportamientos raros. Lecturas repetidas del mismo archivo, llamadas a herramientas que se reintentan sin motivo, instrucciones del system prompt ignoradas y facturas hinchadas sin tarea que lo justifique.

El reflejo natural es culpar al modelo. Es lo que más cambió y lo que más se nota en marketing. Pero el cliente CLI también cambió, y mal. Los reportes en el repositorio oficial de Anthropic ya lo confirman como regresión: en versión 2.1.157 todo fluye normal y, tras el auto-update a 2.1.158, el mismo Opus 4.8 entra en bucles de tool calls redundantes (issue #63935).

El bug no está en lo que el modelo decide, sino en lo que el modelo recibe. Ese matiz cambia toda la depuración.

¿Qué es el harness y por qué importa?

El harness es la capa cliente que envuelve al LLM. En Claude Code es el binario CLI: gestiona el bucle de mensajes, ejecuta tool calls (Bash, Read, MCP), recoge los resultados y los empaqueta de vuelta al modelo en el siguiente turno.

Cuando el harness funciona, el modelo ve una conversación coherente: pidió leer un archivo, el archivo aparece, decide qué hacer. Cuando el harness falla, el modelo ve agujeros: pidió leer 4 archivos, aparecen 2, los otros llegan tarde con el orden cambiado. Ante datos rotos, un modelo bien entrenado intenta reparar la situación: relee, reintenta, inventa pruebas (\"echo PROBE\") y termina quemando tokens en reconstruir un canal que él no controla.

Si quieres una analogía útil del tipo de capas que componen un agente, lo tienes desglosado en skills y subagentes como ladrillos base.

Cómo identificar la regresión en tu sesión

Antes de tocar nada, comprueba la versión:

# Versión actual del cliente Claude Code
claude --version

Si estás entre 2.1.154 y 2.1.158, son candidatas a regresión confirmada. Los síntomas concretos descritos en los reportes oficiales:

Tool results vacíos en la UI: ves (No content) o cadenas tipo "start..." donde debería haber el contenido del archivo, aunque wc -c confirma que el archivo se generó bien.
Lecturas tardías y fuera de orden: cuatro echo en paralelo (P1 a P4) llegan en orden P1, P3, P4, P2.
Llamadas duplicadas a Read: el modelo lee el mismo archivo dos o tres veces porque la primera lectura no llegó.
Errores 400 "thinking blocks cannot be modified" en sesiones que pasan por bridge o wakeup (issue #63394, específicamente en 2.1.154).
Gasto de tokens desproporcionado para una tarea trivial.

Si ves dos o más de estos síntomas, no es paranoia: estás dentro del bug.

Workaround: fijar 2.1.157 sin romper tu configuración

La instalación bajo demanda de una versión concreta vía npm es trivial. Lo importante es no perder tu CLAUDE.md, tus settings.json, hooks ni MCP servers.

Paso 1: respaldo rápido

# Respaldo del directorio de configuración global antes de tocar nada
cp -r ~/.claude ~/.claude.backup-$(date +%Y%m%d)

Paso 2: instalar la versión limpia

# Fija el cliente en la última versión sin regresión conocida
npm install -g @anthropic-ai/claude-code@2.1.157
claude --version  # Debe imprimir 2.1.157

La configuración vive en ~/.claude/ y en el CLAUDE.md de cada repo. Ninguno se toca al reinstalar el binario. Si tu setup además depende de CLAUDE.md bien estructurado, conviene revisar las tres capas de memoria de Claude Code para no mezclar reglas globales con reglas de proyecto.

Paso 3: bloquear el auto-update

El problema viene de que Claude Code se auto-actualiza al iniciar sesión. Si vuelve a saltar a 2.1.158, repites el bug. La solución es desactivar el auto-update temporalmente:

# Variable de entorno que desactiva el auto-update mientras dure el incidente
export DISABLE_AUTOUPDATER=1
# Persistir en tu shell config (~/.bashrc o ~/.zshrc)
echo 'export DISABLE_AUTOUPDATER=1' >> ~/.zshrc

El coste real del workaround: renunciar a Opus 4.8

2.1.157 funciona, pero es anterior al soporte completo de Opus 4.8. Es decir, el workaround tiene un coste: te quedas en Opus 4.7 o Sonnet 4.6 mientras Anthropic publica un fix.

Opción	Modelo disponible	Riesgo	Recomendado para
Quedarte en 2.1.158	Opus 4.8	Alto: tool_result inestables	Tareas one-shot cortas sin tool use intensivo
Bajar a 2.1.157	Opus 4.7 / Sonnet 4.6	Bajo	Sesiones largas con muchos Read/Bash/MCP
Esperar a 2.1.159+	Opus 4.8	Variable	Si tu trabajo aguanta 24-72h en pausa

Si tu workflow vive de subagentes con muchas tool calls paralelas, bajar es lo sensato. Si trabajas mayoritariamente conversacional, puedes quedarte en 2.1.158 con cuidado.

En Producción

Para equipos que tienen a Claude Code metido en pipelines o CI, el riesgo no es solo "se gasta más". Es que un agente que recibe tool_result corruptos puede tomar decisiones sobre datos inventados. Un agente que cree haber leído un archivo cuando en realidad la respuesta llegó vacía puede sobrescribirlo con la versión que él imagina.

Tres medidas prácticas que recomiendo para no volver a comerte una regresión a ciegas:

Pinear versión en CI: en entornos donde Claude Code corre desatendido (cron, hooks de release), nunca uses la última. Fija una versión validada.
Canary mínimo: un script que ejecuta un prompt fijo con tool calls predecibles (leer 3 archivos, hacer 1 grep) y compara la salida con un golden output. 30 segundos al día y detectas la próxima regresión antes de quemar tokens.
Telemetría de tokens: si tu gasto diario sube 30% sin que la carga de trabajo haya cambiado, sospecha del cliente antes que del modelo. La explicación más probable es un bucle de tool calls duplicadas, no un "modelo más caro".

Este tipo de disciplina ya la cubrí en un post anterior sobre medir la degradación de Claude en vez de intuirla. El canary aplica igual aquí, solo que mide al cliente, no al modelo.

Errores Comunes y Depuración

Error: "tool_use sin tool_result correspondiente" → Causa: el harness perdió la respuesta entre paralelos → Solución: redirige el comando a un archivo temporal (cmd > /tmp/x 2>&1) y luego Read /tmp/x en un turno separado.
Error: 400 messages.N.content.M: thinking blocks cannot be modified → Causa: regresión específica de 2.1.154 en sesiones con replay (wakeup, subagentes en background) → Solución: bajar a 2.1.152 o subir a 2.1.157 según hayas validado, y evitar continuaciones desatendidas hasta el fix.
Error: el modelo reintenta el mismo Read con offset distinto sin necesidad → Causa: tool_result llegó vacío o fuera de orden → Solución: ejecutar /clear, bajar a 2.1.157 y reintentar.
Error: el modelo dispara un sleep 20; echo burst_flush por su cuenta → Causa: intento del propio modelo de desbloquear el canal de tool_result → Solución: tratar como confirmación de regresión, no como bug del modelo.

Preguntas Frecuentes

¿Cómo distingo regresión del harness de regresión del modelo?

Una regresión del modelo se nota igual en distintos clientes (CLI, API directa, Workbench). Una regresión del harness solo se nota desde Claude Code CLI y desaparece al bajar la versión del cliente sin tocar el modelo. Si Opus 4.8 funciona normal por API pero se vuelve loco en Claude Code 2.1.158, es harness.

¿Puedo seguir usando Opus 4.8 con 2.1.157?

Parcialmente. 2.1.157 no tiene el soporte completo de las features nuevas de 4.8 (Fast mode, algunas variantes de contexto extendido), pero el modelo en sí responde por la API. Para la mayoría de tareas de coding diarias, Sonnet 4.6 o Opus 4.7 desde 2.1.157 son una alternativa estable hasta el fix.

¿Por qué Anthropic no ha tirado la versión rota?

Versiones publicadas en npm rara vez se despublican por compatibilidad y trazabilidad. Lo habitual es marcar la última versión limpia como recomendada y publicar una nueva por encima con el fix. Tu trabajo como usuario es saber a qué versión bajar, no esperar a que la rota desaparezca sola.

Cierre

El patrón se repetirá. Modelos nuevos, clientes que se actualizan a la par, y regresiones que se confunden con "el modelo está peor". La lección práctica es separar capas: cuando algo va raro, lo primero es claude --version, no abrir un debate sobre si Opus 4.8 ha degradado. Y si tu workflow vive de Claude Code, pinear versiones en entornos críticos deja de ser paranoia para convertirse en higiene básica.

¿Te ha tocado esta semana y has perdido horas pensando que era el modelo? Cuéntamelo en Twitter @sergiomarquezp_. El próximo post va sobre cómo montar el canary mínimo de tool calls para detectar este tipo de regresiones antes de que te coman la tarde.