Ejecutar Claude Code sin supervisión sin arrepentirte

Empieza por la máquina, no por las opciones

Cada salvaguarda de abajo es más fácil cuando el agente se ejecuta en una máquina que no contiene nada más. En tu portátil, “permitirlo todo” incluye tu correo, tu gestor de contraseñas, tus credenciales de producción y tus fotos. En una máquina dedicada con un repositorio y un token limitado, “permitirlo todo” significa ese repositorio y ese token. La propia Anthropic recomienda usar el modo bypass en un entorno aislado. Pon el agente en uno y el resto de esta página se simplifica.

Los modos de permisos de Claude Code

Claude Code tiene cuatro modos. Elige uno por tarea, no uno para siempre.

• default. Pregunta antes de editar archivos y de ejecutar comandos de shell. Bien para trabajo interactivo. Mal para la noche.
• acceptEdits. Edita archivos del directorio de trabajo sin preguntar. Sigue preguntando antes de comandos de shell. Un buen término medio para refactorizaciones donde los tests son el juez.
• plan. Lee y piensa, pero no cambia nada. Úsalo para obtener un plan que revisas antes de la ejecución real.
• bypassPermissions. Ninguna pregunta. Es el modo sin supervisión. Úsalo solo en una máquina aislada y con las reglas deny de abajo activas.

Elige el modo al arrancar.

claude --permission-mode acceptEdits

O ponlo como predeterminado de un proyecto en su archivo de ajustes. Puedes hacer commit de ese archivo para que todo el equipo lo comparta.

// .claude/settings.json
{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

Las reglas deny funcionan en todos los modos

Esta es la parte que casi todo el mundo pasa por alto. Las reglas de permisos se aplican encima del modo, y una regla deny bloquea la acción incluso en modo bypass. Por eso las reglas deny son la red de seguridad real para las ejecuciones sin supervisión. Las reglas allow aprueban de antemano lo que aceptarías siempre, para que el agente no se quede parado en ello.

// .claude/settings.json
{
  "permissions": {
    "allow": [
      "Bash(npm test:*)",
      "Bash(npm run lint:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "Bash(git push origin HEAD:*)"
    ],
    "deny": [
      "Bash(git push:*--force*)",
      "Bash(git push origin main:*)",
      "Bash(rm -rf:*)",
      "Bash(curl:*)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(~/.ssh/**)"
    ]
  }
}

Lee la lista deny como una política, porque eso es. Nada de force push. Nada de push a main. Nada de borrados recursivos. Nada de peticiones salientes que el agente se invente. Nada de leer archivos de secretos. Ajústala a tu proyecto, pero mantén una lista deny en cada máquina sin supervisión.

Hooks para las reglas que un patrón no puede expresar

Algunas reglas dependen del contexto. Un hook ejecuta un script antes de una llamada a una herramienta y puede aprobarla, bloquearla o cambiarla. Uno habitual bloquea cualquier comando que mencione un hostname de producción, sea cual sea el comando.

// .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "./scripts/block-prod.sh" }
        ]
      }
    ]
  }
}

El script lee la llamada a la herramienta por la entrada estándar y sale con un código distinto de cero para bloquearla. Haz hooks pequeños y aburridos. Un hook que puede fallar sin que nadie se dé cuenta es peor que no tener hook.

Git es tu mejor salvaguarda

Los ajustes dentro del agente son una capa. El repositorio es una segunda capa, y le da igual qué agente esté en marcha.

• Protege main. Exige un pull request y un CI en verde para hacer merge. Así un push indebido no puede colar nada.
• Una rama por tarea. El agente empieza en una rama nueva y solo hace push de esa rama.
• Dale al agente un token que pueda hacer push de ramas y abrir pull requests, y nada más. Sin permisos de administración. Sin permisos de borrado. Un token de GitHub fine-grained limitado a un repositorio hace justo eso.
• Los tests son el juez. Si la suite falla, el pull request sigue en rojo y lo ves por la mañana.

Credenciales: las mínimas, y separadas

Nunca pongas una credencial personal en una máquina sin supervisión. Crea una cuenta o un token aparte para el agente, con el alcance más pequeño que le permita hacer la tarea. Staging, no producción. Solo lectura cuando leer basta. Si el agente tiene que iniciar sesión en un servicio desde un navegador, que use una cuenta de prueba. Rota el token cuando termine el proyecto.

Ejecuciones headless con un límite

Para una tarea con script, el modo print ejecuta un prompt y termina. Ponle un límite de turnos para que un agente confundido no se pase la noche dando vueltas.

claude -p "Fix the failing tests in packages/api and open a PR" \
  --permission-mode acceptEdits \
  --max-turns 60

Guarda la salida en un archivo. Por la mañana quieres leer lo que hizo, no adivinarlo.

Las mismas reglas para Codex

Codex CLI separa dos preguntas. Cuándo pide aprobación y qué puede tocar. Para una tarea sin supervisión dentro de un repositorio, la combinación es no preguntar nunca y escribir solo dentro del espacio de trabajo.

codex -a never -s workspace-write exec "Fix the failing tests and commit"

Codex también tiene una opción que quita a la vez las aprobaciones y el sandbox. Trátala exactamente igual que el modo bypass de Claude Code. En una máquina aislada o nunca.

La lista de lo que nunca

Uses la herramienta que uses, un agente sin supervisión no debería poder hacer nada de esto. Si tu configuración permite alguna de estas cosas, arréglalo antes de la primera noche.

• Hacer push a una rama protegida o force push a cualquier sitio.
• Leer o enviar un secreto que no necesitaba para la tarea.
• Tocar datos de producción, ni siquiera para leerlos.
• Gastar dinero. Nada de consolas de nube, páginas de pago ni cuentas de anuncios.
• Enviar mensajes a personas. Ni correo, ni chat, ni redes sociales.
• Borrar algo fuera del árbol de trabajo.