Claude Code — Permisos · Agentes de IA para programar

Claude Code pregunta antes de actuar. Los modos de permisos fijan la postura general; las reglas allow/ask/deny afinan herramienta por herramienta; y el sandbox aísla los comandos de Bash a nivel de sistema operativo.

Modos de permisos

La documentación actual lista seis modos:

Modo	Comportamiento
`default`	Pregunta la primera vez que se usa cada herramienta. En las interfaces de CLI/IDE aparece como Manual; desde la v2.1.200 se acepta `manual` como alias
`acceptEdits`	Acepta automáticamente las ediciones de archivos y los comandos de sistema de archivos habituales (`mkdir`, `touch`, `mv`, `cp`) dentro del directorio de trabajo y de `additionalDirectories`
`plan`	Exploración en solo lectura; no edita código fuente (los comandos aprobados por el clasificador sí pueden ejecutarse)
`auto`	Aprueba automáticamente las llamadas a herramientas, con un clasificador de seguridad revisándolas en segundo plano. Es el modo por defecto desde agosto de 2026
`dontAsk`	Deniega automáticamente las herramientas salvo que estén aprobadas de antemano con `/permissions` o `permissions.allow`
`bypassPermissions`	Se salta las confirmaciones (excepto las acciones que ningún modo aprueba solo; las salvaguardas de mensajería entre sesiones siguen aplicándose). Sólo en entornos aislados — lee el aviso de abajo

Cómo cambiar de modo:

Shift+Tab rota entre modos dentro de la sesión (Auto-Accept / Plan / normal; Alt+M en algunas configuraciones).
Arranca en un modo concreto con claude --permission-mode <modo> o con el ajuste permissions.defaultMode.
Las empresas pueden desactivar modos por completo en los ajustes gestionados: permissions.disableBypassPermissionsMode: "disable" (que también desactiva --dangerously-skip-permissions) y permissions.disableAutoMode: "disable".

AVISO — bypassPermissions / --dangerously-skip-permissions

Se saltan todas las confirmaciones de permisos, así que Claude Code puede ejecutar cualquier comando — incluidos los destructivos — sin preguntar. Úsalos sólo dentro de entornos aislados y desechables (contenedores, máquinas virtuales), sin credenciales ni datos que te importen. Nunca los pongas por defecto, nunca los subas a una configuración compartida y nunca recomiendes desactivar protecciones para esquivar una confirmación molesta — añade una regla allow concreta (se tarda menos que en recuperar un directorio borrado).

Reglas allow / ask / deny

Las reglas viven en settings.json, bajo permissions, o se gestionan en la sesión con /permissions. Formato: Herramienta o Herramienta(especificador).

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git log *)",
      "Read",
      "WebFetch(domain:docs.example.com)",
      "mcp__notion__*"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Read(./.env)",
      "Task(Explore)"
    ]
  }
}

Cómo se hace la coincidencia:

Orden de evaluación: deny → ask → allow, y gana la primera que coincida.
Bash a secas significa todos los comandos de Bash; Bash(*) es equivalente. Como regla de deny, ambas eliminan la herramienta del contexto del modelo por completo.
Especificadores: Bash(npm run build) es una coincidencia exacta; Bash(npm run *) es por prefijo. El espacio final seguido de * también hace coincidir el comando a secas. El espacio importa: Bash(ls *) ≠ Bash(ls*) — el segundo también coincide con lsof. El sufijo :* equivale a un * al final (sólo al final).
Coincidencia por parámetros en las reglas de deny/ask: WebFetch(domain:example.com), Skill(nombre), Task(nombre-del-subagente), Agent(model:opus) — se admiten comodines * en los valores.
Comodines sobre el nombre de la herramienta en deny/ask: "*", "mcp__*". En allow sólo se permiten comodines después de un prefijo literal mcp__<servidor>__.
Comandos compuestos: cada subcomando separado por &&, ||, ;, |, |&, & o saltos de línea tiene que coincidir con una regla de allow.
Envoltorios que se quitan antes de comparar: timeout, time, nice, nohup, stdbuf, command, builtin, el noglob de zsh y xargs a secas. Los lanzadores de entorno (direnv exec, mise exec, npx, docker exec, …) no se quitan — escribe las reglas incluyendo el lanzador.
Elegir “Sí, y no vuelvas a preguntar” en Bash/WebFetch guarda la regla de forma permanente, por repositorio, en el .claude/settings.local.json de la raíz (desde la v2.1.211; antes se guardaba en el directorio desde el que arrancaste). Las aprobaciones de modificación de archivos duran sólo hasta el final de la sesión.

Sandbox

El sandbox ejecuta los comandos de Bash en un aislamiento a nivel de sistema operativo (macOS / Linux / WSL2). Se configura bajo sandbox en settings.json:

Ajuste	Para qué sirve
`sandbox.enabled`	Activa el sandbox (`false` por defecto)
`autoAllowBashIfSandboxed`	El Bash en sandbox se ejecuta sin preguntar (`true` por defecto; desde la v2.1.212 no se aplica en modo plan)
`excludedCommands`	Comandos que tienen que ejecutarse fuera del sandbox
`allowUnsandboxedCommands`	`true` por defecto; con `false` se desactiva la vía de escape `dangerouslyDisableSandbox`
`network.allowedDomains`	Destinos de red permitidos (admite comodines)
`network.allowUnixSockets` / `allowAllUnixSockets`	Acceso a sockets Unix
`allowLocalBinding`	Permite abrir puertos locales (macOS)
`httpProxyPort` / `socksProxyPort`	Puertos de proxy expuestos a los comandos en sandbox
`enableWeakerNestedSandbox`	Alternativa para sandbox anidado en Linux/WSL2 (reduce la seguridad)

Las restricciones de sistema de archivos y de red se expresan con reglas de permisos de Read/Edit/WebFetch, no con ajustes del sandbox.

Última verificación: 2026-09-07

Fuentes oficiales:

Las herramientas de IA para programar evolucionan rápido. Si encuentras información desactualizada, abre un issue o un pull request.