Разрешения

Dropstone использует конфигурацию permission, чтобы решать, должно ли конкретное действие выполняться автоматически, запрашивать подтверждение или быть заблокированным.

Устаревшая логическая конфигурация tools объявлена устаревшей; она была объединена в permission. Старая конфигурация tools по-прежнему поддерживается для обратной совместимости.

Действия

Каждое правило разрешения приводит к одному из следующих результатов:

• "allow": выполнять без одобрения
• "ask": запрашивать одобрение
• "deny": блокировать действие

Конфигурация

Вы можете задавать разрешения глобально (с помощью *) и переопределять отдельные инструменты.

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

Вы также можете задать все разрешения сразу:

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

Детальные правила (синтаксис объекта)

Для большинства разрешений вы можете использовать объект, чтобы применять разные действия в зависимости от входных данных инструмента.

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

Правила оцениваются по совпадению шаблонов, при этом выигрывает последнее совпавшее правило. Распространённый подход — ставить правило-ловушку "*" первым, а более конкретные правила после него.

Подстановочные знаки

Шаблоны разрешений используют простое сопоставление с подстановочными знаками:

• * соответствует нулю или более любых символов
• ? соответствует ровно одному символу
• Все остальные символы сопоставляются буквально

Разворачивание домашнего каталога

Вы можете использовать ~ или $HOME в начале шаблона, чтобы указать на ваш домашний каталог. Это особенно полезно для правил external_directory.

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

Внешние каталоги

Используйте external_directory, чтобы разрешить вызовы инструментов, которые затрагивают пути за пределами рабочего каталога, где был запущен Dropstone. Это применимо к любому инструменту, который принимает путь на входе (например, read, edit, glob, grep и многие команды bash).

Разворачивание домашнего каталога (например, ~/...) влияет только на то, как записан шаблон. Оно не делает внешний путь частью текущего рабочего пространства, поэтому пути за пределами рабочего каталога всё равно должны быть разрешены через external_directory.

Например, это разрешает доступ ко всему, что находится в ~/projects/personal/:

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

Любой каталог, разрешённый здесь, наследует те же значения по умолчанию, что и текущее рабочее пространство. Поскольку read по умолчанию имеет значение allow, чтение также разрешено для записей в external_directory, если не переопределено. Добавляйте явные правила, когда инструмент должен быть ограничен в этих путях, например, блокируя редактирование, но сохраняя чтение:

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

Держите список сосредоточенным на доверенных путях и добавляйте дополнительные правила разрешения или запрета по мере необходимости для других инструментов (например, bash).

Доступные разрешения

Разрешения Dropstone привязаны к имени инструмента, плюс несколько защитных механизмов:

• read: чтение файла (соответствует пути к файлу)
• edit: все изменения файлов (охватывает edit, write, patch)
• glob: поиск файлов по шаблону (соответствует шаблону glob)
• grep: поиск содержимого (соответствует шаблону regex)
• bash: выполнение команд оболочки (соответствует разобранным командам, таким как git status --porcelain)
• task: запуск субагентов (соответствует типу субагента)
• skill: загрузка навыка (соответствует имени навыка)
• lsp: выполнение LSP-запросов (в настоящее время не детализируется)
• question: задавание вопросов пользователю во время выполнения
• webfetch: получение URL (соответствует URL)
• websearch: веб-поиск (соответствует запросу)
• external_directory: срабатывает, когда инструмент затрагивает пути за пределами рабочего каталога проекта
• doom_loop: срабатывает, когда один и тот же вызов инструмента повторяется 3 раза с одинаковыми входными данными

Значения по умолчанию

Если вы ничего не укажете, агент build по умолчанию спрашивает перед каждым действием. Одобрение — это стандартное поведение, а не исключение:

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

Каталоги, которые вы уже одобрили, добавляются в external_directory как "allow" на остаток сессии.

Ваша конфигурация объединяется поверх этих значений по умолчанию, и ваши правила имеют приоритет. Она не заменяет их: установка edit в "allow" оставляет read на "ask", поэтому укажите каждое разрешение, которое вы намерены изменить.

Агент accept all вместо этого начинает с "*": "allow", при этом external_directory полностью разрешён. Чтение .env и .env.* по-прежнему запрашивает подтверждение, исходя из того, что автоматическое одобрение запуска — это не то же самое, что согласие на передачу секретов.

Безголовый и серверный режимы

В интерактивном режиме "ask" безвреден: вы получаете запрос и одобряете его. В dropstone serve, в CI или в любом другом месте без человека за клавиатурой спрашивать некому, поэтому вызов остаётся в состоянии "status": "running", и запрос зависает вместо того, чтобы завершиться ошибкой. Нет ни тайм-аута, ни ошибки, которую можно перехватить.

Поскольку агент build спрашивает перед каждым действием, это стандартный результат, а не крайний случай. Частичная конфигурация вас тоже не спасёт: разрешение edit оставляет read на "ask", и запуск зависает при первой попытке агента открыть файл.

Два способа это исправить. Либо запустите агента accept all, который начинает с "*": "allow":

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

Либо оставайтесь на build и укажите полный список разрешений, запрещая по умолчанию, чтобы инструмент, добавленный в более позднем релизе, не мог незаметно начать подвешивать ваши запуски:

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

Сузьте его до того, что действительно нужно для задачи. Агенту, который только читает и сообщает, нет причин иметь edit или bash.

Обратите внимание, что accept all по-прежнему спрашивает перед чтением .env и .env.*. Если автоматический запуск должен прочитать один из них, разрешите его явно и подойдите к этому осознанно.

Что делает "Ask"

Когда Dropstone запрашивает одобрение, интерфейс предлагает три варианта:

• once: одобрить только этот запрос
• always: одобрять будущие запросы, соответствующие предложенным шаблонам (на оставшуюся часть текущей сессии Dropstone)
• reject: отклонить запрос

Набор шаблонов, которые одобрил бы always, предоставляется инструментом (например, одобрения bash обычно добавляют в белый список безопасный префикс команды, например git status*).

Агенты

Вы можете переопределять разрешения для каждого агента. Разрешения агента объединяются с глобальной конфигурацией, и правила агента имеют приоритет. Узнайте больше о разрешениях агентов.

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

Вы также можете настроить разрешения агента в Markdown:

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

Only analyze code and suggest changes.