Kimi Code — Permisos y aprobaciones · Agentes de IA para programar

Los tres modos de permisos

Se renombraron en la 0.41.0; los valores de configuración siguen siendo manual/yolo/auto.

Modo	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 a herramientas normales; sigue preguntando por archivos sensibles (.env, claves SSH), comandos peligrosos (`shutdown`, `rm -rf`) y las salidas del modo plan; el agente todavía puede hacerte preguntas
Never Ask (antes Auto)	`auto`	Totalmente desatendido; todo se decide automáticamente y el agente nunca pregunta

Cómo cambiarlo: /permission en la TUI; /yolo (alias /yes) y /auto preseleccionan los dos últimos; los flags de arranque -y/--yolo y --auto; y el valor permanente default_permission_mode en config.toml.

AVISO — no pongas yolo/auto como valor por defecto. --yolo se salta la aprobación de las llamadas a herramientas normales, incluidas las escrituras de archivos y los comandos de shell; la documentación oficial dice que se use sólo en directorios de trabajo de confianza. Never Ask (--auto) va todavía más lejos: desde la 0.41.0 ya no bloquea los comandos peligrosos ni los que no se pueden analizar estáticamente, y el agente nunca pregunta. Deja default_permission_mode = "manual" y activa yolo/auto sesión a sesión, para una tarea acotada y en un directorio de confianza — nunca como recomendación general.

Protección contra comandos peligrosos

Añadida en la 0.40.0 ([permission] dangerous_command_guard, true por defecto): comandos como shutdown, reboot o rm -rf se bloquean o se preguntan en los modos Always Ask y Ask When Needed. En modo Never Ask se ejecutan sin interrupción (0.41.0: “el modo de permisos Auto ya no bloquea los comandos peligrosos ni los que no se pueden analizar estáticamente”). Se desactiva con dangerous_command_guard = false o KIMI_CODE_DANGEROUS_COMMAND_GUARD=false — no recomendado.

Aprobación por defecto de cada herramienta

Permitidas automáticamente (solo lectura): Read, Grep, Glob, ReadMediaFile, WebSearch, FetchURL, TodoList, Agent, AskUserQuestion, Skill, TaskList, TaskOutput, WaitFor, CronList, EnterPlanMode y ExitPlanMode (permitida, pero el usuario sigue confirmando el plan).
Requieren aprobación: Write, Edit, Bash, TaskStop, CronCreate y CronDelete.
AgentSwarm: permitida automáticamente en modo enjambre; fuera de él requiere aprobación en modo manual.

Teclas del panel de aprobación: flechas o 1–9 para elegir, Enter para confirmar, Esc/Ctrl-C/Ctrl-D para rechazar y Ctrl-E para ampliar la vista previa del diff. “Aprobar para esta sesión” aprueba automáticamente el mismo tipo de llamada durante el resto de la sesión.

Reglas permanentes: [[permission.rules]]

En ~/.kimi-code/config.toml:

[[permission.rules]]
decision = "allow"                 # allow | deny | ask
scope = "user"                     # turn-override | session-runtime | project | user (por defecto)
pattern = "Bash(git status*)"      # NombreHerramienta o NombreHerramienta(patrón-de-argumento)
reason = "git de solo lectura"

[[permission.rules]]
decision = "deny"
pattern = "Bash(rm -rf*)"
reason = "nunca borrar en recursivo sin preguntar"

[[permission.rules]]
decision = "allow"
pattern = "mcp__github__*"         # las herramientas MCP coinciden por nombre; comodines * y **

Gana la primera regla que coincida. Las herramientas MCP y AgentSwarm coinciden sólo por nombre (los argumentos no entran en la comparación).

Modo no interactivo

kimi -p se ejecuta con la política de permisos auto por defecto — sin aprobación humana. Las reglas estáticas de deny siguen aplicándose.

Estado del sandbox

? No se ha podido verificar: no hay ninguna funcionalidad de sandbox a nivel de sistema operativo documentada para Kimi Code CLI. El modelo de seguridad documentado son las aprobaciones de permisos más los hooks — y los hooks son fail-open (cualquier salida distinta de 2, los timeouts y las caídas dejan pasar la acción), así que la propia documentación advierte de que “no deberían usarse como única barrera de seguridad”. Si existe algún sandbox interno, no está verificado.

Relacionado: las carpetas no confiables muestran una pregunta de confianza del workspace antes de activar los servidores MCP del proyecto (la respuesta por defecto es “confiar en esta carpeta”).

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