Objetivo del tema
Comprender cómo controla Qwen Code las acciones de riesgo, qué significan sus distintos approval modes, cómo se relacionan con los permisos reales de edición y ejecución, y por qué trusted folders forma parte central de la seguridad operativa del producto.
Este tema se apoya en la documentación oficial disponible al 11 de abril de 2026, especialmente en Approval Mode y Trusted Folders dentro de Qwen Code Docs.
Qwen Code no es una herramienta de consulta pasiva. Puede leer archivos, proponer cambios, editar código y ejecutar comandos del sistema. Precisamente por eso necesita un sistema de seguridad operativa más fino que el de un chatbot tradicional.
La documentación oficial aborda esta necesidad con dos mecanismos complementarios:
La seguridad en Qwen Code no depende de un único botón de “permitir o no permitir”. Es una combinación de modos, contexto del proyecto y decisiones explícitas del usuario.
Un approval mode es una política de permisos que define cómo puede actuar Qwen Code sobre el proyecto y el sistema. La documentación oficial actual presenta cuatro modos:
Cada uno representa un equilibrio diferente entre control humano, velocidad y nivel de riesgo aceptado.
| Modo | Edición de archivos | Comandos shell | Nivel de riesgo |
|---|---|---|---|
| Plan | No edita | No ejecuta | Muy bajo |
| Default | Con aprobación manual | Con aprobación manual | Bajo |
| Auto-Edit | Autoaprobada | Con aprobación manual | Medio |
| YOLO | Autoaprobada | Autoaprobado | Alto |
La documentación describe Plan mode como un modo orientado a análisis y planificación, sin edición de archivos ni ejecución de comandos. Es la opción más segura para explorar una base de código sin riesgo operativo.
Conviene usarlo cuando:
La documentación también indica que se puede entrar en este modo con:
/approval-mode plan
Además, en consultas headless la documentación lo vincula con el uso de qwen --prompt o -p.
Desde un punto de vista didáctico, Plan mode es ideal para pensar antes de actuar.
Default mode es el modo estándar de trabajo de Qwen Code. En este modo, cualquier operación sensible requiere aprobación manual: tanto la edición de archivos como la ejecución de comandos.
La documentación lo recomienda especialmente para:
Es el modo más razonable cuando querés productividad sin perder control. Por eso, para muchos usuarios, debería ser el punto de partida habitual.
/approval-mode default
También puede definirse como modo por defecto en configuración:
{
"permissions": {
"defaultMode": "default"
}
}Auto-Edit es un modo intermedio. Según la documentación, permite aprobar automáticamente las ediciones de archivos, pero mantiene aprobación manual para comandos del sistema.
Su lógica es muy clara:
Esto lo vuelve útil para refactors, cambios repetitivos o tareas de edición relativamente seguras, pero todavía con un nivel prudente de control operativo.
/approval-mode auto-edit
La documentación lo sugiere para desarrollo cotidiano, automatización moderada y colaboración relativamente segura.
El modo YOLO es el más permisivo. En este modo, tanto la edición de archivos como la ejecución de shell quedan autoaprobadas.
La documentación oficial es explícita: este modo debe usarse con cautela. Solo tiene sentido cuando:
/approval-mode yolo
También se puede establecer a nivel de proyecto o de usuario, según la documentación:
/approval-mode yolo --project
/approval-mode yolo --user
En la práctica, YOLO debe verse como una herramienta de automatización para entornos muy controlados, no como el modo estándar de trabajo.
Cuanto más poder operativo tiene el agente, mayor tiene que ser la confianza en el proyecto, en el entorno y en el propio flujo de trabajo.
La documentación oficial indica dos mecanismos principales para cambiar de approval mode:
/approval-modeSegún la documentación, el atajo es Shift+Tab, o simplemente Tab en Windows. El indicador visual en la barra inferior muestra el modo actual.
Esto importa porque la seguridad operativa en Qwen Code no es fija: puede ajustarse a la tarea que se está haciendo en ese momento.
No existe un único modo correcto para todas las situaciones. La elección depende del contexto.
| Escenario | Modo recomendado | Razón principal |
|---|---|---|
| Explorar una base desconocida | Plan | No querés riesgo operativo todavía. |
| Desarrollo normal y prudente | Default | Mantiene control sobre ediciones y shell. |
| Refactors repetitivos con bajo riesgo | Auto-Edit | Agiliza cambios de código sin liberar ejecución de shell. |
| Automatización personal en entorno confiable | YOLO | Reduce fricción al máximo. |
Una regla pedagógica muy razonable es esta: empezar en Plan o Default y subir permisos solo si la tarea lo justifica.
La documentación de Trusted Folders agrega una capa de seguridad diferente pero complementaria. Mientras approval modes define cómo puede actuar el agente, trusted folders define en qué proyecto se habilita el comportamiento completo.
La idea es sencilla: no todos los repositorios merecen el mismo nivel de confianza. Si Qwen Code abre una carpeta no confiable, entra en un modo restringido para proteger al usuario frente a configuraciones o comportamientos potencialmente peligrosos.
La documentación explica que esta función está desactivada por defecto y puede activarse así:
{
"security": {
"folderTrust": {
"enabled": true
}
}
}La documentación oficial enumera con claridad las restricciones de un workspace no confiable. En ese “safe mode”:
.qwen/settings.json del proyecto.env del proyectoEsto es muy importante porque evita que un repositorio desconocido inyecte configuración local, secretos o automatizaciones sin consentimiento explícito.
La documentación indica que las decisiones de confianza se guardan en:
~/.qwen/trustedFolders.json
Eso significa que la decisión no pertenece al proyecto, sino al entorno del usuario. En consecuencia, la misma carpeta puede ser confiable para una persona y no confiable para otra.
También se puede modificar la confianza desde dentro del CLI usando el comando:
/permissions
La documentación de otras áreas también menciona /trust en determinados contextos, por ejemplo con soporte LSP. Lo importante para el curso es entender la lógica general: la confianza del workspace forma parte del modelo de seguridad.
Este punto conviene remarcarlo porque suele generar confusión:
Es decir, podrían coexistir situaciones como estas:
La seguridad operativa real de Qwen Code surge de la combinación de ambos mecanismos.
Los riesgos principales que la documentación intenta mitigar son bastante concretos:
Desde un criterio práctico, estas reglas suelen funcionar bien:
Muchos problemas no son errores del producto, sino decisiones de modo mal calibradas o malentendidos sobre confianza del workspace.
| Problema | Causa probable | Primer paso razonable |
|---|---|---|
| Qwen Code no usa la configuración local del proyecto | La carpeta no fue marcada como confiable. | Revisar trusted folders o ejecutar /permissions. |
| El agente pide demasiadas aprobaciones | Estás en Default mode o en un workspace no confiable. | Revisar el mode actual y el estado de confianza del folder. |
| El agente editó más de lo esperado | Se está usando Auto-Edit o YOLO sin el contexto adecuado. | Bajar a Default mode para recuperar control manual. |
| Un script o comando sensible corrió sin revisión | Se estaba en YOLO o en una política demasiado permisiva. | Volver a Default o Plan para tareas delicadas. |
Qwen Code trata la seguridad operativa como una parte central del flujo de trabajo. Approval modes regulan el nivel de autonomía del agente, mientras que trusted folders protege al usuario frente a proyectos no confiables o configuraciones locales potencialmente riesgosas.
En este tema vimos las ideas centrales:
Con esta base, el siguiente paso natural es estudiar el sandboxing y el aislamiento de procesos, que añaden otra capa de seguridad al trabajo con Qwen Code.