Índice
- 1. Qué está pasando en realidad: el token "court" y las etiquetas invoke
- 2. Contexto: un agente también "genera" sus llamadas a herramientas
- 3. Por qué ocurre: dos causas raíz y sus desencadenantes
- 4. Tres errores comunes, aclarados
- 5. Soluciónalo ahora (para usuarios de Claude Code)
- 6. Para desarrolladores: prevenirlo desde la API/SDK
- 7. Cómo distinguirlo de errores parecidos
- 8. Estado oficial
- 9. Lista de prevención
- Resumen
- FAQ
Si has tenido sesiones largas en Claude Code, quizá hayas visto aparecer de repente en pantalla una cadena extraña como esta:
court
<invoke name="Bash">
<parameter name="command">ssh host 'cp file file.bak ; sed -i ...'</parameter>
<parameter name="description">…descripción del comando…</parameter>
</invoke>
Your tool call was malformed and could not be parsed. Please retry.Una llamada a herramienta (un comando) que debía ejecutarse entre bambalinas se filtra al chat como texto en bruto, y nunca llega a ejecutarse. Al principio aparece una palabra sin sentido, court (o call). Es natural pensar "¿se ha roto mi equipo?" o "¿configuré algo mal?". Pero la respuesta corta es: esto no es tu entorno, ni tu comando.
Se trata de un fallo del lado del modelo en el que Claude (sobre todo la familia Opus 4.8 / 4.7) corrompe las "etiquetas de control" de una llamada a herramienta justo en el momento de generarlas. El repositorio oficial de Anthropic tiene muchas issues abiertas al respecto (#64108, #64150, #64690, #65705, #66153, #67295, #68354 y más). Este artículo expone el mecanismo, las causas, los errores comunes, las soluciones para usuarios y desarrolladores, cómo distinguirlo de errores parecidos y el estado oficial, apoyándose en la documentación de Anthropic y en las propias issues. Lo más importante, de entrada: cuando aparezca court, no te empeñes en seguir en esa sesión; sal pronto a una sesión nueva (/clear). El motivo se explica más abajo.
Qué son realmente "court" y las etiquetas invoke filtradas
— una etiqueta de control se genera rota, así que se filtra a pantalla en vez de ejecutarse
Una llamada rota no se puede interpretar, así que nunca se ejecuta (fail-closed): no hay riesgo de que corra un comando equivocado.
Los problemas reales son un turno desperdiciado y una "reacción en cadena" si lo dejas pasar.
1. Qué está pasando en realidad: el token "court" y las etiquetas invoke
Los <invoke name="Bash"> y <parameter name="command"> que ves son "marcado de llamada a herramienta" que nunca deberías ver. Cuando Claude ejecuta un comando o edita un archivo, genera como tokens estas etiquetas estructuradas al estilo XML, y Claude Code (el harness) las interpreta y ejecuta de verdad el comando. Normalmente el harness absorbe las etiquetas, no llegan nunca a pantalla, y solo ves el resultado de la herramienta.
Esta vez, sin embargo, el "token de control de apertura" de la llamada a herramienta se generó roto, con la palabra sin relación court o call colándose al principio. El harness solo reacciona a una sintaxis estricta, así que decide "esto no es una llamada a herramienta, es solo texto" y lo manda directo a pantalla. El comando no se ejecuta y obtienes "Your tool call was malformed and could not be parsed." En algunos casos no hay ningún mensaje de error y simplemente se queda colgado en silencio (en la issue #65705 la respuesta volvió como stop_reason=end_turn sin nada que ejecutar, así que la conversación se quedó pendiente).
La palabra court en sí no significa nada. Pero tampoco es una palabra totalmente aleatoria y aislada: en múltiples reportes independientes, la filtración aparece como court / call con una consistencia inquietante. La issue #64690 lo analiza como "un token adyacente en el vocabulario que se selecciona en lugar de la etiqueta correcta." En otras palabras, lo mejor es entender court como una firma que ayuda a reconocer este bug.
2. Contexto: un agente también "genera" sus llamadas a herramientas
¿Por qué puede llegar a romperse una "etiqueta de control"? La clave es que para un agente de IA, una llamada a herramienta al final no es más que generación de texto.
Cuando usas herramientas con la API de Claude, el formato que ves como desarrollador es JSON (un bloque tool_use). Internamente, sin embargo, el modelo sigue un system prompt oculto que Anthropic inyecta de forma automática y genera las etiquetas envolventes <function_calls>, <invoke> y <parameter> como un flujo de tokens. La capa de la API entonces las interpreta y las convierte en un bloque tool_use JSON limpio (según la documentación oficial de uso de herramientas). Cada "llamada a herramienta" en MCP y en los agentes de IA se apoya en este mecanismo.
Lo importante aquí es que el parser del harness es "fail-closed" (peca de prudente). Si una etiqueta difiere de la forma esperada aunque sea en un solo token, el harness no adivina ni la ejecuta: la rechaza de inmediato como malformada. Este es el diseño de harness correcto: "arreglar amablemente" un comando ambiguo y ejecutarlo sería muchísimo más peligroso. Así que todo este fenómeno es un caso de "se rompió → fue rechazado → no se ejecutó"; es decir, falló de forma segura.
En una frase
Una llamada a herramienta es "texto con etiquetas especiales" que genera el modelo. Cuando el token de apertura de esas etiquetas se rompe durante la generación, el harness no puede reconocerlo, así que se filtra a la prosa y no se ejecuta. El rechazo en sí es un mecanismo de seguridad correcto; el bug reside puramente en la generación del lado del modelo.
3. Por qué ocurre: dos causas raíz y sus desencadenantes
Al consolidar las issues reales, la causa se divide en "(1) corrupción en el momento de la generación" y la "(2) reacción en cadena por autoenvenenamiento" que la vuelve molesta.
Cómo se rompe y luego "encadena"
· Varias llamadas a herramientas en un mismo mensaje / una llamada a herramienta justo después de prosa (#66153)
· El estado justo después de ejecutar
/compact (#67295: se repite en la primera llamada tras compactar)· Bash en segundo plano (run_in_background) o 3+ servidores MCP conectados (#64690)
· Argumentos de herramienta largos del tamaño de un párrafo (#49747: una variante distinta en la que el XML se cuela en el JSON)
Conclusión: la rotura en sí es un ruido de muestreo poco frecuente. Lo verdaderamente molesto es la cadena de (2) —
por eso "insistir con reintentos en la misma sesión" puede ser la peor jugada.
4. Tres errores comunes, aclarados
La información sobre este fenómeno se enreda con facilidad. Para reaccionar bien, aquí están tres errores comunes puestos en su sitio.
| Creencia común | Realidad |
|---|---|
| "La herramienta se descontroló / falló" | Justo lo contrario. La llamada rota fue rechazada sin ejecutarse (fail-closed). No hay riesgo de que corra un comando equivocado; lo único que pasó fue un "turno desperdiciado + una filtración visual." Falló de forma segura. |
| "Basta con reintentar; se cura solo si lo dejas" | Solo cierto a medias. Un caso leve se recupera con un reintento, pero una vez que el bloque roto se asienta en el historial, el modelo lo imita y encadena. En #65705 hubo 14 fallos seguidos durante más de 5 horas; en #66153 más de 30 en una sola sesión. Insistir en la misma sesión es contraproducente. |
"court significa algo / es un comando" | No significa nada: solo son restos de un token de control corrupto. Pero court/call se repiten como marca, así que son útiles como señal de diagnóstico. |
El segundo es el que más importa. Los reportes de incidentes suelen decir "se recuperó al reintentar, así que sin problema", pero eso solo vale para el caso "leve" antes de que empiece la cadena. La esencia de este bug es que una vez entra en modo cadena, ninguna cantidad de reintentos dentro de esa sesión lo arreglará.
5. Soluciónalo ahora (para usuarios de Claude Code)
La respuesta depende de "¿sigues en lo leve o ya empezó la cadena?" En orden de prioridad:
Orden de prioridad
court, haz pronto /clear o abre una sesión nueva. Cortar el historial envenenado es lo más fiable. Antes de moverte, guarda el estado con git commit o una nota de traspaso./compact se repite justo después: no es una solución fiable.
La regla: "falla dos veces, abandona la sesión y empieza de cero."
Cuanto más insistas en un historial envenenado, más profunda es la herida. Mantén el CLI al día (pero ojo: aún no se ha lanzado ningún arreglo; actualizar es higiene, no una cura mágica).
Consejo: si sueles guardar el estado en git o en una nota de traspaso .md, moverte a una sesión nueva en cualquier momento no te cuesta nada. Cuanto más ejecutes sesiones autónomas largas, más rinde este hábito (y conecta directamente con la gestión de tu ventana de contexto).
6. Para desarrolladores: prevenirlo desde la API/SDK
Si construyes tu propio agente sobre la API / SDK de Claude, puedes añadir las siguientes defensas en tu harness. La lógica de detección propuesta en la issue #65705 es práctica.
// Inspecciona el turno del asistente recibido antes de ejecutar
const text = assistantText(resp);
const looksLeaked =
/<invoke\s+name=/.test(text) ||
/function_calls/.test(text) ||
/\bcourt\s*<invoke/.test(text);
// 1) Hay marcado de arriba pero NO un bloque tool_use estructurado → llamada rota
if (looksLeaked && !hasToolUseBlock(resp)) {
// 2) No lo muestres; regístralo. NO conserves el bloque roto en el historial (evita el autoenvenenamiento)
// 3) Empuja a "emítelo como tool_use estructurado, no como texto" y reintenta automáticamente
return retryWithNudge(messages);
}
// Rechaza un tool_use incompleto causado por truncamiento
if (resp.stop_reason === 'max_tokens' && lastBlock(resp)?.type === 'tool_use') {
return retryWith({ max_tokens: higher }); // no lo ejecutes
}Cuatro principios. (1) Comprueba siempre stop_reason (un end_turn sin que ninguna herramienta se haya ejecutado de verdad = detecta el cuelgue silencioso). (2) Antes de ejecutar, verifica que el texto no contiene <invoke name= ni function_calls; si los contiene, reintenta en lugar de ejecutar. (3) No conserves el bloque roto en el historial de la conversación (conservarlo hace que la siguiente generación lo imite: autoenvenenamiento / #62344). (4) Mantén cortos los argumentos de herramienta y divide las salidas largas (evita la variante de payload largo de #49747). Incluso cuando usas un harness oficial como el Claude Agent SDK, conviene entender cómo se comportan los bucles de larga duración.
7. Cómo distinguirlo de errores parecidos
Hay varios errores del tipo "la herramienta no se ejecuta", y necesitan soluciones distintas. Distingue estos cuatro para no confundirlos.
| Síntoma | Qué es en realidad | Solución principal |
|---|---|---|
| court / call + etiquetas invoke en bruto mostradas, sin ejecutar | El tema de este artículo. Corrupción al generar el token de control + encadenamiento por autoenvenenamiento | Prefiere una sesión nueva (/clear); no insistas tras dos fallos |
| El 400 "thinking blocks cannot be modified" bloquea la sesión | Un desajuste de firma en el pensamiento extendido (otro bug). Un error duro de la API | Consulta el artículo dedicado (Esc×2 / rewind) |
| La respuesta se corta a mitad de stream (sin XML corrupto) | Un truncamiento normal por alcanzar max_tokens. No es un error | Sube max_tokens y vuelve a ejecutar |
| El XML no se estructura en Bedrock, LangChain, etc. | Un cliente de terceros que no logra interpretar el formato de Anthropic (langchain-aws #521). No se reproduce en la API oficial / Claude Code | Revisa la librería de integración / la capa de hosting |
El eje para distinguirlos es sencillo. Si ves un "garabato court / call + XML en bruto", es este bug. Un error de firma 400 es el error del bloque de pensamiento. Un corte limpio es solo el límite de salida. Solo en Bedrock o vía LangChain apunta a la capa de integración. Para otros errores comunes de Claude Code, consulta el resumen de errores.
8. Estado oficial
A junio de 2026, no hay un arreglo oficial confirmado (entrada en el changelog) que diga que este fenómeno se ha resuelto. Siguiendo las notas de versión hasta el Claude Code más reciente (la línea 2.1.183), no hay ninguna entrada que aborde la corrupción de la serialización de las llamadas a herramientas, y muchas de las issues relacionadas siguen abiertas, o están archivadas como "duplicate / stale." Así que cada solución de este artículo es una solución provisional a la espera de un arreglo oficial, y no puedes afirmar que "actualizar a la última versión lo arregla" (actualizar es recomendable, pero no es una cura garantizada).
Dicho esto, el diseño fail-closed del harness de "rechazar una llamada rota en lugar de ejecutarla adivinando" es en sí mismo correcto. Lo que hay que arreglar es la estabilidad de generación del modelo, no relajar el parser para "arreglarlo y ejecutarlo igualmente", lo cual invitaría al grave riesgo de correr el comando equivocado. Lo mejor que podemos hacer como usuarios es operar para evitar la cadena y reportar las reproducciones a las issues oficiales con tu entorno y tus logs (más reportes elevan la prioridad y aceleran el arreglo).
9. Lista de prevención
Usuarios de Claude Code: (1) Cuando aparezca court/call, reintenta como mucho dos veces; si persiste, /clear / sesión nueva de inmediato. (2) Evita sesiones muy largas / de varios días; guarda el trabajo en git/notas en los puntos de corte. (3) No metas varias llamadas a herramientas en un solo mensaje. (4) Recuerda que /compact no es la panacea (puede repetirse justo después). (5) Mantén el CLI al día y reporta las reproducciones a las issues oficiales.
Desarrolladores de API/SDK: (1) Comprueba siempre stop_reason. (2) Detecta <invoke name= / function_calls filtrándose en el texto y reintenta. (3) No conserves las llamadas rotas en el historial (evita el autoenvenenamiento). (4) Mantén cortos los argumentos de herramienta; divide las salidas largas. (5) Nunca ejecutes un tool_use incompleto por un corte de max_tokens: reintenta en su lugar.
Resumen
En Claude Code, "court / call + una etiqueta <invoke> en bruto mostrada, sin que la herramienta se ejecute" es un fallo del lado del modelo en el que Claude (la familia Opus 4.8 / 4.7) genera el token de control de una llamada a herramienta de forma rota. El harness lo rechaza fail-closed, así que no hay riesgo de que corra un comando equivocado (falló de forma segura). Lo verdaderamente molesto es que una vez que el bloque roto permanece en el historial, el modelo lo imita y "encadena." Por eso "reintentar lo arregla" solo vale mientras es leve, y la regla pasa a ser "falla dos veces, sal a una sesión nueva."
La causa es de dos capas: (1) corrupción al generar el token de control + (2) encadenamiento por autoenvenenamiento. Entre los desencadenantes están sesiones largas / de varios días, contexto pesado, el estado posterior a /compact, varias herramientas en paralelo, 3+ servidores MCP y argumentos de herramienta largos. Como no se ha lanzado ningún arreglo oficial a junio de 2026, todo remedio es provisional. Los usuarios deben "preferir una sesión nueva + guardar el estado a menudo"; los desarrolladores deben "comprobar stop_reason, reintentar al detectar la filtración, nunca conservar un historial roto y acortar los argumentos." Leer junto a esto el error 400 del bloque de pensamiento, el resumen de errores de Claude Code y MCP te hará mucho más resistente a los problemas de llamadas a herramientas.
FAQ
Q. El "court" o la etiqueta invoke que veo en pantalla, ¿lo causa un error en mi comando o mi configuración?
A. No, casi con total seguridad que no. Es un fallo conocido del lado del modelo en el que Claude genera las etiquetas de llamada a herramienta de forma rota, con varias issues registradas en el repositorio oficial de Anthropic (#64108, #65705, #66153 y más). No es un error de tu entorno, tu comando ni tu configuración. Trata court/call como una "firma" del bug.
Q. ¿Podría ejecutarse un comando equivocado y dañar mi servidor o mis archivos cuando esto ocurre?
A. No. Una llamada a herramienta rota se juzga "malformada" y se rechaza sin ejecutarse (diseño fail-closed). Lo único que pasa es que el turno se desperdicia y el texto de control se vuelve visible; no hay efecto sobre tus datos ni sobre el estado del servidor. Está diseñado para fallar de forma segura.
Q. He oído que "basta con reintentar y se arregla solo". ¿Es cierto?
A. Solo cuando es leve. En una primera aparición aislada, un empujón a "continuar" suele hacer que lo vuelva a emitir bien. Pero una vez que el bloque roto permanece en el historial de la conversación, el modelo lo usa como plantilla y repite la misma corrupción (autoenvenenamiento). En ese punto, reintentar en la misma sesión es contraproducente. Si falla dos veces seguidas, deja de insistir y pásate a una sesión nueva (/clear).
Q. ¿/compact lo arregla?
A. No de forma fiable. Compactar el contexto a veces ayuda, pero en la issue #67295 se repitió en la primerísima llamada a herramienta justo después de /compact. Lo más fiable no es /compact, sino una sesión nueva (/clear) que reinicie por completo el historial. Guarda tu estado de trabajo en git o en notas antes de moverte.
Q. ¿Actualizar Claude Code a la última versión lo arregla?
A. No se puede afirmar que lo "arregla". A junio de 2026 no hay ninguna entrada de changelog oficial que confirme un arreglo, y muchas issues relacionadas siguen abiertas o como duplicate. Actualizar se recomienda como higiene, pero no es una cura mágica. Por ahora el mejor enfoque es operar para evitar la cadena (falla dos veces → sesión nueva) y reportar las reproducciones a las issues oficiales.
