Permisos

Dropstone utiliza la configuración permission para decidir si una acción determinada debe ejecutarse automáticamente, solicitar tu aprobación o bloquearse.

La configuración heredada tools (booleana) está obsoleta; se ha fusionado en permission. La configuración antigua tools sigue siendo compatible para mantener la retrocompatibilidad.

Acciones

Cada regla de permiso se resuelve en una de las siguientes opciones:

• "allow": ejecutar sin aprobación
• "ask": solicitar aprobación
• "deny": bloquear la acción

Configuración

Puedes establecer permisos globalmente (con *) y anular herramientas específicas.

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": {
    "*": "ask",
    "bash": "allow",
    "edit": "deny"
  }
}

También puedes establecer todos los permisos de una vez:

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": "allow"
}

Reglas Granulares (Sintaxis de Objeto)

Para la mayoría de los permisos, puedes usar un objeto para aplicar diferentes acciones según la entrada de la herramienta.

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": {
    "bash": {
      "*": "ask",
      "git *": "allow",
      "npm *": "allow",
      "rm *": "deny",
      "grep *": "allow"
    },
    "edit": {
      "*": "deny",
      "packages/web/src/content/docs/*.mdx": "allow"
    }
  }
}

Las reglas se evalúan mediante coincidencia de patrones, ganando la última regla que coincida. Un patrón común es poner la regla comodín "*" primero y las reglas más específicas después.

Comodines

Los patrones de permisos utilizan coincidencia simple con comodines:

• * coincide con cero o más caracteres cualesquiera
• ? coincide exactamente con un carácter
• Todos los demás caracteres coinciden literalmente

Expansión del Directorio Personal

Puedes usar ~ o $HOME al inicio de un patrón para hacer referencia a tu directorio personal. Esto es particularmente útil para reglas de external_directory.

• ~/projects/* -> /Users/username/projects/*
• $HOME/projects/* -> /Users/username/projects/*
• ~ -> /Users/username

Directorios Externos

Usa external_directory para permitir llamadas a herramientas que toquen rutas fuera del directorio de trabajo donde se inició Dropstone. Esto aplica a cualquier herramienta que acepte una ruta como entrada (por ejemplo, read, edit, glob, grep y muchos comandos bash).

La expansión del directorio personal (como ~/...) solo afecta cómo se escribe un patrón. No convierte una ruta externa en parte del espacio de trabajo actual, por lo que las rutas fuera del directorio de trabajo deben permitirse igualmente mediante external_directory.

Por ejemplo, esto permite el acceso a todo lo que está bajo ~/projects/personal/:

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": {
    "external_directory": {
      "~/projects/personal/**": "allow"
    }
  }
}

Cualquier directorio permitido aquí hereda los mismos valores predeterminados que el espacio de trabajo actual. Dado que read tiene como valor predeterminado allow, las lecturas también están permitidas para las entradas bajo external_directory a menos que se anulen. Añade reglas explícitas cuando una herramienta deba restringirse en estas rutas, como bloquear ediciones mientras se mantienen las lecturas:

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": {
    "external_directory": {
      "~/projects/personal/**": "allow"
    },
    "edit": {
      "~/projects/personal/**": "deny"
    }
  }
}

Mantén la lista centrada en rutas de confianza y añade capas de reglas de permiso o denegación adicionales según sea necesario para otras herramientas (por ejemplo, bash).

Permisos Disponibles

Los permisos de Dropstone se organizan por nombre de herramienta, además de algunos mecanismos de seguridad adicionales:

• read: lectura de un archivo (coincide con la ruta del archivo)
• edit: todas las modificaciones de archivos (cubre edit, write, patch)
• glob: búsqueda de archivos con comodines (coincide con el patrón glob)
• grep: búsqueda de contenido (coincide con el patrón de expresión regular)
• bash: ejecución de comandos de shell (coincide con comandos analizados como git status --porcelain)
• task: lanzamiento de subagentes (coincide con el tipo de subagente)
• skill: carga de una habilidad (coincide con el nombre de la habilidad)
• lsp: ejecución de consultas LSP (actualmente no granular)
• question: hacer preguntas al usuario durante la ejecución
• webfetch: obtención de una URL (coincide con la URL)
• websearch: búsqueda web (coincide con la consulta)
• external_directory: se activa cuando una herramienta toca rutas fuera del directorio de trabajo del proyecto
• doom_loop: se activa cuando la misma llamada a una herramienta se repite 3 veces con entrada idéntica

Valores Predeterminados

Si no especificas nada, el agente build predeterminado pregunta antes de todo. La aprobación es el valor predeterminado, no una excepción:

{
  "permission": {
    "*": "ask",
    "read": {
      "*": "ask",
      "*.env": "ask",
      "*.env.*": "ask",
      "*.env.example": "ask"
    },
    "external_directory": { "*": "ask" },
    "question": "deny",
    "plan_enter": "deny",
    "plan_exit": "deny",
    "mode_switch": "deny"
  }
}

Los directorios que ya has aprobado se añaden a external_directory como "allow" durante el resto de la sesión.

Tu configuración se fusiona por encima de estos valores predeterminados, y tus reglas tienen prioridad. No los reemplaza: establecer edit en "allow" deja read en "ask", así que nombra cada permiso que pretendas cambiar.

El agente accept all comienza con "*": "allow" en su lugar, con external_directory completamente permitido. Las lecturas de .env y .env.* siguen preguntando, con el razonamiento de que aprobar automáticamente una ejecución no es lo mismo que consentir la entrega de secretos.

Modo sin interfaz y modo servidor

De forma interactiva, "ask" es inofensivo: se te solicita y apruebas. Bajo dropstone serve, en CI, o en cualquier otro lugar sin una persona frente al teclado, no hay nadie a quien preguntar, por lo que la llamada se queda en "status": "running" y la solicitud se cuelga en lugar de fallar. No hay tiempo de espera ni error que capturar.

Debido a que el agente build pregunta antes de todo, este es el resultado predeterminado y no un caso límite. Una configuración parcial tampoco te salva: permitir edit deja read en "ask", y la ejecución se cuelga la primera vez que el agente abre un archivo.

Hay dos formas de solucionarlo. O ejecutas el agente accept all, que comienza con "*": "allow":

curl -X POST ".../session/$SID/message" -d '{ "agent": "accept all", ... }'

O te quedas en build y declaras la lista completa de permisos, denegando por defecto para que una herramienta añadida en una versión posterior no pueda empezar silenciosamente a colgar tus ejecuciones:

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": {
    "*": "deny",
    "read": "allow",
    "edit": "allow",
    "glob": "allow",
    "grep": "allow",
    "bash": "allow"
  }
}

Redúcelo a lo que el trabajo realmente necesita. Un agente que solo lee e informa no tiene razón para tener edit o bash.

Ten en cuenta que accept all todavía pregunta antes de leer .env y .env.*. Si una ejecución sin supervisión debe leer uno, permítelo explícitamente y sé deliberado al respecto.

Qué hace "Ask"

Cuando Dropstone solicita aprobación, la interfaz ofrece tres resultados:

• once: aprobar solo esta solicitud
• always: aprobar solicitudes futuras que coincidan con los patrones sugeridos (durante el resto de la sesión actual de Dropstone)
• reject: denegar la solicitud

El conjunto de patrones que always aprobaría lo proporciona la herramienta (por ejemplo, las aprobaciones de bash típicamente permiten un prefijo de comando seguro como git status*).

Agentes

Puedes anular permisos por agente. Los permisos de los agentes se fusionan con la configuración global, y las reglas de los agentes tienen prioridad. Aprende más sobre los permisos de los agentes.

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": {
    "bash": {
      "*": "ask",
      "git *": "allow",
      "git commit *": "deny",
      "git push *": "deny",
      "grep *": "allow"
    }
  },
  "agent": {
    "build": {
      "permission": {
        "bash": {
          "*": "ask",
          "git *": "allow",
          "git commit *": "ask",
          "git push *": "deny",
          "grep *": "allow"
        }
      }
    }
  }
}

También puedes configurar permisos de agentes en Markdown:

---
description: Revisión de código sin ediciones
mode: subagent
permission:
  edit: deny
  bash: ask
  webfetch: deny
---

Solo analiza el código y sugiere cambios.