Permisos

El sistema de permisos controla qué acciones puede realizar el agente sin pedir tu aprobación. Puedes aprobar de antemano las acciones seguras, bloquear las peligrosas y solicitar siempre confirmación para operaciones sensibles.

Comportamiento predeterminado de los permisos

Devin CLI usa un sistema de permisos por niveles para equilibrar capacidad y seguridad. El comportamiento predeterminado depende del modo actual: Cada celda muestra si esa herramienta se ejecuta automáticamente (Auto, sin solicitud de confirmación) o si espera tu aprobación (Solicitar confirmación) en ese modo:

Tipo de herramienta	Ejemplo	Normal	Aceptar ediciones	Smart	Omitir	Autónomo (sandbox)
Solo lectura	Lecturas de archivos, grep, glob	Auto	Auto	Auto	Auto	Auto
Fetch	Solicitudes HTTP	Solicitar confirmación	Solicitar confirmación	Auto cuando se considere seguro	Auto	Auto
Comandos de Bash	Ejecución del shell	Solicitar confirmación	Solicitar confirmación	Auto cuando se considere seguro	Auto	Auto
Ediciones de archivos mediante `edit`/`write`	Editar/escribir archivos	Solicitar confirmación	Auto (en el workspace)	Auto (en el workspace)	Auto	Solicitar confirmación

En el modo Normal (el predeterminado), las operaciones de solo lectura se aprueban automáticamente, mientras que las escrituras y los comandos de shell requieren tu aprobación explícita. Cada vez que apruebas una acción, puedes elegir permitirla una vez, durante la sesión o de forma permanente para el proyecto. En el modo Aceptar ediciones, las ediciones de archivos dentro del workspace se aprueban automáticamente, pero los comandos de shell y las escrituras fuera del workspace siguen requiriendo aprobación. En el modo Smart, las ediciones en el workspace se aprueban automáticamente como en Aceptar ediciones, y todas las demás acciones son evaluadas por un modelo rápido que solo las ejecuta automáticamente cuando son claramente seguras. Todo lo demás solicita confirmación como de costumbre. Consulta el modo Smart a continuación. En el modo Omitir, todas las llamadas a herramientas se aprueban automáticamente sin solicitar confirmación. En el modo Autónomo, los comandos de shell y las solicitudes de red se aprueban automáticamente porque el sandbox a nivel del sistema operativo limita a qué pueden acceder. Las ediciones directas de archivos mediante las herramientas edit/write siguen requiriendo aprobación, porque esas herramientas funcionan fuera del sandbox. Autónomo solo está disponible cuando el sandbox a nivel del sistema operativo está activo.

Los modos Smart, Omitir y Autónomo no anulan los permisos a nivel de organización. Las Rules de denegación y de solicitud impuestas por el Admin y configuradas mediante Team Settings permanecen activas independientemente del modo de permisos del usuario. Consulta Precedencia para obtener más información.

Modo Smart

Smart se sitúa entre Aceptar ediciones y Omitir. Las ediciones de archivos del workspace se aprueban automáticamente, igual que en Aceptar ediciones. Para todas las demás acciones —comandos de shell, solicitudes de red, herramientas MCP y escrituras fuera del workspace—, un modelo rápido evalúa si la acción se puede ejecutar de forma desatendida de manera segura. Si es claramente segura, se ejecuta sin solicitar aprobación; si no lo es, o si el modelo no está seguro o no está disponible, se muestra la solicitud de aprobación normal.

/smart
# o
/mode smart

También puedes cambiar al modo Smart con Shift+Tab, seleccionarlo en el selector de modo o iniciarlo:

devin --permission-mode smart
# o
DEVIN_PERMISSION_MODE=smart devin

El criterio del modelo se limita a tareas rutinarias de desarrollo: compilación, pruebas, linting, formateo e inspección del proyecto. Algunas categorías nunca se aprueban automáticamente en el modo Smart, sin importar lo que determine el modelo:

Instalación de paquetes (npm install, pip install, cargo install, brew install, …)
Operaciones de git que modifican contenido (los subcomandos de solo lectura, como git status, siguen siendo aptos)
rm, sudo y otros comandos destructivos o que elevan privilegios
kubectl delete y operaciones destructivas de CLI en la nube (aws, gcloud, az, terraform, …)
Cualquier acción que lea o escriba archivos dotenv, material de claves, la configuración de Git o la propia configuración del agente

Smart se diferencia de los modos adyacentes en lo que delega:

	Aceptar ediciones	Smart	Omitir
Ediciones de archivos del workspace	Automático	Automático	Automático
Comandos de shell y solicitudes de red	Solicitar siempre	Automático solo cuando el modelo los considera seguros	Siempre automático
Comandos de alto riesgo (instalaciones, `rm`, `sudo`, operaciones de `git` que modifican contenido)	Solicitar siempre	Solicitar siempre	Siempre automático

Tus propias Rules siguen teniendo prioridad. El criterio de Smart solo se aplica cuando ninguna Rule determina ya la acción, por lo que una Rule deny bloquea la acción y una Rule ask siempre solicita confirmación, exactamente como se describe en Cómo funcionan los permisos. Las Rules deny y ask de nivel de organización tampoco se ven afectadas.

El modo Smart se está implementando gradualmente, por lo que es posible que todavía no aparezca en tu selector de modo ni al alternar con Shift+Tab.

Modo autónomo

autónomo es el modo de permisos que se combina con la marca --sandbox. Conceptualmente, equivale más o menos a “Aceptar ediciones en el workspace actual” más la capacidad de ejecutar cualquier comando de shell, con ambos comportamientos contenidos por el sandbox a nivel del sistema operativo. Cuando el sandbox está activo:

Es el único modo de permisos disponible. Normal, Aceptar ediciones, Smart y Omitir se ocultan en las sesiones con sandbox. El modo Plan sigue estando disponible.
Los comandos de shell y las solicitudes de red se aprueban automáticamente en lugar de pedir confirmación, porque el sandbox impone lo que pueden leer, escribir y alcanzar a través de la red.
Las ediciones directas de archivos mediante las herramientas edit y write siguen pidiendo confirmación. Estas herramientas se ejecutan dentro del proceso de la CLI, en lugar de hacerlo dentro del sandbox, por lo que no pueden quedar restringidas por él. Conceder un ámbito Write(...) en el prompt amplía dinámicamente el sandbox para que los comandos de shell posteriores puedan escribir allí.
Los ámbitos Write(...) concedidos a mitad de la sesión amplían dinámicamente el sandbox para los comandos posteriores. Las aprobaciones de Read(...) a mitad de la sesión solo afectan a las propias herramientas del agente; las rutas ocultas por las Rules de denegación Read(...) permanecen ocultas durante toda la sesión.

devin --sandbox --permission-mode autonomous

Usa Omitir cuando quieras una ejecución sin restricciones y sin aislamiento a nivel del sistema operativo; usa --sandbox (que selecciona autónomo) cuando quieras una ejecución desatendida con límites aplicados por el sistema operativo al acceso al sistema de archivos y a la red. Consulta la referencia de configuración de sandbox para obtener más información sobre las raíces con permisos de escritura, las Rules de denegación y el filtrado de dominios, y Team Settings → Aplicación de Sandbox para los controles de Enterprise.

Cómo funcionan los permisos

Cuando el agente usa una herramienta, el sistema de permisos comprueba tus reglas en orden de prioridad:

Reglas de denegación — Se comprueban primero. Si coinciden, la acción se bloquea de inmediato.
Reglas de solicitud — Se comprueban en segundo lugar. Si coinciden, siempre se te pedirá confirmación (tienen prioridad sobre cualquier regla de autorización).
Reglas de autorización — Se comprueban al final. Si coinciden, la acción continúa sin pedir confirmación.
Predeterminado — Si no coincide ninguna regla, se te pedirá aprobación.

Como la denegación se comprueba antes que la solicitud, y la solicitud se comprueba antes que la autorización, una regla de denegación siempre prevalece. Si el mismo ámbito coincide tanto con una regla de denegación como con una de solicitud, se aplica la denegación.

Configuración

Agrega permisos a la sección permissions de tu archivo de configuración:

En Windows, la ruta del archivo de configuración del usuario es %APPDATA%\devin\config.json (normalmente C:\Users\<you>\AppData\Roaming\devin\config.json) en lugar de ~/.config/devin/config.json. Consulta Archivo de configuración para obtener más detalles.

Configuración del proyecto
Configuración del usuario
Anulación local

// .devin/config.json
{
  "permissions": {
    "allow": [
      "Read(src/**)",
      "Exec(npm run)"
    ],
    "deny": [
      "Exec(rm)"
    ]
  }
}

// ~/.config/devin/config.json
{
  "permissions": {
    "allow": [
      "Read(**)",
      "Exec(git)"
    ]
  }
}

// .devin/config.local.json
{
  "permissions": {
    "allow": [
      "Exec(docker compose)"
    ]
  }
}

Sintaxis de permisos

Hay dos tipos de criterios de coincidencia de permisos: basados en ámbitos (controlan a qué rutas/comandos/URL se puede acceder) y basados en herramientas (controlan qué herramientas se pueden usar).

Permisos basados en el ámbito

Read(glob)

Controla el acceso de lectura a archivos. El patrón glob coincide con rutas de archivo.

"allow": [
  "Read(src/**)",           // Todos los archivos de src/
  "Read(~/.config/**)",     // Archivos de configuración del directorio personal
  "Read(/tmp/**)"           // Directorio temporal
]

Las rutas de directorio incluyen automáticamente todos los archivos que contienen.

Write(glob)

Controla el acceso de escritura y edición de archivos.

"allow": [
  "Write(src/**)",          // Puede escribir en cualquier parte de src/
  "Write(tests/**)"         // Puede escribir archivos de prueba
],
"deny": [
  "Write(*.lock)",          // No puede modificar archivos .lock
  "Write(.env*)"            // No puede modificar archivos .env
]

Exec(prefix)

Controla la ejecución de comandos de shell. Coincide con los comandos que empiezan por el prefijo indicado.

"allow": [
  "Exec(git)",              // git, git status, git commit...
  "Exec(npm run)",          // npm run test, npm run build...
  "Exec(python)"            // python, python script.py...
],
"deny": [
  "Exec(rm)",               // Bloquea rm, rm -rf, etc.
  "Exec(sudo)"              // Bloquea comandos sudo
]

Exec(git) coincide con “git”, “git status” y “git commit -m ‘msg’”, pero NO con “gitk” ni “github-cli”. El prefijo debe coincidir como una palabra completa.

Fetch(pattern)

Controla el acceso HTTP mediante patrones de URL.

"allow": [
  "Fetch(https://api.github.com/*)",    // API de GitHub
  "Fetch(https://*.example.com/*)",     // Todos los subdominios de example.com
  "Fetch(domain:npmjs.org)"             // Cualquier URL de npmjs.org
]

Los patrones de URL siguen el estándar WHATWG URL Pattern. La abreviatura domain: coincide con cualquier ruta del dominio exacto.

Permisos por herramienta

Haz coincidir el nombre de la herramienta para controlar herramientas completas:

{
  "permissions": {
    "deny": [
      "edit",       // Bloquear todas las ediciones de archivos
      "exec"        // Bloquear toda ejecución de comandos
    ],
    "allow": [
      "read",       // Permitir todas las lecturas de archivos
      "grep",       // Permitir todas las búsquedas
      "glob"        // Permitir la búsqueda de todos los archivos
    ]
  }
}

Nombres de las herramientas disponibles: read, edit, grep, glob, exec

Permisos de las herramientas del servidor MCP

Controle el acceso a las herramientas del servidor MCP:

{
  "permissions": {
    "allow": [
      "mcp__github__list_issues",     // Herramienta específica en servidor específico
      "mcp__github__*",               // Todas las herramientas en el servidor de github
      "mcp__*"                        // Todas las herramientas MCP
    ],
    "deny": [
      "mcp__github__delete_repo"      // Bloquear herramienta peligrosa específica
    ]
  }
}

Patrón	Coincide con
`mcp__server__tool`	Una herramienta específica
`mcp__server__*`	Todas las herramientas de un servidor
`mcp__*`	Todas las herramientas MCP en todas partes

Patrones de ruta

Los patrones glob en Read() y Write() admiten:

Patrón	Significado
`*`	Cualquier carácter en un solo segmento de ruta
`**`	Cualquier carácter a través de segmentos de ruta (recursivo)
`~`	Expansión del directorio de inicio

Ejemplos:

"allow": [
  "Read(**)",                    // Todos los archivos en cualquier ubicación
  "Read(src/**/*.ts)",           // Todo TypeScript en src/
  "Write(~/projects/myapp/**)"   // Escribir en un proyecto específico
]

Usa un prefijo de ruta absoluta (p. ej., Read(/**)) cuando quieras que coincida con todos los archivos del sistema. Un Read(**) sin una / inicial se resuelve en relación con tu directorio de trabajo actual, por lo que solo coincide con los archivos dentro de ese directorio, no con los archivos a los que se accede mediante rutas absolutas en otras ubicaciones.

Opciones de persistencia

Cuando el agente solicite permiso durante una sesión, puedes elegir cómo guardar tu decisión:

Opción	Dónde se guarda	¿Se comparte con el equipo?
Permitir esta vez	No se guarda	No
Permitir para la sesión	Solo en memoria	No
Permitir para el proyecto	`.devin/config.json`	Sí
Permitir para el proyecto (local)	`.devin/config.local.json`	No
Permitir globalmente	`~/.config/devin/config.json` (`%APPDATA%\devin\config.json` en Windows)	No

Los prompts de Command ofrecen ambos ámbitos explícitamente: “Sí, permitir siempre los comandos <cmd> en <project>” guarda la concesión para el proyecto actual, y “Sí, permitir siempre los comandos <cmd> en todos los proyectos” la guarda en tu configuración de usuario para que se aplique en todas partes. Los prompts de obtención web para una URL o dominio específicos añaden una opción equivalente de “Sí, permitir siempre todas las solicitudes web”, que agrega la obtención a la lista de permitidos en un solo paso.

Editar un Command antes de aprobarlo

Las solicitudes de aprobación de Command no se limitan a sí o no. Además de las opciones de aprobación, una solicitud de Command ofrece:

Opción	Efecto
Editar Command	Abre el Command propuesto para editarlo en línea y ajustarlo antes de ejecutarlo
Describir el cambio en el Command	Reescribe el Command a partir de una descripción en lenguaje natural de lo que desea que haga, para revisarlo antes de ejecutarlo

Permisos a nivel del servidor MCP

Cuando se solicita una herramienta específica de MCP (p. ej., list_issues en el servidor de Figma), la solicitud de permisos también ofrece opciones más amplias a nivel del servidor:

Opción	Efecto
Permitir esta herramienta (esta sesión)	Otorga acceso a la herramienta específica durante la sesión actual
Permitir siempre esta herramienta	Guarda en la configuración el permiso para esa herramienta específica
Permitir todas las herramientas de este servidor (esta sesión)	Otorga acceso a todas las herramientas del servidor durante la sesión
Permitir siempre las herramientas de este servidor	Guarda en la configuración el acceso a todas las herramientas del servidor

Esto te permite otorgar rápidamente acceso general a un servidor MCP de confianza sin tener que aprobar cada herramienta por separado.

Precedencia

Cuando varias fuentes de permisos definen reglas, se combinan con esta precedencia (de mayor a menor):

Configuración de la organización o del equipo (si es Enterprise)
Permisos a nivel de sesión (aprobaciones interactivas)
Configuración local del proyecto (.devin/config.local.json)
Configuración del proyecto (.devin/config.json)
Configuración del usuario (~/.config/devin/config.json; %APPDATA%\devin\config.json en Windows)

Las denegaciones definidas a nivel de organización no pueden ser anuladas por la configuración del proyecto ni por la del usuario. Esto garantiza que se apliquen las políticas de Enterprise.

Ejemplos

Configuración mínima para desarrollo

Permite las operaciones habituales de solo lectura y solicita confirmación para todo lo demás:

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Exec(git status)",
      "Exec(git diff)",
      "Exec(git log)"
    ]
  }
}

Confianza total para un proyecto

Aprobar automáticamente la mayoría de las operaciones del proyecto:

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Write(src/**)",
      "Write(tests/**)",
      "Exec(npm)",
      "Exec(git)",
      "Exec(node)"
    ],
    "deny": [
      "Exec(rm -rf)",
      "Exec(sudo)",
      "Write(.env*)"
    ]
  }
}

Enterprise con restricciones estrictas

Restringe las operaciones a operaciones seguras específicas y solicita siempre confirmación para las operaciones de escritura:

{
  "permissions": {
    "allow": [
      "Read(src/**)",
      "Exec(git status)",
      "Exec(git diff)",
      "Exec(npm run lint)"
    ],
    "deny": [
      "Exec(rm)",
      "Exec(sudo)",
      "Write(.env*)"
    ],
    "ask": [
      "Write(**)",
      "exec"
    ]
  }
}

En este ejemplo, los intentos de escribir en .env* se deniegan de inmediato, todas las demás escrituras siempre solicitan confirmación al usuario y solo unos pocos comandos de solo lectura se aprueban automáticamente. Como deny se comprueba antes que ask, la denegación de .env* tiene prioridad sobre la regla Write(**) de solicitud.

Primeros pasos

Integraciones del Editor

Extensibilidad

Enterprise

Referencia

Registro de cambios

Comportamiento predeterminado de los permisos

Modo Smart

Modo autónomo

Cómo funcionan los permisos

Configuración

Sintaxis de permisos

Permisos basados en el ámbito

Permisos por herramienta

Permisos de las herramientas del servidor MCP

Patrones de ruta

Opciones de persistencia

Editar un Command antes de aprobarlo

Permisos a nivel del servidor MCP

Precedencia

Ejemplos

Configuración mínima para desarrollo

Confianza total para un proyecto

Enterprise con restricciones estrictas

​Comportamiento predeterminado de los permisos

​Modo Smart

​Modo autónomo

​Cómo funcionan los permisos

​Configuración

​Sintaxis de permisos

​Permisos basados en el ámbito

​Permisos por herramienta

​Permisos de las herramientas del servidor MCP

​Patrones de ruta

​Opciones de persistencia

​Editar un Command antes de aprobarlo

​Permisos a nivel del servidor MCP

​Precedencia

​Ejemplos

​Configuración mínima para desarrollo

​Confianza total para un proyecto

​Enterprise con restricciones estrictas

Comportamiento predeterminado de los permisos

Modo Smart

Modo autónomo

Cómo funcionan los permisos

Configuración

Sintaxis de permisos

Permisos basados en el ámbito

Permisos por herramienta

Permisos de las herramientas del servidor MCP

Patrones de ruta

Opciones de persistencia

Editar un Command antes de aprobarlo

Permisos a nivel del servidor MCP

Precedencia

Ejemplos

Configuración mínima para desarrollo

Confianza total para un proyecto

Enterprise con restricciones estrictas