Permisos - Devin Docs

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	Omitir	Autónomo (sandbox)
Solo lectura	Lecturas de archivos, grep, glob	Auto	Auto	Auto	Auto
Fetch	Solicitudes HTTP	Solicitar confirmación	Solicitar confirmación	Auto	Auto
Comandos de Bash	Ejecución del shell	Solicitar confirmación	Solicitar confirmación	Auto	Auto
Ediciones de archivos mediante `edit`/`write`	Editar/escribir archivos	Solicitar confirmación	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 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 Omitir y Autónomo no anulan los permisos a nivel de organización. Las reglas 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 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 y Omitir se ocultan en las sesiones con sandbox. El modo Plan sigue estando disponible.
Los comandos de shell y las operaciones de fetch 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 concedidos a mitad de la sesión amplían dinámicamente el sandbox para los comandos posteriores.

devin --sandbox --permission-mode autonomous

Usa Bypass cuando quieras una ejecución sin restricciones y sin aislamiento a nivel del sistema operativo; usa --sandbox (que selecciona Autonomous) 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 lectura/escritura 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

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.

​Comportamiento predeterminado de los permisos

​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

​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 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

Permisos a nivel del servidor MCP

Precedencia

Ejemplos

Configuración mínima para desarrollo

Confianza total para un proyecto

Enterprise con restricciones estrictas