Permitir a Codex y a Claude Code ejecutar comandos sin confirmación

Cuando usamos asistentes de programación en terminal, como Codex o Claude Code, una de las cosas que más corta el flujo de trabajo es tener que aprobar cada comando, cada edición o cada operación potencialmente sensible. Ese comportamiento tiene sentido por seguridad, dado que estas herramientas pueden leer ficheros, modificar código, ejecutar comandos, instalar dependencias, lanzar tests, borrar archivos o interactuar con Git. Pero también hay casos donde queremos que trabajen de forma más autónoma: por ejemplo, dentro de una máquina virtual, un contenedor, un entorno de laboratorio o un directorio de proyecto sin datos sensibles.

En este artículo veremos cómo ejecutar Codex y Claude Code sin confirmaciones constantes, qué comandos usar y qué riesgos tiene cada modo. Eso sí, no debemos ejecutar estos modos en nuestro $HOME, en /, en /etc, en /var, en /usr, ni en ningún directorio donde tengas información importante. Lo razonable es usarlos dentro de un entorno controlado o, mejor aún, dentro de una máquina virtual, un contenedor systemd-nspawn, Docker, Podman, LXC o una VM de Proxmox.

Codex

Codex permite controlar dos cosas distintas:

• La política de aprobaciones, que decide cuándo Codex debe pedir permiso.
• El sandbox, que decide qué puede tocar Codex cuando ejecuta comandos.

El comando más equilibrado para trabajar sin interrupciones, pero manteniendo cierto aislamiento, es este:

codex --sandbox workspace-write --ask-for-approval never

Con esto le estamos diciendo a Codex:

• Usa el sandbox workspace-write, permitiendo escribir dentro del workspace actual, pero desactivando la red por defecto, incluida la resolucción DNS).
• No pidas aprobación (impide que Codex solicite permiso para salir del sandbox. No concede acceso adicional).

Este modo es útil cuando queremos que Codex pueda editar archivos y ejecutar comandos dentro del proyecto, pero sin darle acceso completo al sistema.

Para activar la red:

codex \
  --sandbox workspace-write \
  --ask-for-approval never  \
  -c 'sandbox_workspace_write.network_access=true'

Otra opción es usar –ask-for-approval on-request; así Codex podrá pedir autorización cuando necesite red.

Qué hace exactamente workspace-write

El modo workspace-write permite que Codex pueda escribir SÓLO dentro del directorio del proyecto, aunque desactivando la red por defecto, incluida la resolucción DNS). Ejemplo:

cd ~/LabsIA/mi-proyecto
codex --sandbox workspace-write --ask-for-approval never

Con esto Codex podrá trabajar sobre los ficheros del proyecto sin preguntarnos cada dos por tres. La diferencia importante es que aquí no estamos desactivando el sandbox sino eliminando las confirmaciones, pero manteniendo una barrera de permisos.

Usar solo –ask-for-approval never

También podemos ejecutar:

codex --ask-for-approval never

Esto desactiva las solicitudes de aprobación, pero no define explícitamente el sandbox. En ese caso Codex usará la configuración que tenga por defecto o la que hayamos definido en su configuración. No es la opción más clara, porque no deja visible qué permisos reales estás usando.

Modo YOLO

Codex también tiene un modo más agresivo:

codex --yolo

Este comando es un alias de:

codex --dangerously-bypass-approvals-and-sandbox

Esto significa: sin aprobaciones y sin sandbox. Dicho claramente: este modo le da mucha más libertad a Codex. No solo deja de pedir confirmación, sino que además elimina la capa de aislamiento del sandbox. No deberíamos usarlo en nuestro sistema principal. Deberíamos usarlo ÚNICAMENTE dentro de un entorno aislado, por ejemplo:

• Una VM descartable.
• Un contenedor.
• Un entorno de laboratorio.
• Un proyecto sin secretos.
• Un sistema donde puedas romper cosas sin consecuencias.

Ejemplo razonable:

mkdir -p ~/LabsIA/codex-yolo
cd ~/LabsIA/codex-yolo
git init
codex --yolo

Ejemplo poco recomendable:

cd ~
codex --yolo

Peor todavía:

cd /
codex --yolo

Alias cómodo

Si vamos a usar este modo con frecuencia, podemos crear un alias.

Opción razonable:

echo "alias codex-auto='codex --sandbox workspace-write --ask-for-approval never'" >> ~/.bashrc
source ~/.bashrc

Después lo ejecutamos así:

codex-auto

Opción peligrosa:

echo "alias codex-yolo='codex --yolo'" >> ~/.bashrc
source ~/.bashrc

Y luego:

codex-yolo

El alias codex-auto es bastante más sensato para uso normal.

Configuración persistente

También podemos dejarlo configurado en el fichero de configuración de Codex. Editamos:

nano ~/.codex/config.toml

Y añadimos:

approval_policy = "never"
sandbox_mode = "workspace-write"

Con esto Codex usará por defecto el modo sin aprobaciones y con escritura limitada al workspace.

Si queremos una configuración más peligrosa, podríamos usar:

approval_policy = "never"
sandbox_mode = "danger-full-access"

Pero esto ya se parece más al modo YOLO. No es recomendable salvo en entornos aislados.

Claude Code

Claude Code tiene un sistema parecido de permisos. Por defecto, cuando quiere editar archivos, ejecutar comandos o hacer determinadas acciones, pide aprobación.

Modo bypassPermissions

Para saltarnos esas confirmaciones podemos usar:

claude --dangerously-skip-permissions

Este flag equivale a:

claude --permission-mode bypassPermissions

Modo auto

Si no queremos ir tan lejos, Claude Code también tiene el modo auto:

claude --permission-mode auto

Este modo reduce muchas confirmaciones, pero no es lo mismo que bypassPermissions.

La diferencia práctica es esta:

• auto intenta trabajar con menos interrupciones, pero mantiene comprobaciones de seguridad.
• bypassPermissions salta prácticamente todo el sistema de confirmaciones.

Para trabajar en proyectos reales, auto es más razonable. Para laboratorios aislados, bypassPermissions puede tener sentido.

NOTA: bypassPermissions no se puede activar si claude se está ejecutando como root o con sudo, excepto que «engañemos» a Claude Code haciéndole creer que ya está ejecutándose en un entorno aislado pasándole la variable de entorno IS_SANDBOX=1 antes de ejecutarlo:

IS_SANDBOX=1 claude --dangerously-skip-permissions

Hacer bypassPermissions permanente

Podemos configurar Claude Code para arrancar por defecto en modo bypassPermissions. Editamos:

nano ~/.claude/settings.json

Y dejamos algo parecido a esto:

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "bypassPermissions",
    "skipDangerousModePermissionPrompt": true
  }
}

La clave importante es esta:

"defaultMode": "bypassPermissions"

Y esta otra evita el aviso de entrada al modo peligroso:

"skipDangerousModePermissionPrompt": true

Alias cómodo

También podemos crear un alias:

echo "alias claude-yolo='claude --dangerously-skip-permissions'" >> ~/.bashrc
source ~/.bashrc

Y lanzarlo así:

claude-yolo

Otra opción menos agresiva:

echo "alias claude-auto='claude --permission-mode auto'" >> ~/.bashrc
source ~/.bashrc

Y luego:

claude-auto

Este el equivalente al comando de Codex:

claude --permission-mode auto --allow-dangerously-skip-permissions --settings '{"sandbox":{"enabled":true,"network":{"allowedDomains":["*"]}}}'

Para limitar el acceso de red sólo a determinados dominios:

claude --permission-mode auto --allow-dangerously-skip-permissions --settings '{"sandbox":{"enabled":true,"network":{"allowedDomains":["dominio1.com","api.dominio2.com"]}}}'

Enlaces oficiales

• Referencia oficial de Codex CLI
• Referencia oficial de Claude Code CLI