Локальная песочница GitHub Copilot App: настройка и проверка

Вы включили песочницу, но действующий сеанс продолжает работать со старыми правами — или агент снова и снова просит доступ для установки зависимостей, локального сервера и push ветки. Обычно проблема не в одном переключателе, а в сочетании проектного значения, переопределения текущего сеанса и трех отдельных границ: файлов, сети и учетных данных.

После этого руководства вы сможете выбрать стартовую политику для локального репозитория или worktree, применить изменения к нужному сеансу и проверить ограничения на фиктивных данных. Короткий маршрут: подтвердить тип сеанса → включить Sandbox new sessions → сузить три группы прав → создать или перезапустить сеанс → выполнить безопасные проверки.

GitHub объявил эту функцию 23 сентября 2026 года; она остается в публичном превью, поэтому интерфейс и поведение могут измениться. Важно помнить три границы: локальная песочница по умолчанию выключена, политика задается для каждого проекта, а при невозможности обеспечить запрошенные ограничения sandboxed shell завершается с ошибкой вместо тихого запуска команды без защиты.

Сначала убедитесь, что политика действует на ваш сеанс

Проектная политика применяется только к локальному сеансу репозитория и локальному worktree. Облачная песочница, удаленный хост и GitHub Copilot CLI используют другие механизмы, поэтому сначала сверьтесь с таблицей.

Тип сеанса	Применяется ли политика	Важная граница
Локальный сеанс репозитория	Да	Использует настройки песочницы выбранного проекта
Локальный сеанс рабочего дерева	Да	Рабочее дерево разделяет ветки и файлы, но не ограничивает доступ команд к другим местам на компьютере; это делает песочница
Облачный sandbox-сеанс	Нет	Использует собственную облачную изоляцию
Сеанс на удаленном хосте	Нет	Локальная политика проекта не переносится на удаленный хост
GitHub Copilot CLI	Настраивается отдельно	Настройки песочницы Copilot app и Copilot CLI не заменяют друг друга

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

Как включить песочницу для новых сеансов

Чтобы следующие локальные сеансы получили проектную политику, включите Sandbox new sessions и создайте новый сеанс; один переключатель не меняет уже запущенный сеанс. Выполните следующие шаги:

1. Откройте настройки GitHub Copilot app.
2. Выберите нужный проект.
3. Найдите раздел Sandbox.
4. Включите Sandbox new sessions.
5. Создайте новый локальный сеанс.

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

Чтобы сохранить историю текущего диалога и заново загрузить политику, введите /restart-session.

Для большинства проектов GitHub рекомендует начать со стандартной политики. Она рассчитана на обычные задачи: установку зависимостей, подключение к локальному серверу разработки, отправку ветки и создание pull request. Ограничения стоит усиливать, если рядом с проектом находятся чувствительные каталоги, сеть не нужна или агент не должен использовать ваши учетные данные.

Как отдельно ограничить файлы, сеть и учетные данные

Это три независимые границы: запрет файлов не отключает учетные данные, а отключение учетных данных не защищает чувствительный каталог, который остается доступен для чтения. Сужайте каждую область по задаче, а не выключайте все сразу.

1. Файловая система: что можно читать и изменять

Начните с минимального файлового доступа: оставьте чтение и запись в workspace, а другие пути добавляйте только при реальной необходимости задачи. По умолчанию sandbox-сеанс может читать и изменять workspace и текущий рабочий каталог; настройки проекта добавляют три списка:

• Additional read/write — дополнительные каталоги, которые инструменты агента могут читать и изменять.
• Additional read-only — дополнительные каталоги, которые можно читать, но нельзя изменять.
• Denied — каталоги, доступ к которым полностью запрещен.

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

На Windows действует важная граница. Запрещенный путь можно сохранить в настройках, но если активные возможности Windows sandbox не могут гарантировать запрет, команда завершается сообщением класса unsupported-policy. Она не продолжает работу с доступом к пути и не отключает песочницу автоматически.

2. Сеть: интернет и локальная сеть управляются отдельно

Если задаче нужны установка зависимостей или локальный сервер разработки, не отключайте оба сетевых направления автоматически; отдельно решите, нужны ли внешний интернет и локальная сеть. По умолчанию sandbox-сеанс может обращаться к обоим, и вы можете управлять:

• Outbound internet — доступ к GitHub, реестрам пакетов и другим интернет-сервисам.
• Local network — loopback и локальные сетевые соединения, включая локальные серверы разработки.

Сетевые ограничения могут нарушить установку пакетов, API-вызовы, preview-серверы и другие инструменты, которым нужна связь. Отключение сети — это компромисс задачи, а не бесплатный защитный переключатель.

На Linux есть отдельное ограничение: песочница не может независимо управлять доступом к локальной сети для порожденных процессов, например shell-команд, локальных MCP- или LSP-серверов. Настройка все же действует на внутрипроцессные операции, включая веб-запросы и удаленные MCP-подключения. Поэтому на Linux проверяйте и внутрипроцессный, и дочерний путь, а не делайте вывод по одному тесту.

3. Учетные данные: Git и GitHub CLI настраиваются отдельно

Для чтения кода или офлайн-анализа сначала отключите учетные данные Git и GitHub CLI; включайте их только для push ветки или создания pull request. По умолчанию аутентифицированные операции доступны внутри песочницы, и можно отключить:

• Git credentials — учетные данные для аутентифицированных HTTPS-операций Git.
• GitHub CLI credentials — учетные данные, которыми аутентифицируется GitHub CLI.

После отключения push ветки или создание pull request могут перестать работать внутри песочницы. Политика файлов и политика учетных данных — разные границы: даже при отключенных credentials защищайте каталог с ключами, конфигурацией и другими секретами файловыми правилами.

Когда менять проект, текущий сеанс или одну операцию

Меняйте настройки проекта, если правило должны наследовать будущие сеансы; используйте /sandbox on или /sandbox off только для текущего сеанса; после изменения проекта примените /restart-session, если активный сеанс должен перечитать политику.

Действие	Когда применяется	Влияние на другие сеансы
Изменить настройки проекта Sandbox	В новом или перезапущенном сеансе	Меняет значение по умолчанию для последующих сеансов проекта
Ввести /sandbox on в активном локальном сеансе	Сразу; создается устойчивое переопределение для этого сеанса	Не меняет проектное значение для других сеансов
Ввести /sandbox off в активном локальном сеансе	Сразу отключает песочницу для текущего сеанса	Другие сеансы не меняются; команды получают такой же доступ к файлам, сети и учетным данным, как учетная запись пользователя
Ввести /sandbox on или /sandbox off до запуска сеанса	Меняет проектное значение, наследуемое новыми сеансами	Влияет на сеансы, которые позднее стартуют с этим значением
Ввести /restart-session	Перезапускает текущий сеанс, сохраняет историю и перечитывает политику	Само по себе не редактирует проектные настройки

Если инструменту нужен доступ за пределами политики, приложение может показать Run outside the sandbox?. В зависимости от итоговой политики можно отменить операцию, один раз выполнить ее вне песочницы либо отключить песочницу до конца текущего сеанса. Владелец предприятия может запретить запуск инструментов вне песочницы.

Отключение через это окно не переписывает проектное значение и существующее переопределение сеанса. Временное состояние заканчивается после перезапуска или повторного подключения сеанса. Когда отображается Sandbox off for this session, песочницу можно вернуть через Re-enable sandbox.

Безопасный порядок решений: сначала отменить операцию и понять, зачем команде дополнительный доступ. Если он нужен постоянно, точечно изменить политику проекта и перезапустить сеанс. Одноразовый запуск вне песочницы стоит выбирать только после проверки команды, аргументов и возможных последствий. Для незнакомого репозитория или команды, динамически собранной из Prompt, не отключайте песочницу на весь сеанс только ради удобства.

Если хост не может обеспечить политику, команда останавливается

Если операционная система не способна обеспечить правило, безопасный результат — ошибка команды, а не автоматический переход к выполнению без песочницы.

GitHub Copilot app принимает настройки раньше, чем узнает, способен ли хост выполнить все требования. Проверка поддержки происходит при запуске первого sandboxed shell.

Если запрошенную политику невозможно обеспечить:

• Shell сообщает unsupported-platform или unsupported-policy.
• Команда не продолжает выполнение без песочницы.
• Если приложение показывает Sandbox unavailable, устраните указанную проблему и выберите Retry sandbox.

Это поведение fail-closed, а не попытка выполнить команду любой ценой. Успешное сохранение настроек еще не доказывает, что политика работает на текущем компьютере. Запустите хотя бы один sandboxed shell, убедитесь, что нет сообщения о неподдерживаемой конфигурации, и проведите минимальную проверку.

Как проверить политику на фиктивных данных

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

Создайте вне workspace одноразовые тестовые каталоги и положите туда только фиктивные файлы. Не используйте настоящие SSH-ключи, облачные credentials или производственную конфигурацию.

Проверка	Безопасная процедура	Ожидаемое поведение политики
Наследование новым сеансом	Включите Sandbox new sessions и создайте новый локальный сеанс	Новый сеанс использует проектную политику; старый не меняется автоматически
Применение изменения	Измените одно правило и введите /restart-session	Сеанс перезапускается, сохраняет историю и перечитывает политику
Каталог только для чтения	Добавьте одноразовый каталог в Additional read-only, прочитайте фиктивный файл и попробуйте создать тестовый	Чтение должно работать, запись должна блокироваться
Запрещенный каталог	Добавьте другой одноразовый каталог в Denied, затем попробуйте вывести список или прочитать фиктивный файл	Доступ должен блокироваться, даже если более широкий родительский путь разрешен
Интернет	Отключите Outbound internet и выполните безвредную проверку соединения	Внешнее соединение должно завершиться неудачей; включите доступ и сравните
Локальная сеть	Отключите Local network и подключитесь к одноразовому локальному сервису	Доступ должен соответствовать возможностям платформы; на Linux учитывайте ограничение для порожденных процессов
Git credentials	Отключите Git credentials и выполните немодифицирующую проверку аутентификации в тестовом репозитории	Аутентифицированные HTTPS-операции Git могут стать недоступны
GitHub CLI credentials	Отключите GitHub CLI credentials и выполните немодифицирующую проверку, например gh auth status	GitHub CLI не должен получать прежнюю возможность аутентификации; точное сообщение зависит от среды
Fail-closed	Если появился unsupported-platform или unsupported-policy, проверьте, что целевой фиктивный файл не создан	Команда не должна продолжиться без песочницы или дать ожидаемый побочный эффект

После проверки удалите тестовые каталоги и верните только минимальные разрешения, которые действительно нужны проекту. Не проверяйте запрет попыткой открыть настоящий чувствительный каталог.

Какой начальный профиль выбрать для вашей задачи

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

Обычная разработка

Включите песочницу, оставьте стандартные сетевые и credential-возможности, разрешите только необходимые внешние каталоги и явно запретите соседние чувствительные пути. Такой вариант подходит для установки зависимостей, локальных сервисов, push веток и pull request.

Проверка незнакомого репозитория

Оставьте чтение и запись только в workspace, дополнительные материалы подключайте как read-only, по умолчанию отключите Git и GitHub CLI credentials, а интернет не включайте, пока не понятны источники зависимостей. При временной необходимости открывайте одну конкретную возможность вместо немедленного /sandbox off.

Локальный офлайн-анализ

Отключите интернет и ненужные учетные данные, сохранив только необходимый файловый доступ. Если важно ограничить и локальную сеть, отдельно проверьте порожденные процессы на Linux: один переключатель интерфейса не гарантирует идентичное управление каждым процессом.

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

Ошибки, из-за которых политика не работает или становится слишком широкой

Чаще всего сохранение настроек принимают за доказательство работы политики или отключают всю песочницу после первого отказа. Семь пунктов ниже искажают проверку либо дают задаче лишние права.

1. Считать рабочее дерево границей безопасности. Оно разделяет ветки и файлы, но не ограничивает доступ команд к другим местам компьютера.
2. Изменить политику и продолжить проверку в старом сеансе. Изменения не применяются задним числом; создайте новый сеанс или используйте /restart-session.
3. Предполагать, что app и CLI используют одну песочницу. Они настраиваются раздельно.
4. Считать успешное сохранение доказательством поддержки хоста. Проверка происходит только при первом запуске sandboxed shell.
5. Недооценивать /sandbox off. После него команды агента получают область доступа вашей учетной записи пользователя.
6. Ожидать одинакового сетевого поведения на всех платформах. Для Linux документировано ограничение локальной сети у порожденных процессов.
7. Использовать широкий обход при любом отказе в доступе. Обычно безопаснее подтвердить необходимость, минимально изменить политику и перезапустить сеанс.

Что делать дальше

Сначала убедитесь, что работаете в локальном сеансе репозитория или worktree, затем включите Sandbox new sessions. Для обычной разработки начните со стандартной политики и оставьте только нужные каталоги, сеть и учетные данные; для незнакомого кода или офлайн-анализа выберите более строгий профиль и открывайте по одной возможности.

После изменения проектной политики создайте новый сеанс или выполните /restart-session, затем проверьте read-only, denied, сеть и учетные данные на одноразовых объектах. Если появляются unsupported-platform, unsupported-policy или Sandbox unavailable, устраните проблему совместимости и не подменяйте проверку запуском через /sandbox off.

Официальные источники

По этим страницам GitHub можно сверить актуальный интерфейс, область действия и поведение при ошибке до и после настройки.

• Configuring local sandboxing in the GitHub Copilot app
• Local sandboxing in the GitHub Copilot app — GitHub Changelog, September 23, 2026