Permisos y modelos de seguridad

Las tres herramientas enfocan la seguridad de forma distinta: Claude Code gira en torno a modos y reglas de permisos (con un sandbox opcional), Codex a un sandbox del sistema operativo obligatorio más políticas de aprobación, y Kimi Code a modos y reglas de permisos sin ningún sandbox documentado.

Páginas relacionadas de cada herramienta: Claude Code — Permisos · Codex CLI — Permisos, sandbox y aprobaciones · Kimi Code — Permisos y aprobaciones

Modos de permisos

Claude Code — seis modos

Modo	Comportamiento
`default` (en las interfaces aparece como Manual)	Pregunta la primera vez que se usa cada herramienta
`acceptEdits`	Acepta solo las ediciones de archivos y los comandos habituales de sistema de archivos dentro del directorio de trabajo
`plan`	Exploración en solo lectura; no edita código fuente
`auto`	Aprueba solo las llamadas a herramientas, con comprobaciones de un clasificador de seguridad en segundo plano; es el modo por defecto desde agosto de 2026
`dontAsk`	Deniega automáticamente las herramientas salvo las aprobadas de antemano con reglas de permitir
`bypassPermissions`	Se salta las confirmaciones; pensado sólo para entornos aislados (contenedores o máquinas virtuales)

Se cambia de forma interactiva con Shift+Tab; el modo de arranque se fija con --permission-mode <modo> o el ajuste permissions.defaultMode. Los administradores pueden desactivar el modo de bypass por completo con permissions.disableBypassPermissionsMode en los ajustes gestionados.

Codex — política de aprobación × modo de sandbox

Codex separa cuándo preguntar de qué está permitido:

Políticas de aprobación (approval_policy / -a): untrusted (sólo se ejecutan solas las lecturas consideradas seguras), on-request (pregunta cuando hace falta salirse del sandbox; es el valor del preset interactivo Auto), never (no pregunta nunca; para ejecuciones no interactivas) o una tabla granular por categorías. on-failure está obsoleto.
Modos de sandbox (sandbox_mode / -s): read-only, workspace-write y danger-full-access (ver la siguiente sección).
Presets verificados: Auto = --sandbox workspace-write --ask-for-approval on-request (recomendado en carpetas con control de versiones); solo lectura en CI = --sandbox read-only --ask-for-approval never. Con approvals_reviewer = "auto_review" las peticiones de aprobación que apliquen pasan por un agente revisor automático.
/permissions cambia el modo a mitad de sesión.

Kimi Code — tres modos

Modo (nombre desde 0.41.0)	Valor en config	Comportamiento
Always Ask (antes Manual)	`manual`	El de por defecto. Las operaciones de solo lectura van solas; cada edición o comando se pregunta uno a uno
Ask When Needed (antes YOLO)	`yolo`	Aprueba solo las llamadas rutinarias; sigue preguntando por archivos sensibles (`.env`, claves SSH), comandos peligrosos y salidas del modo plan
Never Ask (antes Auto)	`auto`	Totalmente desatendido; todo se decide automáticamente y el agente nunca pregunta

Se cambia con /permission, /yolo y /auto; se arranca con --yolo / --auto; y el valor por defecto se fija en default_permission_mode. Una protección contra comandos peligrosos (activa por defecto) bloquea o pregunta ante comandos como shutdown y rm -rf en los modos Always Ask y Ask When Needed; en modo Never Ask esos comandos se ejecutan sin interrupción. Se desactiva con [permission] dangerous_command_guard = false (no recomendado).

Disponibilidad del sandbox por plataforma

Plataforma	Claude Code	Codex	Kimi Code
macOS	⚠️ Sandbox opcional (`sandbox.enabled`, apagado por defecto)	✅ Seatbelt vía `sandbox-exec`	❌ No hay ninguno documentado
Linux	⚠️ Sandbox opcional (apagado por defecto)	✅ `bwrap` + seccomp (WSL2 funciona; WSL1 no está soportado)	❌ No hay ninguno documentado
Windows	⚠️ Sólo con WSL2	✅ Sandbox nativo de Windows (`elevated`/`unelevated`) o el de Linux bajo WSL2	❌ No hay ninguno documentado

El sandbox de Codex está activo por defecto y lo impone el sistema operativo; incluso en workspace-write, <raíz>/.git, <raíz>/.agents y <raíz>/.codex siguen protegidos en solo lectura (por eso git commit puede seguir pidiendo aprobación). El acceso a red está apagado por defecto en workspace-write (sandbox_workspace_write.network_access = true para activarlo).
El sandbox de Claude añade listas blancas de dominios de red (network.allowedDomains) y autoAllowBashIfSandboxed (true por defecto: el Bash en sandbox se ejecuta sin preguntar). Por lo demás, las restricciones de sistema de archivos y de red se expresan con reglas de permisos de Read/Edit/WebFetch, no con ajustes del sandbox.
El modelo de seguridad documentado de Kimi Code son las aprobaciones de permisos más los hooks — y los hooks son fail-open (cualquier salida distinta de cero que no sea 2, o un timeout o una caída, deja pasar la acción), así que la documentación advierte de que no deberían ser la única barrera.

Ejemplos de sintaxis de las reglas

Claude Code (`permissions` en settings.json)

El orden de evaluación es deny → ask → allow, y gana la primera coincidencia. Formato: Herramienta o Herramienta(especificador).

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

Los especificadores admiten coincidencias exactas, comodines por prefijo (un * al final) y coincidencia por parámetro (Herramienta(parámetro:valor)). En los comandos de shell compuestos, cada subcomando tiene que coincidir con una regla de allow. “Sí, y no vuelvas a preguntar” guarda las reglas de Bash/WebFetch de forma permanente en .claude/settings.local.json.

Codex (archivos `.rules` de execpolicy, experimental)

Reglas en Starlark dentro de una carpeta rules/ junto a una capa de configuración (por ejemplo ~/.codex/rules/default.rules o <repo>/.codex/rules/). Gana la decisión más restrictiva (forbidden > prompt > allow).

prefix_rule(
    pattern = ["git", "push"],
    decision = "prompt",
    justification = "Hacer push requiere confirmación humana",
)

Prueba las reglas con codex execpolicy check --rules <archivo> -- <cmd>. Elegir “permitir siempre” en la TUI escribe en ~/.codex/rules/default.rules. Los perfiles de permisos con nombre ([permissions.<nombre>]) también admiten reglas de sistema de archivos y de red, con extends.

Kimi Code (`[[permission.rules]]` en config.toml)

Gana la primera coincidencia; las herramientas MCP coinciden sólo por nombre, con comodines */** (por ejemplo mcp__github__*).

[[permission.rules]]
pattern = "Bash(rm -rf*)"
decision = "deny"
scope = "user"
reason = "Nada de borrados recursivos"

[[permission.rules]]
pattern = "mcp__github__*"
decision = "ask"

decision es allow/deny/ask; scope es turn-override/session-runtime/project/user (por defecto user).

Flags de bypass — con mucho cuidado

Herramienta	Flag	Efecto
Claude Code	`--dangerously-skip-permissions`	Se salta todas las confirmaciones; la documentación lo recomienda sólo en entornos aislados (contenedores o VMs)
Codex	`--dangerously-bypass-approvals-and-sandbox` (alias `--yolo`)	Sin sandbox ni aprobaciones; la documentación lo marca como “riesgo elevado, no recomendado” y aconseja una VM dedicada como sandbox
Kimi Code	`--auto` (Never Ask)	Totalmente desatendido: todo se ejecuta solo, incluidos los comandos que la protección contra comandos peligrosos bloquearía; el modo no interactivo `-p` usa esto por defecto
Kimi Code	`--yolo` (Ask When Needed)	Se salta la aprobación de las llamadas rutinarias, incluidas escrituras de archivos y comandos de shell; la documentación avisa de usarlo sólo en directorios de trabajo de confianza

Ojo a la coincidencia de nombres: el --yolo de Codex desactiva el sandbox entero, mientras que el --yolo de Kimi conserva las confirmaciones para lo sensible y lo peligroso. No son equivalentes.

Recomendaciones

Nunca desactives las protecciones por defecto. Deja las confirmaciones activas en cualquier cosa que no sea un entorno desechable, y reserva los flags de bypass para contenedores o VMs efímeros sin credenciales.
Usa la configuración diaria de mínimo privilegio: en Claude Code los modos default/plan (o auto, que sigue pasando por el clasificador), en Codex el preset Auto (workspace-write + on-request) y en Kimi Always Ask o Ask When Needed.
Cuando el agente necesite un directorio extra, usa --add-dir (en las tres) antes que ampliar el sandbox o subir el modo de permisos.
Escribe tu política permanente como reglas de denegación (Read(./.env), Bash(rm -rf*), restricciones de mcp__*) en vez de depender de rechazos improvisados.
En Kimi Code, no trates los hooks como una frontera de seguridad — son fail-open por diseño.
Marca como de confianza una carpeta de proyecto (preguntas de confianza del workspace, servidores MCP de proyecto) sólo después de revisar qué activa de verdad su configuración.

Ú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.