Saltar al contenido principal

Documentation Index

Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt

Use this file to discover all available pages before exploring further.

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:
Tipo de herramientaEjemploNormalAceptar edicionesOmitirAutónomo (sandbox)
Solo lecturaLecturas de archivos, grep, globNoNoNoNo
FetchSolicitudes HTTPNoNo
Comandos de BashEjecución del shellNoNo
Ediciones de archivos mediante edit/writeEditar/escribir archivosNo (en el workspace)No
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 de confirmación 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:
  1. Reglas de denegación — Se comprueban primero. Si coinciden, la acción se bloquea de inmediato.
  2. Reglas de solicitud — Se comprueban en segundo lugar. Si coinciden, siempre se te pedirá confirmación (tienen prioridad sobre cualquier regla de autorización).
  3. Reglas de autorización — Se comprueban al final. Si coinciden, la acción continúa sin pedir confirmación.
  4. 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.
// .devin/config.json
{
  "permissions": {
    "allow": [
      "Read(src/**)",
      "Exec(npm run)"
    ],
    "deny": [
      "Exec(rm)"
    ]
  }
}

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.
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
]
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.
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ónCoincide con
mcp__server__toolUna 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ónSignificado
*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ónDónde se guarda¿Se comparte con el equipo?
Permitir esta vezNo se guardaNo
Permitir para la sesiónSolo en memoriaNo
Permitir para el proyecto.devin/config.json
Permitir para el proyecto (local).devin/config.local.jsonNo
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ónEfecto
Permitir esta herramienta (esta sesión)Otorga acceso a la herramienta específica durante la sesión actual
Permitir siempre esta herramientaGuarda 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 servidorGuarda 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):
  1. Configuración de la organización o del equipo (si es Enterprise)
  2. Permisos a nivel de sesión (aprobaciones interactivas)
  3. Configuración local del proyecto (.devin/config.local.json)
  4. Configuración del proyecto (.devin/config.json)
  5. 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.