🚦 Política de autonomía

Hasta aquí conectaste herramientas y formaste un equipo. Falta la pregunta que decide si puedes dormir tranquilo: ¿qué puede hacer el agente sin ti?

A runtime/POLITICA.md responde con cinco niveles, de N0 a N4. La primera línea del archivo resume la idea: cuanto mayor sea el impacto de la acción, más participa la persona.

Qué revisar en la tabla: es la copia exacta de la sección «Niveles de autonomía» de la POLITICA.md. La diferencia entre N1 y N2 es quién presiona el botón: en N1 eres tú; en N2, el agente, con tu aprobación.

Cómo leer el diagrama: cada nivel le da más libertad al agente. El nivel ámbar (N2) es donde el kit pone todo lo que tiene impacto. Los niveles azules son para acciones que, si salen mal, puedes deshacer sin problemas.

Los niveles por sí solos no dicen nada. Cobran sentido cuando vinculas cada tipo de acción a un nivel máximo. Es la segunda tabla de la POLITICA.md, la de límite.

Las dos últimas columnas muestran cómo se convierte cada límite en una configuración: en Claude Code y en Codex. Verás ambas en los temas 4 y 5.

Qué revisar en la tabla: el límite baja a medida que aumenta el daño potencial. Leer no rompe nada (N4). Gastar y borrar son irreversibles (N1): el agente prepara y tú lo haces.

Leia runtime/POLITICA.md e responda em uma linha qual é o teto de 'Enviar'.

respondeu "N2" lendo a POLITICA

Cuando Claude Code pide permiso, ofrece "sí", "no" y una opción para no volver a preguntar. En la décima pregunta seguida, la tentación es hacer clic en la tercera. En uno de los videos de mods, incluso había un ayudante que aprobaba los permisos por su cuenta.

A POLITICA.md cierra esa puerta con una frase: un permiso de "permitir siempre" nunca supera el límite de la acción. Puedes permitir la lectura para siempre. No puedes permitir los pagos para siempre.

En Claude Code, la política se convierte en el archivo .claude/settings.json, que ya viene en el kit. Claude Code lee este archivo automáticamente al abrirse en la carpeta.

La parte que importa aquí es la lista deny: comandos que el agente no ejecuta, pide quién los solicita. Son los bloqueos básicos que la POLITICA.md cita para "borrar" y para el push forzado.

{
  "permissions": {
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)",
      "Bash(git push -f:*)",
      "Bash(git reset --hard:*)"
    ]
  },
  "enabledMcpjsonServers": [
    "ponte-modelo"
  ],
  "hooks": { ... }
}

Cómo leer el diagrama: ambas solicitudes pasan por la misma caja ámbar. Lo que no está en la lista sigue por la flecha azul. Lo que está en la lista se detiene en la flecha roja, sin preguntar y sin depender de que estés mirando.

Codex no lee el .claude/settings.json. En él, la política se introduce mediante sandbox, elegido con la opción -s en cada llamada. La tabla del límite ya indica cuál usar.

El puente runtime/pontes/codex-exec.sh, que usaste en el módulo 2.1, solo acepta dos valores. Cualquier otro se rechaza antes de que se invoque Codex.

Qué revisar en la tabla: enviar, gastar y borrar no tienen sandbox en el puente. Para esas líneas, la POLITICA dice «sin aprobación automática» o «no ejecutar»: Codex lo prepara y la acción queda en tus manos.

runtime/pontes/codex-exec.sh "x" . danger-full-access

sandbox recusado pela POLITICA, saída 2

case "$sandbox" in
  read-only|workspace-write) ;;
  *) echo "sandbox recusado pela POLITICA: $sandbox" >&2; exit 2 ;;
esac

Además de los niveles y el límite, la POLITICA.md tiene una sección corta llamada Integración. Son tres reglas sobre cómo se conectan las herramientas entre sí.

Protegen lo que ningún deny toma: la cuenta, la contraseña y la estabilidad de tu sistema.

Cómo leer el diagrama: por el puente ámbar solo pasa texto: la solicitud va, la respuesta vuelve. Los inicios de sesión quedan cada uno en su casilla. La línea roja discontinua es el camino que prohíbe la regla 2.