# Kimi Code Never Ask: modos y comandos peligrosos > En el modo Never Ask, Kimi Code ejecuta rm -rf y shutdown sin preguntar. ¿En qué se diferencian los 3 modos y cómo puedes prohibir un comando peligroso en config.toml? Source: https://ailoot.ai/blog/es/kimi-code-never-ask-mode/ Canonical: https://ailoot.ai/blog/es/kimi-code-never-ask-mode/ Language: es Publisher: Ailoot (https://ailoot.ai/) Translation: guide-162 Revision: sha256-58f1c39905ca808c894aa30af2ada4ea9acc1069eb3a8a056aafdd430f7e5dad En Kimi Code, el modo Never Ask (`/auto`) lo aprueba todo automáticamente: ejecuta `rm -rf`, `shutdown` y `reboot` sin hacer una sola pregunta. El agente solo pregunta antes de ejecutar estos comandos en los otros 2 modos, Always Ask y Ask When Needed. Yo mismo trabajo en Claude Code con la opción «permitir todo» activada; de lo contrario, nos quedaríamos ahí haciendo clic: sí, sí, sí. Pero una de cada 10 veces, el agente hace las cosas a su manera. Por suerte, había una copia de seguridad de 3 días antes. Incluso un prototipo personal puede exponer archivos y credenciales valiosos. Usa una copia o contenedor aislado con permisos limitados y una copia de seguridad verificada; para sistemas de clientes, utiliza además una identidad de base de datos separada con solo el acceso necesario. Así, aunque de verdad quiera borrar la base de datos, no podrá. Veamos qué hace cada modo de Kimi Code, dónde funciona la protección y cómo establecer una prohibición. Vamos allá. Para obtener información sobre cómo usar el servicio, consulta la [documentación de Ailoot](https://ailoot.ai/docs/).
Punto clave Kimi Code tiene 3 modos. Always Ask es el modo predeterminado: la lectura se realiza automáticamente y confirmas todo lo demás acción por acción. Ask When Needed (`/yolo`) aprueba por sí mismo las modificaciones habituales, pero pregunta antes de acceder a archivos que contienen claves, ejecutar comandos peligrosos o salir del modo de planificación. Never Ask (`/auto`) no pregunta nada y la protección contra comandos peligrosos no funciona en este modo. Para establecer una prohibición permanente, añade una regla `deny` a `~/.kimi-code/config.toml`. Es mejor no activar Never Ask cuando hay una base de datos en producción.
## ¿En qué se diferencian los 3 modos de Kimi Code? Si ya has [instalado Kimi Code](https://ailoot.ai/blog/es/kimi-code-install/), habrás visto el panel de aprobación: el agente quiere editar un archivo o ejecutar un comando y espera tu «sí». Antes, los modos se llamaban Manual, YOLO y Auto; por eso aún utilizan los comandos antiguos `/yolo` y `/auto`. **Always Ask.** El modo predeterminado. El agente lee archivos sin preguntar, pero confirmas cada modificación y cada comando por separado. Es el modo más lento. **Ask When Needed.** Se activa con `/yolo`. Aprueba por sí mismo las modificaciones y los comandos habituales, pero pregunta antes de acceder a `.env` (el archivo que contiene las contraseñas y claves del proyecto) y a las claves SSH del servidor; antes de ejecutar comandos peligrosos como `shutdown` (apagar el ordenador) y `rm -rf` (eliminar una carpeta entera sin pasar por la papelera); y antes de salir del modo de planificación. El agente también puede hacerte una pregunta por iniciativa propia. **Never Ask.** Se activa con `/auto`. Todas las aprobaciones se conceden automáticamente, incluidas las relativas a archivos sensibles y a salir del modo de planificación. El agente no te hace preguntas y lo decide todo por sí mismo.
Tabla de los tres modos de permisos de Kimi Code: Always Ask, Ask When Needed, Never Ask
3 modos de permisos en Kimi Code CLI.
El modo de planificación se activa por separado con `Shift-Tab` o `/plan`: primero, el agente escribe un plan y espera tu aprobación; después, modifica los archivos. ## Cuándo trabajo yo mismo sin confirmaciones En Claude Code, «permitir todo» es mi configuración predeterminada y está activada en cada chat nuevo. Sin ella, el vibe coding es demasiado lento. Un vibe coder ya entiende muy poco y, encima, tiene que pulsar botones todo el rato: sí, sí, sí, no, no, no. Pero en este modo el agente puede hacer cualquier imprudencia, incluso borrar una base de datos. Luego dirá «lo siento, te pido disculpas», pero a veces ya no hay forma de arreglar lo que ha hecho. Así que este modo es para quienes no tienen miedo, y tú eres responsable de usarlo. Estas son mis reglas. En proyectos personales, experimentos y prototipos, usa el modo sin confirmaciones solo en una copia o contenedor aislado sin archivos valiosos ni credenciales de producción, con permisos limitados y copia de seguridad. No tener clientes no protege tus archivos o claves; también hay que comprobar el aislamiento. Pero si activas este modo en el mismo proyecto que tiene acceso a un servidor de producción, basta con 1 prompt para que el agente borre allí la base de datos durante la noche y despliegue cambios en el sitio activo. ## Por qué una prohibición expresada con palabras no te protege Mucha gente escribe «no toques la base de datos» en las instrucciones del agente. No cuentes con que eso te salve. Le dices: colega, no te metas ahí. Pero se meterá de todos modos y cogerá lo que necesite cuando lo necesite. Especialmente el Kimi chino: incumplirá cualquier prohibición que establezcas. Los modelos estadounidenses están mucho mejor entrenados para no hacerlo. Sigo usando Kimi en mi trabajo. Kimi K3 es muy atento; lo uso para revisar si hay claves filtradas en los proyectos y recopilar información. Una vez agoté todos sus límites en un par de días. Kimi no da problemas y hace todo lo que le pides. Por eso necesitas aislarlo cuando trabajes con él. [Aquí](https://ailoot.ai/blog/es/kimi-k3-hands-on-review/) describí cómo lo probé en mis propias tareas. Necesitas 2 formas de aislamiento: 1. **Una lista de bloqueo de comandos en la configuración.** Bloquea llamadas coincidentes; un patrón para una forma de escribir un comando no cubre otras herramientas ni acciones equivalentes. Combínalo con permisos del sistema operativo, contenedor y base de datos. 2. **Acceso de solo lectura a la base de datos.** En la base de datos activa, el agente tiene un usuario independiente con permisos de solo lectura. Así, ni siquiera en Never Ask podrá borrar la base de datos. ## Dónde funciona la protección contra comandos peligrosos La protección integrada de Kimi Code contra comandos peligrosos está activada de forma predeterminada. En Always Ask y Ask When Needed, solicita confirmación antes de `shutdown`, `reboot` (reiniciar) o `rm -rf`. En Never Ask, estos comandos se ejecutan sin detenerse. Hay 2 excepciones: - `rm -rf` se ejecuta sin preguntar si solo elimina el contenido de las carpetas temporales `/tmp` o `/temp` (desde la versión 0.43.0); - en Ask When Needed, Kimi Code no pregunta por los comandos de terminal que no puede analizar de antemano (desde la versión 2.0.1). En la versión 0.40.0, el modo Auto bloqueaba los comandos peligrosos; ese bloqueo se eliminó en la versión 0.41.0.
Antes/ahora: el modo autónomo de Kimi Code antes bloqueaba los comandos peligrosos, pero ya no
0.40.0: Auto bloqueaba los comandos peligrosos. 0.41.0: se eliminó el bloqueo.
Puedes desactivar la protección con `dangerous_command_guard = false` en la sección `[permission]` del archivo de configuración `~/.kimi-code/config.toml` o con la variable `KIMI_CODE_DANGEROUS_COMMAND_GUARD=false`. Los desarrolladores recomiendan hacerlo solo en lugares donde los comandos peligrosos ya se interceptan externamente. ## Cómo establecer una prohibición permanente en Kimi Code Cuando el agente quiere cambiar algo, Kimi Code muestra un panel de aprobación: - **Aprobar**: usa las teclas de flecha y `Enter`, o pulsa directamente `1`, `2` o `3`; - **Rechazar**: `Esc`, `Ctrl-C` o `Ctrl-D`; - **Aprobar durante esta sesión**: se aprueba el mismo tipo de llamada hasta que termine la sesión; - **Reglas permanentes**: una regla permanente de permiso o denegación en el archivo de configuración. Las reglas permanentes se escriben en el archivo de configuración `~/.kimi-code/config.toml`, dentro de bloques `[[permission.rules]]`. Kimi Code las comprueba en orden y aplica la primera que coincide, así que coloca las prohibiciones por encima de los permisos. Cada regla tiene un `decision`: `allow` (permitir inmediatamente), `deny` (denegar inmediatamente) o `ask` (preguntar cada vez). Una prohibición para `rm -rf` y una pregunta antes de cualquier otro comando de terminal: ```toml [[permission.rules]] decision = "deny" pattern = "Bash(rm -rf*)" [[permission.rules]] decision = "ask" pattern = "Bash" ``` Para los comandos de terminal, el patrón va entre paréntesis: `Bash(command-pattern)`; para leer archivos, `Read(path-pattern)`. Las herramientas MCP, `AgentSwarm` y tus propias herramientas solo se pueden prohibir por su nombre completo. Si no tienes conocimientos técnicos y no quieres abrir el archivo de configuración, pega el siguiente prompt en el agente: él mismo encontrará qué debe restringir. Solo pídele que primero te diga cuánto te ralentizará. Si estás acostumbrado a trabajar sin confirmaciones, algunas cosas dejarán de funcionar después de añadir las prohibiciones. Este es mi prompt: ``` Analiza mi proyecto y dime si tienes acceso al servidor de producción, a la base de datos de staging y a las claves de producción. Si lo tienes, configura la protección contra comandos peligrosos: prohíbe eliminar carpetas enteras, ejecutar comandos que reescriban de forma irreversible el historial de cambios y enviar comandos directamente a la base de datos de producción. Primero muestra un plan con el formato «antes - después» y dime sinceramente cuánto me ralentizará. ``` He explicado cómo configurar lo mismo en Claude Code [en un artículo aparte](https://ailoot.ai/blog/es/claude-code-safe-overnight-setup/). Echa un vistazo también a [cómo el modo Auto de Claude Code comprueba las acciones del agente](https://ailoot.ai/blog/es/claude-code-auto-mode-classifier/). ## Qué modo elegir - **Quieres ver cada paso que da el agente:** Always Ask, el modo predeterminado. Confirmas todo excepto la lectura. - **Un proyecto personal o un prototipo sin clientes reales:** empieza con Always Ask o Ask When Needed. Considera Never Ask solo en una copia aislada y desechable, con permisos restringidos y sin datos ni claves valiosos; no gana seguridad por carecer de clientes. - **Un proyecto con clientes reales y acceso al servidor:** no actives Never Ask. Establece prohibiciones `deny` en `config.toml` y dale al agente acceso de solo lectura a la base de datos. Y haz una copia de seguridad de la base de datos en un equipo distinto del proyecto. Las demás reglas de seguridad están recopiladas [en un artículo aparte](https://ailoot.ai/blog/es/vibe-coding-security/). Adapta el modo de confirmación a los permisos de acceso de tu proyecto y comprueba dónde hacen falta prohibiciones.
### Fuentes - [Kimi Code: Interaction and input](https://moonshotai.github.io/kimi-code/en/g%75ides/interaction.md) — 3 modos de permisos, `/yolo`, `/auto`, protección contra comandos peligrosos en cada modo, el panel de aprobación y el modo Plan. - [Kimi Code: Configuration files](https://moonshotai.github.io/kimi-code/en/configuration/config-files.md) — `[[permission.rules]]`, el orden en que se comprueban las reglas, `dangerous_command_guard`, `KIMI_CODE_DANGEROUS_COMMAND_GUARD` y la ruta de `config.toml`. - [Kimi Code: Changelog](https://moonshotai.github.io/kimi-code/en/release-notes/changelog.md) — versiones 0.40.0, 0.41.0, 0.43.0 y 2.0.1: protección contra comandos peligrosos y el cambio de nombre de los modos.
Conoce [Ailoot](https://ailoot.ai/). ## Preguntas sobre Kimi Code ### ¿Never Ask es seguro simplemente porque mi proyecto no tiene clientes? No. El agente puede dañar archivos personales o exponer claves. Antes de considerar un modo sin confirmaciones, usa permisos restringidos, una copia desechable aislada o contenedor y una copia de seguridad. ### ¿Una regla deny para rm -rf sustituye al aislamiento? No. Bloquea llamadas coincidentes, no todas las formas equivalentes de cambiar archivos. Mantén los datos valiosos y credenciales de producción fuera del alcance del agente y usa una identidad de base de datos separada con solo los permisos necesarios. ## Ailoot · La empresa y su cartera de proyectos Ailoot se apoya en la experiencia operativa acumulada, una amplia base de clientes, un servicio estable y el seguimiento continuo de KPI. La empresa y su cartera de proyectos: millones de clientes; ventas por miles de millones al mes. Ailoot aplica esa experiencia operativa al acceso por API a funciones de IA en productos de clientes, agentes, aplicaciones y automatizaciones.