Noticia7 min

Claude Code corrige hook matchers con guiones: una regla pequeña que evita aprobar tools equivocadas

El changelog de Claude Code corrigió matchers de hooks con identificadores que incluyen guiones, como mcp__brave-search. Para equipos con MCP, el cambio importa porque una política por substring puede activar o bloquear herramientas equivocadas.

ClaudeAnthropic
Composición editorial de Claude Code aplicando hooks exactos sobre herramientas MCP con guiones

Por qué importa

Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.

Anthropic registró en el changelog de Claude Code una corrección pequeña con impacto operativo real: los hook matchers con identificadores que incluyen guiones, como code-reviewer o mcp__brave-search, dejaron de hacer coincidencias por substring accidental y ahora hacen match exacto. Para cubrir todas las tools de un servidor MCP con guiones, el patrón recomendado pasa a ser explícito, por ejemplo mcp__brave-search__.*.

Esto suena como bugfix de bajo nivel. Para un equipo que usa hooks como control de permisos, auditoría o bloqueo antes de tool calls, es más serio: si tu matcher no coincide como crees, puedes aprobar, bloquear o registrar la tool equivocada.

Diagrama editorial de tools MCP con guiones pasando por un matcher exacto antes de ejecutar una acción

Por qué un matcher importa tanto

Los hooks viven en una parte incómoda del stack agentic: no son la inteligencia del modelo, pero deciden qué pasa alrededor de sus acciones. Un PreToolUse puede pedir confirmación, registrar evidencia, bloquear una tool o cambiar el flujo antes de que el agente toque algo sensible.

Por eso las reglas de match no son un detalle cosmético. Si una política dice "aplica a mcp__brave-search", el equipo espera que se active sobre esa tool o ese grupo de tools, no sobre cualquier nombre parecido. En entornos con muchos MCP servers, skills, plugins y subagentes, los nombres empiezan a parecerse demasiado.

El bug corregido afectaba justo esa frontera: identificadores con guiones podían caer en coincidencias por substring. La corrección vuelve más predecible el contrato.

El patrón práctico: explícito o nada

La lección para builders no es memorizar un nombre de tool. Es revisar cómo están escritas tus reglas.

Si quieres una tool concreta, usa match exacto. Si quieres todas las tools de un servidor MCP con guiones, usa un patrón explícito que capture el namespace completo. Si quieres cubrir varios servidores, no dependas de prefijos ambiguos que alguien pueda malinterpretar seis semanas después.

Panel editorial de políticas de hooks con reglas exactas, comodines acotados y revisión de auditoría antes de ejecutar tools

Yo revisaría tres zonas:

  1. Hooks que bloquean escritura en repos, filesystem o shell.
  2. Hooks que permiten búsqueda, navegador o conectores externos.
  3. Hooks que registran evidencia para auditoría, costo o seguridad.

Una regla demasiado amplia puede frenar trabajo legítimo. Una regla demasiado débil puede dejar que el agente use una tool fuera de política. El costo aparece tarde, cuando un incidente o una revisión de PR muestra que la automatización no estaba protegida como el equipo creía.

Señal de demanda

No hay volumen SEO conectado aquí y no conviene inventarlo. La demanda se infiere por señales técnicas: changelog oficial, adopción de MCP, uso creciente de hooks para seguridad y búsquedas probables como Claude Code hooks, mcp__brave-search, Claude Code PreToolUse, MCP tool matcher y Claude Code hook matcher.

Este es tráfico pequeño pero muy valioso. Quien busca esto no está leyendo IA por curiosidad; está conectando tools reales a un agente de coding y necesita que las reglas no fallen por sintaxis.

Qué haría esta semana

Si tu equipo ya usa Claude Code con MCP, haría una revisión corta:

  • listar todos los matchers que incluyen guiones;
  • separar match exacto de comodines por namespace;
  • probar un caso permitido y uno bloqueado por cada servidor crítico;
  • documentar la intención de cada patrón junto al hook;
  • evitar reglas "parecidas" que dependan de cómo alguien interpreta el nombre.

La conclusión es simple: un agente con buenas tools puede fallar por una mala regla alrededor de la tool. Este fix de Claude Code no es vistoso, pero empuja una práctica madura: tratar hooks, permisos y matchers como infraestructura, no como configuración casual.

Si todavía estás ordenando los fundamentos de tools y permisos, arranca por el curso gratis. Si ya operas MCP en flujos de coding, esta corrección debería disparar una auditoría pequeña antes de que otro nombre parecido pase inadvertido.