Claude Code auto-accept: permisos, reglas y sandbox para automatizar sin ceder el control
Claude Code puede aceptar ediciones y acelerar la iteración, pero aceptar todo no es una política de seguridad. Esta guía ordena los modos actuales, las reglas y el sandbox para automatizar sin entregar el repositorio ni sus secretos.
Si buscas Claude Code auto accept, mi recomendación es concreta: usa `acceptEdits` durante la iteración en un worktree, con una allowlist pequeña, `deny` para secretos y rutas peligrosas, hooks que hagan cumplir invariantes y revisión del diff antes de integrar. El modo acelera el trabajo repetitivo; no convierte al agente en una autoridad sobre tu máquina.
`plan` sirve para razonar y proponer una secuencia sin ejecutar cambios. `dontAsk` rechaza o evita preguntas interactivas y solo encaja cuando el entorno ya tiene una política explícita para lo que queda permitido. `bypassPermissions` salta confirmaciones: no limita el alcance, no sustituye un sandbox y solo merece un entorno efímero y desechable. Si aparece `auto` en una interfaz o integración, trátalo como una disponibilidad limitada y específica de esa superficie; no prometas compatibilidad universal ni asumas que significa lo mismo en todas las versiones.
Matriz de decisión rápida
| Situación | Modo inicial | Controles mínimos | Decisión | |---|---|---|---| |Explorar repo desconocido|`default` o `plan`|sin secretos en contexto, logs y revisión|pedir primero un plan| |Editar código en worktree|`acceptEdits`|allowlist, deny, hooks y tests|aceptar cambios, revisar diff| |CI no interactiva|`dontAsk`|permisos explícitos, repo efímero y artefactos|fallar cerrado si falta permiso| |Experimento destructivo|ningún modo global|contenedor/VM efímero sin secretos|aislar y destruir| |Producción o datos reales|`default`|aprobación humana y controles externos|no automatizar el bypass|
La matriz no pretende ser una promesa exacta de comportamiento entre clientes. Las superficies de Claude Code, Claude Desktop y el Agent SDK pueden exponer nombres o capacidades distintas. Comprueba la documentación de la versión que ejecuta tu equipo y prueba una acción negativa: la política solo existe si bloquea lo que debe bloquear.
Checklist
Configuración mínima en `.claude/settings.json`
Una configuración útil empieza pequeña. Declara herramientas de lectura y pruebas que el equipo entienda, y bloquea rutas donde suelen vivir credenciales, dumps o configuración operativa. Los patrones exactos dependen de la versión y del host; valida la sintaxis y no copies una allowlist sin comprobar qué expande cada patrón.
{"permissions":{"allow":["Read(src/**)","Edit(src/**)","Bash(git diff:*)","Bash(pytest:*)"],"deny":["Read(.env*)","Read(**/secrets/**)","Edit(.github/workflows/**)","Bash(rm:*)","Bash(curl:*)"]},"hooks":{"PreToolUse":[{"matcher":"Bash","hooks":[{"type":"command","command":"./scripts/check-agent-command.sh"}]}]}}
La allowlist anterior es deliberadamente modesta: limita edición al código de `src`, deja visibles diff y tests, y no autoriza por defecto red, borrado ni workflows. Ajusta los nombres de herramientas a la sintaxis que tu instalación soporte. Si un patrón no está claro, elimínalo y conserva la confirmación; una regla ambigua no es una protección.
¿Te está sirviendo? Hay una dosis cada semana
Te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.
Suscribirme gratisEl workflow que recomiendo
Empieza en `plan`: pide al agente que localice archivos, riesgos, pruebas y una secuencia de cambios. Después abre un worktree aislado y cambia a `acceptEdits` solo para la implementación descrita. El worktree hace visible la frontera de archivos y vuelve barato descartar una exploración que tomó una dirección equivocada.
Puntos a revisar
Lo que conviene comprobar
Cierra con tests y revisión: ejecuta los checks conocidos, inspecciona `git diff --stat` y el diff completo, revisa permisos y elimina cualquier cambio fuera del objetivo. Si algo requiere privilegios nuevos, vuelve a `default` y decide con contexto. La secuencia es plan → acceptEdits en worktree → tests → revisión/diff; saltarse el último paso destruye la trazabilidad que supuestamente comprabas con la velocidad.
Shift+Tab, settings y límites reales
El atajo Shift+Tab puede hacer cómodo cambiar de modo durante una sesión, y `.claude/settings.json` permite compartir parte de la política. Ninguno de los dos elimina la necesidad de verificar la versión ni de distinguir settings de proyecto, usuario y entorno. La configuración que funciona en tu terminal puede no tener la misma precedencia en Desktop, SDK o CI.
Documenta en el repositorio qué modo se espera para cada tarea y cómo probar la política. En particular, prueba lectura de `.env`, edición de un workflow, un comando con red y una operación destructiva. Si solo pruebas el caso feliz, confundirás una interfaz fluida con control efectivo. La guía de [Skills y SKILL.md](/claude-code-skills-skill-md-agentes/) ayuda a separar instrucciones reutilizables de permisos que deben vivir en la infraestructura.
Checklist
Permisos por equipo y subagentes
Un subagent no debería heredar automáticamente más autoridad de la que necesita. Define su contexto, herramientas y salida; un investigador puede leer y resumir, mientras que un implementador trabaja en un worktree con edición acotada. La separación reduce el impacto de una mala interpretación y hace más fácil atribuir qué hilo tocó qué archivo.
En equipos, comparte reglas versionadas y revisa excepciones como código. La guía sobre [subagents, contexto y permisos](/claude-code-subagents-contexto-permisos/) es una referencia útil para pensar en aislamiento, no una invitación a repartir credenciales. El agente que descubre una solución no tiene por qué ser el que la integra.
Observabilidad y auditoría
Registra modo, versión, worktree, herramientas invocadas, archivos cambiados, resultado de hooks, tests y decisión humana. Redacta tokens, cookies, rutas privadas y contenido de archivos sensibles. Una auditoría útil permite reconstruir por qué se aceptó una edición sin convertir el log en otra copia de los secretos.
Puntos a revisar
Lo que conviene comprobar
Mide tiempo hasta el primer diff válido, porcentaje de cambios rechazados, fallos de hooks, tests rotos y reversiones. Si `acceptEdits` reduce prompts pero aumenta cambios fuera de alcance, no has mejorado el sistema. El objetivo es una iteración más rápida con una superficie que se pueda explicar.
Preguntas frecuentes
¿`acceptEdits` acepta automáticamente cualquier comando?
No. Su propósito es aceptar ediciones de archivos; otras herramientas y acciones siguen sujetas a la política, hooks, allow/deny y confirmaciones de la superficie que uses.
¿`bypassPermissions` equivale a una allowlist amplia?
No. Es un bypass de confirmaciones, no una lista de capacidades. Úsalo solo en un contenedor o VM efímero sin secretos ni producción, y mantén controles externos.
¿Puedo usar `dontAsk` en GitHub Actions?
Sí, si el job es efímero y la política autoriza explícitamente la tarea, con credenciales mínimas y fallo cerrado ante cualquier permiso no previsto. No es una razón para activar bypass general.
¿Los hooks siguen importando con bypass?
Deben seguir siendo una frontera efectiva de seguridad; verifica la versión concreta con pruebas negativas, porque los detalles de integración pueden variar entre CLI, SDK y Desktop.
¿Qué modo uso para empezar?
`plan` para entender el cambio, `default` para explorar un repositorio desconocido y `acceptEdits` en un worktree cuando el alcance y las pruebas ya están claros.
Cómo automatizar ediciones de Claude Code con control
- Definir el alcance. Escribe objetivo, archivos permitidos, comandos de prueba, datos prohibidos y criterio de terminado antes de abrir el modo de edición.
- Planificar primero. Usa `plan` o `default` para localizar riesgos y obtener una secuencia; no aceptes cambios mientras aún estás descubriendo el repositorio.
- Aislar el trabajo. Crea un worktree o un checkout efímero, elimina secretos del entorno y configura hooks, deny y una allowlist mínima.
- Iterar con acceptEdits. Cambia a `acceptEdits` solo para la tarea acotada; deja `dontAsk` para CI explícitamente configurado y no uses bypass como atajo diario.
- Ejecutar evidencia. Corre tests, lint y comprobaciones de seguridad; registra el resultado y detén el job si falta un permiso o falla un hook.
- Revisar e integrar. Inspecciona diff y rutas tocadas, revierte lo inesperado y fusiona únicamente después de una revisión humana con contexto.
Checklist
Conclusión: velocidad con una frontera visible
Claude Code auto accept tiene sentido cuando reduce confirmaciones repetitivas en una zona que ya conoces. `acceptEdits` en un worktree, con deny, hooks, tests y diff revisable, es una mejora de flujo. `bypassPermissions` como configuración por defecto es otra cosa: borra preguntas sin crear límites y desplaza el riesgo al entorno.
La regla que dejaría escrita para un equipo es sencilla: automatiza la edición, no la autoridad. Si la sesión necesita leer secretos, tocar producción, abrir red o destruir datos, cambia de entorno o exige aprobación; no cambies una bandera esperando que la seguridad aparezca después.
Fuentes y referencias
También te puede interesar
Claude Code Skills y SKILL.mdClaude Code subagents: contexto y permisosClaude Code en GitHub ActionsPrompt injection en agentes de IAGit worktree para agentes en paraleloRecibe una lectura semanal de herramientas IA para devs
Cada semana te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.
Suscribirme gratis
