Permissões

O Dropstone usa a configuração permission para decidir se uma determinada ação deve ser executada automaticamente, solicitar sua aprovação ou ser bloqueada.

A configuração legada tools (booleana) está obsoleta; ela foi incorporada à permission. A antiga configuração tools ainda é suportada para compatibilidade reversa.

Ações

Cada regra de permissão é resolvida para uma das seguintes opções:

• "allow": executar sem aprovação
• "ask": solicitar aprovação
• "deny": bloquear a ação

Configuração

Você pode definir permissões globalmente (com *) e sobrescrever ferramentas específicas.

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

Você também pode definir todas as permissões de uma só vez:

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

Regras Granulares (Sintaxe de Objeto)

Para a maioria das permissões, você pode usar um objeto para aplicar diferentes ações com base na entrada da ferramenta.

{
  "$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"
    }
  }
}

As regras são avaliadas por correspondência de padrão, com a última regra correspondente vencendo. Um padrão comum é colocar a regra abrangente "*" primeiro e as regras mais específicas depois dela.

Caracteres Curinga

Os padrões de permissão usam correspondência simples com caracteres curinga:

• * corresponde a zero ou mais de qualquer caractere
• ? corresponde exatamente a um caractere
• Todos os outros caracteres correspondem literalmente

Expansão do Diretório Inicial

Você pode usar ~ ou $HOME no início de um padrão para referenciar seu diretório inicial. Isso é particularmente útil para regras de external_directory.

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

Diretórios Externos

Use external_directory para permitir chamadas de ferramentas que acessam caminhos fora do diretório de trabalho onde o Dropstone foi iniciado. Isso se aplica a qualquer ferramenta que receba um caminho como entrada (por exemplo, read, edit, glob, grep e muitos comandos bash).

A expansão do diretório inicial (como ~/...) afeta apenas como um padrão é escrito. Ela não torna um caminho externo parte do espaço de trabalho atual, portanto, caminhos fora do diretório de trabalho ainda devem ser permitidos via external_directory.

Por exemplo, isso permite acesso a tudo sob ~/projects/personal/:

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

Qualquer diretório permitido aqui herda os mesmos padrões do espaço de trabalho atual. Como read tem como padrão allow, leituras também são permitidas para entradas sob external_directory, a menos que sejam sobrescritas. Adicione regras explícitas quando uma ferramenta deve ser restrita nesses caminhos, como bloquear edições enquanto mantém leituras:

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

Mantenha a lista focada em caminhos confiáveis e adicione camadas de regras extras de permitir ou negar conforme necessário para outras ferramentas (por exemplo, bash).

Permissões Disponíveis

As permissões do Dropstone são chaveadas pelo nome da ferramenta, além de alguns mecanismos de segurança:

• read: leitura de um arquivo (corresponde ao caminho do arquivo)
• edit: todas as modificações de arquivos (cobre edit, write, patch)
• glob: correspondência de arquivos (corresponde ao padrão glob)
• grep: busca de conteúdo (corresponde ao padrão regex)
• bash: execução de comandos shell (corresponde a comandos analisados como git status --porcelain)
• task: lançamento de subagentes (corresponde ao tipo de subagente)
• skill: carregamento de uma skill (corresponde ao nome da skill)
• lsp: execução de consultas LSP (atualmente não granular)
• question: fazer perguntas ao usuário durante a execução
• webfetch: busca de uma URL (corresponde à URL)
• websearch: busca na web (corresponde à consulta)
• external_directory: acionado quando uma ferramenta acessa caminhos fora do diretório de trabalho do projeto
• doom_loop: acionado quando a mesma chamada de ferramenta se repete 3 vezes com entrada idêntica

Padrões

Se você não especificar nada, o Dropstone começa com padrões permissivos:

• A maioria das permissões tem como padrão "allow".
• doom_loop e external_directory têm como padrão "ask".
• read é "allow", mas arquivos .env são negados por padrão:

{
  "permission": {
    "read": {
      "*": "allow",
      "*.env": "deny",
      "*.env.*": "deny",
      "*.env.example": "allow"
    }
  }
}

O que "Ask" faz

Quando o Dropstone solicita aprovação, a interface oferece três resultados:

• once: aprovar apenas esta solicitação
• always: aprovar solicitações futuras que correspondam aos padrões sugeridos (pelo restante da sessão atual do Dropstone)
• reject: negar a solicitação

O conjunto de padrões que always aprovaria é fornecido pela ferramenta (por exemplo, aprovações de bash normalmente incluem na lista de permissões um prefixo de comando seguro como git status*).

Agentes

Você pode sobrescrever permissões por agente. As permissões do agente são mescladas com a configuração global, e as regras do agente têm precedência. Saiba mais sobre permissões de agente.

{
  "$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"
        }
      }
    }
  }
}

Você também pode configurar permissões de agente em Markdown:

---
description: Code review without edits
mode: subagent
permission:
  edit: deny
  bash: ask
  webfetch: deny
---

Only analyze code and suggest changes.