> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Permisos

> Controla lo que el agente puede hacer con reglas de permisos granulares

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.

***

<div id="default-permission-behavior">
  ## Comportamiento predeterminado de los permisos
</div>

Devin CLI usa un sistema de permisos por niveles para equilibrar capacidad y seguridad. El comportamiento predeterminado depende del [modo](/es/cli/essential-commands#modes) 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](#autonomous-mode) está activo.

<Warning>
  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](/es/cli/enterprise/team-settings) permanecen activas independientemente del modo de permisos del usuario. Consulta [Precedencia](#precedence) para obtener más información.
</Warning>

<div id="autonomous-mode">
  ### Modo autónomo
</div>

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.

```bash theme={null}
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](/es/cli/reference/configuration/config-file#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](/es/cli/enterprise/team-settings#sandbox-enforcement) para los controles de Enterprise.

***

<div id="how-permissions-work">
  ## Cómo funcionan los permisos
</div>

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.

<Note>
  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.
</Note>

***

<div id="configuration">
  ## Configuración
</div>

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

<Note>
  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](/es/cli/reference/configuration/config-file#file-locations) para obtener más detalles.
</Note>

<Tabs>
  <Tab title="Configuración del proyecto">
    ```json theme={null}
    // .devin/config.json
    {
      "permissions": {
        "allow": [
          "Read(src/**)",
          "Exec(npm run)"
        ],
        "deny": [
          "Exec(rm)"
        ]
      }
    }
    ```
  </Tab>

  <Tab title="Configuración del usuario">
    ```json theme={null}
    // ~/.config/devin/config.json
    {
      "permissions": {
        "allow": [
          "Read(**)",
          "Exec(git)"
        ]
      }
    }
    ```
  </Tab>

  <Tab title="Anulación local">
    ```json theme={null}
    // .devin/config.local.json
    {
      "permissions": {
        "allow": [
          "Exec(docker compose)"
        ]
      }
    }
    ```
  </Tab>
</Tabs>

***

<div id="permission-syntax">
  ## Sintaxis de permisos
</div>

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).

<div id="scope-based-permissions">
  ### Permisos basados en el ámbito
</div>

<AccordionGroup>
  <Accordion title="Read(glob)" icon="eye" defaultOpen>
    Controla el acceso de lectura a archivos. El patrón glob coincide con rutas de archivo.

    ```json theme={null}
    "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.
  </Accordion>

  <Accordion title="Write(glob)" icon="pen">
    Controla el acceso de escritura y edición de archivos.

    ```json theme={null}
    "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
    ]
    ```
  </Accordion>

  <Accordion title="Exec(prefix)" icon="terminal">
    Controla la ejecución de comandos de shell. Coincide con los comandos que empiezan por el prefijo indicado.

    ```json theme={null}
    "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
    ]
    ```

    <Note>
      `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.
    </Note>
  </Accordion>

  <Accordion title="Fetch(pattern)" icon="globe">
    Controla el acceso HTTP mediante patrones de URL.

    ```json theme={null}
    "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](https://urlpattern.spec.whatwg.org/). La abreviatura `domain:` coincide con cualquier ruta del dominio exacto.
  </Accordion>
</AccordionGroup>

<div id="tool-based-permissions">
  ### Permisos por herramienta
</div>

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

```json theme={null}
{
  "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`

<div id="mcp-tool-permissions">
  ### Permisos de las herramientas del servidor MCP
</div>

Controle el acceso a las herramientas del servidor MCP:

```json theme={null}
{
  "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 |

***

<div id="path-patterns">
  ## Patrones de ruta
</div>

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:**

```json theme={null}
"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
]
```

<Note>
  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.
</Note>

***

<div id="persistence-options">
  ## Opciones de persistencia
</div>

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                          |

<div id="mcp-server-level-grants">
  ### Permisos a nivel del servidor MCP
</div>

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.

***

<div id="precedence">
  ## Precedencia
</div>

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)

<Warning>
  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.
</Warning>

***

<div id="examples">
  ## Ejemplos
</div>

<div id="minimal-development-setup">
  ### Configuración mínima para desarrollo
</div>

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

```json theme={null}
{
  "permissions": {
    "allow": [
      "Read(**)",
      "Exec(git status)",
      "Exec(git diff)",
      "Exec(git log)"
    ]
  }
}
```

<div id="full-trust-for-a-project">
  ### Confianza total para un proyecto
</div>

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

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

<div id="locked-down-enterprise">
  ### Enterprise con restricciones estrictas
</div>

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

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

<Tip>
  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.
</Tip>