Programas un agente para revisar un repositorio cada mañana. Antes de permitir un comando o una edición, un hook consulta una política. Un día el servicio de política no responde: si el callback falla y la herramienta continúa, la protección solo existía mientras todo funcionaba. Anthropic publicó el 3 de noviembre de 2026 Claude Agent SDK para TypeScript 0.3.317 con una opción precisa para ese caso: onFailure: "block" en los matchers de hooks.

Qué añade la versión 0.3.317

Según las notas oficiales, cuando un callback de hook lanza una excepción o devuelve una respuesta inválida, onFailure: "block" hace que la acción se bloquee. La versión también añade un mensaje de advertencia al flujo cuando falla el callback. Claude Code 2.1.317, publicado el mismo día, refleja el cambio para los callbacks del Agent SDK. La mejora importa a quien construye agentes que editan archivos, usan herramientas o corren tareas desatendidas; no significa que Claude entienda por sí solo qué operación es segura.

Hay dos situaciones distintas. Un hook puede decidir denegar una acción porque la política la prohíbe. También puede fallar técnicamente porque hubo un timeout, excepción o salida mal formada. La nueva opción trata esa segunda situación como un bloqueo cuando así lo configuras. No convierte todos los hooks existentes a ese comportamiento por arte de magia ni sustituye las restricciones de herramientas, permisos y sandbox.

Cómo aplicarlo a un agente de código

Primero comprueba la versión del paquete y actualiza en una rama de prueba. El comando de instalación indicado por Anthropic es:

npm install @anthropic-ai/claude-agent-sdk@0.3.317

Después localiza los hooks PreToolUse que protegen una acción importante. La documentación del Agent SDK muestra que este evento se dispara antes de una llamada de herramienta y puede permitir, modificar o denegar la operación. En un matcher de TypeScript, la idea es configurar la política de fallo al lado del callback:

hooks: {
  PreToolUse: [{
    matcher: "Write|Edit",
    hooks: [checkWritePolicy],
    onFailure: "block"
  }]
}

El fragmento muestra la ubicación de la opción, no un programa completo: checkWritePolicy debe ser un callback real y tu proyecto debe pasar las opciones a query(). Mantén una denegación explícita en el propio callback para archivos o rutas prohibidos. Si el callback intenta consultar una lista de permisos y esa consulta falla, el nuevo ajuste evita que la llamada a Write o Edit prosiga silenciosamente.

Haz una prueba controlada antes de activar el job: usa un archivo desechable en un repositorio de prueba, configura el callback para lanzar una excepción y verifica que la operación no cambie el archivo. Repite con una respuesta inválida y con una respuesta válida que permita la escritura. Revisa el evento de advertencia en el flujo para que una caída de la política no se confunda con una negativa normal. Esta es una prueba propuesta; no ejecuté una sesión real de Claude Agent SDK con credenciales de Joseph.

Dos límites que conviene respetar

El matcher Write|Edit solo cubre esas herramientas. La documentación de Anthropic advierte que una escritura hecha mediante Bash no pasa por ese matcher; para ese caso hacen falta controles de Bash, permisos o sandbox según el entorno. Además, bloquear por fallo puede interrumpir trabajo legítimo si tu servicio de política está caído. Diseña el mensaje de error y la recuperación: el operador debe saber qué callback falló y poder reintentar tras corregirlo, sin desactivar la protección por impaciencia.

Mi decisión para un agente que toca datos, despliegues o archivos sensibles sería usar onFailure: "block" en los hooks que son barreras reales y probar el caso de error antes del siguiente run programado. Para hooks que solo registran telemetría, evalúa por separado si una caída debe detener el trabajo. El valor de la noticia es explícito: ahora puedes elegir qué pasa cuando falla el control, en vez de confiar en el camino feliz.