Claude Code 2.1.268: qué se corrigió en las reglas deny y MCP

Claude Code versión 2.1.268 se publicó el 10 de septiembre de 2026 y al día siguiente le siguió la versión 2.1.269. Deberías actualizar de inmediato: en dos casos, las reglas de denegación que usas para impedir que el agente acceda a .env y a las carpetas de servicios no surtían efecto sin avisar. Además, el comando /mcp podía mostrar secretos de tus archivos de configuración en el terminal.

Todo lo que sigue se basa en el registro de cambios y la documentación oficiales de Anthropic tal como estaban el 17 de septiembre de 2026, la fecha del material de origen. La versión más reciente en esa fecha era la 2.1.274. Describimos cómo funcionaban los errores basándonos en esas entradas; no se reprodujeron los métodos para eludir las restricciones en la versión vulnerable.

Para obtener más instrucciones sobre cómo trabajar con Ailoot, consulta la documentación.

¿Qué se corrigió en Claude Code 2.1.268 y 2.1.269?#

Cuatro correcciones afectan a las reglas de permisos:

1. Las denegaciones en enlaces simbólicos no funcionaban. Las reglas deny y ask definidas para directorios enlazados simbólicamente (/etc, /tmp, /var en macOS, /bin en Linux) no se activaban cuando se especificaba una ruta mediante su ubicación real. Los comandos Bash también ignoraban las reglas de denegación definidas para una ruta a través de un enlace simbólico.
2. La denegación de lectura y edición fallaba junto con env -C o eval. Si la misma línea de comandos contenía una construcción que la comprobación de permisos no podía analizar, deny en Read o Edit podía no activarse.
3. Una regla con «!» se aplicaba de forma más amplia de lo previsto. Una regla deny o ask que comenzaba con ! se aplicaba fuera del archivo de configuración en el que estaba escrita. Ahora solo se aplica dentro de su propio origen, y se ignora una negación independiente !.
4. tee escribía sin respetar las denegaciones. Las reglas deny para Edit() y la comprobación de la ruta de escritura no se aplicaban a los archivos creados con el comando Bash tee. El permiso Bash(tee:*) ya no cubre escrituras fuera de los directorios de trabajo.

Estas versiones también corrigieron dos problemas de exposición de secretos. WebFetch ya no espera indefinidamente una respuesta de un servidor que mantiene abierta la conexión: la solicitud ahora falla después de 300 segundos y el tiempo límite se puede configurar con la variable CLAUDE_CODE_WEBFETCH_DEADLINE_MS. También eliminaron el uso elevado y persistente de la CPU en sesiones largas inactivas.

¿Cómo funcionan las denegaciones en Claude Code?#

Claude Code tiene tres listas de reglas: deny (siempre prohibido), ask (preguntar antes de realizar la acción) y allow (permitido sin confirmación). Cuando el agente está a punto de hacer algo, las reglas se comprueban estrictamente en ese orden. Una regla deny coincidente anula cualquier regla allow para la misma acción: una regla que permite una acción no puede crear una excepción a una denegación.

Las reglas se guardan en tres lugares: las reglas de usuario en ~/.claude/settings.json, las reglas del proyecto en .claude/settings.json dentro del repositorio y las reglas locales en .claude/settings.local.json. Aquí tienes un ejemplo de configuración que deniega la lectura de un archivo con claves:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(rm *)"
    ]
  }
}

Puedes ver todas las reglas activas y el archivo del que procede cada una ejecutando /permissions en una sesión. Si una regla bloquea la lectura, la denegación indica qué regla es; esto será útil para la comprobación que se explica más abajo.

¿Qué errores corrigió Claude Code en las reglas deny?#

Los errores afectaron a las comprobaciones de rutas y comandos, así como al alcance de las reglas de distintos archivos de configuración.

Primer caso: enlaces simbólicos. En macOS, /etc, /tmp y /var son enlaces simbólicos a carpetas reales en /private; en Linux, /bin suele ser un enlace similar. Si escribías una regla de denegación para una forma de una ruta, pero el agente accedía a ella con otra (por ejemplo, mediante su ubicación real en vez del enlace simbólico), la regla no se activaba. Los comandos Bash también ignoraban una denegación definida para una ruta a través de un enlace simbólico. En 2.1.268 se corrigieron ambos casos: ahora la regla se aplica independientemente de la forma de la ruta que se use.

Segundo caso: env -C y eval en la misma línea. La comprobación de permisos analiza un comando para averiguar a qué archivos accederá. No puede analizar construcciones como env -C o eval. El fallo consistía en que, cuando aparecía una de esas construcciones en la línea, deny para Read o Edit podía no aplicarse. Como resultado, el comando podía eludir la denegación al leer o editar un archivo protegido.

Tercer caso: una regla con «!» se aplicaba fuera de sus límites. Una regla que empieza con ! debería aplicarse solo dentro del archivo de configuración donde está escrita. Antes de 2.1.269, también se aplicaba a otros orígenes de configuración. Ahora su alcance se limita a su propio archivo, y se ignora una regla que consista únicamente en !.

Cuarto caso: escritura mediante tee. El comando Bash tee puede escribir en un archivo. La comprobación de la ruta de escritura y las reglas deny para Edit() no se aplicaban a ese archivo. Al mismo tiempo, el permiso Bash(tee:*) cubría escrituras fuera de los directorios de trabajo. En 2.1.269, estas comprobaciones empezaron a aplicarse a las escrituras mediante tee: la denegación del archivo surte efecto, y Bash(tee:*) solo cubre los directorios de trabajo.

Si usas denegaciones específicas para bloquear .env, algunas carpetas de servicios o comandos peligrosos, también deberías comprobarlas. Los pasos están más abajo.

¿Por qué podía /mcp mostrar tus claves?#

Las configuraciones de servidores MCP suelen guardar las claves en variables de entorno y hacer referencia a ellas mediante ${VAR}, para que el archivo pueda almacenarse en un repositorio sin incluir los propios secretos. El problema era que los comandos para ver la configuración (/mcp, /plugin, claude mcp list, claude mcp get) y los mensajes de error al iniciar sesión en MCP mostraban la configuración con los valores ya sustituidos. La clave aparecía en pantalla.

Otra corrección afecta a los errores de plugins y marketplaces: podían mostrar un token o una contraseña de la URL del repositorio Git de origen.

Si la salida de /mcp o claude mcp list de una versión anterior apareció en una transmisión, una captura de pantalla, un mensaje a un colega o un registro que salió de tu equipo, incluso automáticamente, da por hecho que las claves de tus configuraciones MCP quedaron expuestas y cámbialas. Si la salida nunca salió de tu equipo, basta con actualizar. Tenemos una guía aparte sobre servidores MCP y configuraciones listas para usar: Servidores MCP de Claude Code.

Otros cambios en estas versiones#

WebFetch y los artefactos. Antes, una regla de WebFetch sin detalles en deny o ask también se aplicaba a la lectura y modificación de artefactos publicados. Desde 2.1.268, ya no se aplica a ellos. Para bloquear artefactos, necesitas una regla Artifact aparte o una regla para el dominio, como WebFetch(domain:claude.ai). Si confiabas en una denegación general de WebFetch para impedir la lectura de artefactos, vuelve a revisar tu configuración: la regla anterior ya no bloquea estas acciones.

WebFetch ahora tiene un tiempo límite. Una solicitud a un servidor que mantiene la conexión abierta y no termina de responder ahora falla después de 300 segundos. Antes, la solicitud podía quedarse colgada indefinidamente. El comportamiento se puede configurar con la variable CLAUDE_CODE_WEBFETCH_DEADLINE_MS; si se establece en 0, se desactiva el tiempo límite.

Se eliminó el uso elevado y persistente de la CPU en sesiones inactivas. Durante sesiones largas inactivas, un bucle de inactividad en Claude Code podía provocar un uso elevado y persistente de la CPU. Este error se corrigió en 2.1.268. También podía afectar a quienes mantienen las sesiones abiertas todo el día.

Instala la versión más reciente. En 2.1.269 apareció un nuevo error: después de que una sesión llevara mucho tiempo activa, los comandos Bash de Git que solo leían datos empezaban a pedir permiso. Se corrigió en 2.1.270. Así que actualiza a la versión más reciente (a fecha del 17 de septiembre de 2026, era la 2.1.274); no te quedes en la 2.1.268 ni en la 2.1.269.

¿Cómo actualizar y comprobar que las denegaciones funcionan?#

1. Averigua qué versión tienes. Ejecuta claude --version en el terminal. Las correcciones para los problemas descritos arriba se publicaron en las versiones 2.1.268 y 2.1.269. Si tu número de versión es inferior a 2.1.268, aún no incluye estas correcciones, aunque la aplicabilidad de cada problema depende de las rutas, los comandos y las reglas que uses.
2. Actualiza. La guía cómo actualizar Claude Code a la versión más reciente contiene instrucciones paso a paso y consejos para solucionar problemas. Elige la versión más reciente; no te quedes en la 2.1.268.
3. Prueba la denegación. No pruebes una regla con un archivo .env real: si la denegación falla, el agente verá claves reales. Crea un archivo de prueba, por ejemplo, secret-test.txt, que contenga cualquier texto, como «esto es una prueba»; añade la regla "Read(./secret-test.txt)" a la lista deny de .claude/settings.json del proyecto; reinicia la sesión y pide: «lee el archivo secret-test.txt y dime qué contiene». El resultado esperado es una denegación que mencione tu regla. Si el agente lee el archivo, la denegación no ha funcionado en esta prueba. Empieza por comprobar la sintaxis en la sección anterior y abre /permissions para ver las reglas activas y los archivos desde los que se cargaron. El resultado de la prueba por sí solo no identifica la causa. Una denegación demuestra que la regla para este archivo funciona; no dice nada sobre tus otras reglas, así que compruébalas una por una de la misma manera.
4. Comprueba el caso de los enlaces simbólicos si usas rutas como estas. Si tienes denegaciones para /tmp, /etc o /var en macOS, o para /bin en Linux, después de actualizar repite la prueba con esas rutas.
5. Revisa las reglas con «!». Si has usado alguna, comprueba que esté escrita en el archivo donde debe aplicarse.

Si la denegación funciona pero Claude Code sigue sin poder ver los archivos que necesitas, consulta la explicación aparte: por qué Claude Code no puede ver los archivos del proyecto.

Si no puedes actualizar ahora mismo#

A veces tienes que aplazar una actualización: no puedes cambiar el entorno, el equipo pertenece a la empresa o necesitas terminar la tarea actual. Hasta que actualices, puedes reducir el riesgo de esta forma:

• escribe reglas de denegación para las dos formas de la ruta: el enlace simbólico y la ubicación real (en macOS, las rutas reales están bajo /private);
• no combines varios comandos en una sola línea y evita env -C y eval en los comandos que pidas ejecutar al agente;
• no muestres a nadie la salida de /mcp, /plugin, claude mcp list o claude mcp get, y cambia las claves de las configuraciones MCP que puedan haber caído en manos de otras personas;
• recuerda que tee elude deny para Edit: no des por protegidos los archivos si Bash está permitido.

Estas medidas reducen la probabilidad de ciertos métodos para eludir las restricciones, pero no sustituyen la corrección. Actualiza y realiza la prueba de la sección anterior en cuanto puedas.

Resumen breve#

Las versiones 2.1.268 y 2.1.269 corrigieron cuatro problemas de permisos de Claude Code: los enlaces simbólicos, las líneas con env -C y eval, las reglas con «!» que se aplicaban más allá de su propio archivo y las escrituras mediante tee. Por separado, corrigieron la exposición de secretos en la salida de /mcp y de tokens en los errores de plugins. Comprueba el número de tu versión, actualiza a la versión más reciente y haz la prueba con un archivo de prueba de la sección anterior. Una denegación que menciona tu regla demuestra que la denegación funcionó en esta prueba. La mera presencia de la regla en la configuración no basta para verificar que funciona.

Para seguir trabajando con modelos, puedes ir a Ailoot.