Каталог конфигурации CLI GitHub Copilot

Copilot CLI Хранит свою конфигурацию, историю сессий, журналы и настройки в одном каталоге на вашем компьютере. По умолчанию эта папка ( ~/.copilot то есть $HOME/.copilot).

В этой статье описывается содержимое этого каталога и то, как им можно пользоваться.

Обзор каталога

Каталог ~/.copilot содержит следующие элементы верхнего уровня.

Файлы, редактируемые пользователем

Следующие файлы предназначены для прямого редактирования вами или управления с помощью команд CLI.

settings.json

Это основной конфигурационный файл для Copilot CLI. В течение сессии вы можете использовать интерактивную /settings команду для изменения конкретных значений или запустить /settings KEY VALUE её для установки одного значения. См . раздел AUTOTITLE. В качестве альтернативы можно редактировать settings.json файл напрямую в текстовом редакторе. Файл поддерживает JSON с комментариями (JSONC).

По умолчанию этот файл находится в ~/.copilot каталоге, который является пользовательской конфигурационной директорией. Он содержит глобальные пользовательские настройки по умолчанию для всех репозиториев. Вы можете изменить расположение этой директории, установив COPILOT_HOME переменную окружения на другой путь.

Если settings.json не удается прочитать, проанализировать или проверить, Copilot CLI игнорирует недопустимые значения и отображает предупреждение о запуске на временной шкале, на которой вы направляете на вкладку /settings"Проблемы" команды. Откройте эту вкладку, чтобы увидеть конкретную ошибку, а затем исправьте сообщаемую проблему для восстановления затронутых параметров.

Если settings.json содержит ключ верхнего уровня, который не является распознаваемым параметром (например, опечаткой), он отображается на вкладке /settings"Проблемы" Copilot CLI команды вместо временной шкалы или в stderr. Метка вкладки показывает количество (например, Problems (2)) при возникновении проблем с любой областью конфигурации. $schema допускается и никогда не сообщается.

Если ~/.copilot/settings.json это асимметричная ссылка, например для синхронизации параметров с помощью репозитория dotfiles, записи из /settings команды следуют симлинку и обновляют целевой объект вместо замены симлинка обычным файлом.

Полный список настроек и их взаимодействие с конфигурацией на уровне репозитория см. раздел «Настройки конфигурационных файлов » позже в этой статье.

Используйте copilot config из оболочки за пределами сеанса для чтения или изменения параметров, неинтерактивно — аналог скрипта в команде косой /settings черты. Добавьте --repo или --local в целевой .github/copilot/settings.json или .github/copilot/settings.local.json вместо файла параметров пользователя. Можно записать только переопределимые ключи . Полный справочник по команде см. в разделе AUTOTITLE .

copilot-instructions.md

Личные индивидуальные инструкции, которые применимы ко всем вашим сессиям, независимо от того, над каким проектом вы работаете. Этот файл работает так же, как репозиторий copilot-instructions.md , но применяется глобально.

Дополнительные сведения см. в разделе Добавление пользовательских инструкций репозитория для GitHub Copilot.

instructions/

Здесь храните дополнительные личные инструкции в виде *.instructions.md файлов. Они загружаются вместе copilot-instructions.md и применяются ко всем вашим сессиям. Вы можете организовать инструкции по темам — например, ~/.copilot/instructions/code-style.instructions.md.

mcp-config.json

Определяет серверы MCP (Model Context Protocol), доступные на уровне пользователя. Эти серверы доступны во всех ваших сессиях, независимо от того, в каком вы каталоге проектов. Project-уровневые конфигурации MCP (в .mcp.json или .github/mcp.json) имеют приоритет над определениями на уровне пользователя при конфликте имён серверов.

Дополнительные сведения см. в разделе Добавление MCP-серверов для GitHub Copilot CLI.

lsp-config.json

Определяет серверы Language Server Protocol (LSP), доступные на уровне пользователя. Эти серверы предоставляют агенту языковой интеллект (диагностику, завершение и т.д.). Управляйте этим файлом с помощью /lsp команды slash или редактируйте его напрямую.

Дополнительные сведения см. в разделе Добавление серверов LSP для GitHub Copilot CLI.

providers.json

Определяет реестр поставщиков и моделей с собственным ключом (BYOK) в качестве объекта JSON с providers ключами и models ключами. Когда этот файл объявляет любой поставщик или модель, он имеет приоритет над устаревшими COPILOT_PROVIDER_* переменными среды.

По умолчанию этот файл расположен по адресу ~/.copilot/providers.json. Переопределите его расположение с помощью переменной COPILOT_PROVIDERS_CONFIG среды.

Модели в этом файле доступны вместе с моделями, предоставляемыми Copilot вашей подпиской. После редактирования файла вручную перезапустите Copilot CLI , чтобы загрузить изменения. Инструкции по настройке см. в разделе Добавление моделей LLM в интерфейс командной строки GitHub Copilot.

Структура конфигурации поставщика

Используйте объект JSON без примечаний или запятых. Файл содержит два массива. Каждый поставщик определяет подключение, и каждая модель ссылается на одного из этих поставщиков по имени. В приведенных ниже [] таблицах означает запись в массиве. Например, models[].capabilities.supports.vision параметр vision``supports``capabilitiesвнутри элемента модели.

Отсутствующий или пустой файл или файл без записей поставщика или модели позволяет CLI вернуться к COPILOT_PROVIDER_* переменным среды. null Значение для любого массива рассматривается как пустой массив. Вместо этого файл с недопустимыми записями JSON или недопустимыми поставщиками или моделями создает ошибку конфигурации.

Чтобы использовать настроенную модель при запуске интерфейса командной строки, перейдите PROVIDER-NAME/MODEL-ID к параметру --model . PROVIDER-NAME — это значение поставщика name и MODEL-ID является значением модели id . Например, выполните команду copilot --model local/qwen3:8b. Кроме того, во время интерактивного сеанса можно ввести /model и выбрать модель из средства выбора.

Этот файл настраивает подключения, возможности модели и инструкции по модели для использования.Copilot CLI Json в этом файле не является текстом запроса API поставщика. Параметры не передаются поставщику при их добавлении в этот файл.

Параметры поставщиков

Каждая запись в providers ней принимает следующие поля. Только name и baseUrl всегда обязательны. Требования к проверке подлинности зависят от поставщика.

Файл именованного поставщика не поддерживается apiKeyCommand. Не помещайте учетные данные или команды обновления маркеров в metadata или localModel.args.

Параметры сервера локальной модели

Эти параметры применяются только в том случае, baseUrl если providers[].type``"local_model" это путь к файлу.gguf. Интерфейс командной строки начинается llama-server при первом использовании модели. Исполняемый файл должен быть установлен и доступен.PATH Используйте абсолютный путь модели, чтобы избежать в зависимости от каталога, с которого запускается интерфейс командной строки.

Если baseUrl это URL-адрес HTTP или HTTPS, интерфейс командной строки подключается к существующему серверу и не использует эти параметры запуска. Они также не настраивают Ollama или другие серверы, совместимые с OpenAI.

Все поля внутри providers[].localModel являются необязательными.

Интерфейс командной строки управляет путем модели сервера, узлом и портом. Невозможно передать --model, -m``--hostили --port через args, включая такие формы, как --port=8080.

Параметры модели

Каждая запись в models ней принимает следующие поля. Только id и provider являются обязательными.

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

Возможности модели

Объект models[].capabilities описывает модель. Установка функции, которая не добавляет эту функцию true в модель, которая не поддерживает ее.

Все поля возможностей являются необязательными. Объекты объединяются со значениями по умолчанию модели, а массивы заменяют соответствующие массивы по умолчанию.

Поддерживаемые функции модели

Следующие поля относятся внутри models[].capabilities.supports.

Значения adaptive_thinking имеют следующие значения.

Для reasoning_effort, интерфейс командной строки распознает "none", "minimal", "low", "medium", "high"``"xhigh"и "max". Список только уровней, поддерживаемых моделью, например ["low", "medium", "high"]. Опущенный или пустой список оставляет интерфейс командной строки для использования по умолчанию для конкретной модели. Выберите уровень с --reasoning-effort помощью средства выбора моделей, где они доступны.

Ограничения возможностей модели

Следующие поля относятся внутри models[].capabilities.limits. Все они необязательны.

Предпочитайте поля модели maxPromptTokens``maxContextWindowTokensи maxOutputTokens поля при настройке бюджетов маркеров вручную. Обнаружение может сохранять ограничения в обоих местах. Сохраняйте согласованность повторяющихся значений, так как различные операции CLI считывают два представления. Для локальных серверов, управляемых интерфейсом командной строки, измеряемое ограничение контекста может иметь приоритет над настроенным значением.

Используйте не отрицательные целые числа для количества маркеров и размеров изображений, а также положительное целое число для количества изображений. Счетчики маркеров и количество изображений должны соответствовать 0``4294967295. Размеры изображений измеряются в байтах, а не в маркерах.

Системные сообщения модели

models[].systemMessage управляет системными инструкциями, используемыми при создании стандартного запроса для этой модели, включая подагенты общего назначения. Он имеет приоритет над конфигурацией сообщений на уровне сеанса в этих путях. Он не заменяет инструкции выбранного пользовательского агента или специализированного подагента.

Предпочитайте, "mode": "append" если вам нужны только дополнительные инструкции. Замена или удаление встроенных инструкций может изменить использование средства CLI и другое ожидаемое поведение. Опустить systemMessage , чтобы сохранить стандартные инструкции, а не задать для него значение null.

Принимаются только поля, перечисленные в режиме. Например, добавление sections без параметров "mode": "customize" приводит к ошибке конфигурации.

В содержимом замены {{copilot:memories}} вставляет инструкции и контексты памяти ИНТЕРФЕЙСА командной строки при наличии.

Разделы системного сообщения

В режиме customize``models[].systemMessage.sections сопоставляет имена разделов с объектами. Каждый объект задает action и при необходимости content. Например, models[].systemMessage.sections.tone изменяет раздел тона.

Доступны указанные ниже действия.

Действие transform не поддерживается providers.json , так как для него требуется обратный вызов приложения, а не сохраненная конфигурация JSON.

Используйте следующие имена разделов или групп в качестве ключей.sections

Изменения отдельных разделов применяются перед изменениями группы. Замена группы заменяет все его разделы-члены, включая разделы, которые вы настроили отдельно.

Блоки содержимого системного сообщения

В replace режиме models[].systemMessage.contentBlocks предоставляются инструкции по замене вместо простой content строки. Сохраняйте content представление, так как оно требуется в формате конфигурации. Все блоки должны иметь content строку.

Метаданные модели

models[].metadata — это объект, значения которого могут быть любым допустимым значением JSON. Это описательные данные, а не способ предоставления параметров запроса API или учетных данных. Вам не нужно добавлять метаданные вручную.

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

Пример конфигурации поставщика

В этом примере подключается к существующему серверу Ollama и показано, как вложены возможности модели и системные инструкции. Предполагается, что qwen3:8b он установлен. Ограничения маркеров являются примерами бюджетов, а не инструкцией максимальной емкости модели. Настройте их в соответствии с контекстом, настроенным на сервере.

{
  "providers": [
    {
      "name": "local",
      "type": "openai",
      "baseUrl": "http://127.0.0.1:11434/v1",
      "modelProvider": "ollama"
    }
  ],
  "models": [
    {
      "id": "qwen3:8b",
      "provider": "local",
      "name": "Qwen 3 8B",
      "maxPromptTokens": 6144,
      "maxContextWindowTokens": 8192,
      "maxOutputTokens": 2048,
      "capabilities": {
        "supports": {
          "vision": false,
          "toolCalls": true
        }
      },
      "systemMessage": {
        "mode": "customize",
        "sections": {
          "tone": {
            "action": "append",
            "content": "\nUse concise explanations."
          }
        }
      }
    }
  ]
}

{
  "providers": [
    {
      "name": "local",
      "type": "openai",
      "baseUrl": "http://127.0.0.1:11434/v1",
      "modelProvider": "ollama"
    }
  ],
  "models": [
    {
      "id": "qwen3:8b",
      "provider": "local",
      "name": "Qwen 3 8B",
      "maxPromptTokens": 6144,
      "maxContextWindowTokens": 8192,
      "maxOutputTokens": 2048,
      "capabilities": {
        "supports": {
          "vision": false,
          "toolCalls": true
        }
      },
      "systemMessage": {
        "mode": "customize",
        "sections": {
          "tone": {
            "action": "append",
            "content": "\nUse concise explanations."
          }
        }
      }
    }
  ]
}

После перезапуска интерфейса командной /model строки выберите эту модель с copilot --model local/qwen3:8b помощью средства выбора или средства выбора. Добавьте дополнительные объекты в любой массив для настройки дополнительных поставщиков и моделей.

agents/

Здесь храните личные определения пользовательских агентов в виде .agent.md файлов. Агенты, размещённые в этом каталоге, доступны во всех ваших сессиях. Если личный агент и агент уровня проекта имеют один и тот же идентификатор, например, если оба файла верхнего уровня называются reviewer.agent.md, личный агент имеет приоритет. Необязательное name поле frontmatter не управляет дедупликацией, поэтому агенты с одинаковыми name , но различными идентификаторами обоих загрузок.

Дополнительные сведения см. в разделе Создание и использование пользовательских агентов для GitHub Copilot CLI.

skills/

Здесь храните личные индивидуальные определения навыков. Каждый навык находится в подкаталоге, содержащем SKILL.md файл — например, ~/.copilot/skills/my-skill/SKILL.md. Личные навыки доступны во всех ваших сессиях. Навыки Project Level имеют приоритет над личными, если у них одинаковое название.

Дополнительные сведения см. в разделе Добавление навыков агента для GitHub Copilot CLI.

hooks/

Здесь можно хранить скрипты с крючками на уровне пользователя. Эти зацепки применимы ко всем вашим сессиям. Вы также можете задать крючки в строке в пользовательском конфигурационном файле (~/.copilot/settings.json) с помощью ключа hooks . Хуки уровня репозитория (in .github/hooks/) загружаются вместе с пользовательскими хуками.

Дополнительные сведения см. в разделе Использование крючков с GitHub Copilot CLI.

extensions/

Храните файлы расширений пользовательского уровня здесь. Расширения в этом каталоге доступны между сессиями.

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

Автоматически управляемые файлы

Следующие пункты управляются CLI. Обычно не стоит редактировать их вручную.

config.json

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

permissions-config.json

Сохраняет сохранённые решения по инструменту и разрешению каталога, организованные по расположению проекта. Когда вы одобряете инструмент или предоставляете доступ к каталогу текущего местоположения, CLI фиксирует решение здесь, чтобы вас больше не запросили в том же репозитории или каталоге.

Расположение файла

Copilot CLI Разрешает файл из каталога конфигурации.

Интерфейс командной строки использует только первый применимый каталог конфигурации в этом порядке. Он также не загружается permissions-config.json из расположений с более низким приоритетом.

Этот --config-dir вариант — наследие. Предпочитаю COPILOT_HOME , когда нужно менять каталог конфигурации.

В Windows стандартный файл обычно выглядит:

C:\Users\YOUR-USER\.copilot\permissions-config.json

Старые сборки использовали файл без расширения под названием permissions-config. Если permissions-config.json его нет, а файл без расширения есть, CLI всё равно учитывает наследственный файл. Используйте permissions-config.json для новых правок.

Предыдущие локации конфигурации на базе XDG мигрируются ~/.copilot при запуске, когда COPILOT_HOME она не настроена.

Ключи местоположения

Объект верхнего уровня locations определяется абсолютным путём.

• Для репозитория Git используйте корень Git, используемый для определения разрешений.
• Связанные рабочие деревья разрешаются на основной корень репозитория, поэтому они разделяют права с основным деревом работы.
• Подмодули используют собственную рабочую директорию.
• Для каталога, который не входит в репозиторий Git, используйте нормализованный текущий рабочий каталог.

Ключ должен совпадать с местом, где Copilot CLI он работает. Если ключ не совпадает, сохраненные одобрения не будут применяться.

CLI загружает одобрения соответствующего места при начале сессии и изменении активного рабочего каталога.

Схема

Файл должен содержать объект JSON.

permissions-config.json не поддерживает правила отказа, правила «спросить», режимы по умолчанию, правила URL, фильтрацию инструментов или совместную политику репозитория. Для таких действий используйте командные опции, такие --deny-toolкак , --available-tools, --excluded-tools``--allow-url, и --deny-url. Правила сохранения URL хранятся в settings.json, а не в permissions-config.json.

Неизвестные поля не входят в схему. CLI может их игнорировать, а последующие записи могут их удалять.

Виды одобрения

Каждый элемент должен tool_approvals быть одним из следующих объектов.

Для одобрения MCP serverName должно точно совпадать с настроенным именем сервера MCP. Используйте сырое имя сервера из вашей конфигурации MCP, а не очищенный префикс имени инструмента.

Сопоставление команд оболочки

permissions-config.json не поддерживает регулярные выражения или общие шаблоны глобов. Строковые значения совпадают буквально, за исключением того, что :* значение оболочки commandIdentifiers соответствует тексту до :*того, как само по себе или за ним следует пробел и больше текста. Равнина * не имеет особого смысла, поэтому git* не соответствует git status.

Сопоставление каталогов

allowed_directories Записи позволяют Copilot CLI получать доступ к путям внутри этих каталогов без отдельного запроса на путь. Они не одобряют саму работу инструмента. Например, редактирование файла в разрешённой папке всё равно может требовать write одобрения.

Каждая allowed_directories запись должна быть абсолютной, непустой и доступной папкой. CLI разрешает симлинки перед сравнением путей, блокирует сетевые пути UNC, если они не являются локальными путями расширенной длины, сравнивает пути без падежа в Windows и сравнивает пути с учетом регистра на других платформах. Если запись не может быть применена, CLI фиксирует предупреждение и пропускает эту запись.

Примеры

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

{
  "locations": {
    "C:\\src\\my-repo": {
      "tool_approvals": [
        {
          "kind": "commands",
          "commandIdentifiers": ["git:*"]
        }
      ],
      "allowed_directories": ["C:\\src\\shared-docs"]
    }
  }
}

{
  "locations": {
    "C:\\src\\my-repo": {
      "tool_approvals": [
        {
          "kind": "commands",
          "commandIdentifiers": ["git:*"]
        }
      ],
      "allowed_directories": ["C:\\src\\shared-docs"]
    }
  }
}

Разрешите выбранные команды, всё ещё спрашивая перед записью файла:

{
  "locations": {
    "/Users/YOUR-USER/src/my-repo": {
      "tool_approvals": [
        {
          "kind": "commands",
          "commandIdentifiers": [
            "git status",
            "git diff",
            "git log",
            "npm test",
            "npm run build"
          ]
        }
      ]
    }
  }
}

{
  "locations": {
    "/Users/YOUR-USER/src/my-repo": {
      "tool_approvals": [
        {
          "kind": "commands",
          "commandIdentifiers": [
            "git status",
            "git diff",
            "git log",
            "npm test",
            "npm run build"
          ]
        }
      ]
    }
  }
}

Approve file writes и один MCP-сервер для репозитория:

{
  "locations": {
    "/home/YOUR-USER/src/my-repo": {
      "tool_approvals": [
        {
          "kind": "write"
        },
        {
          "kind": "mcp",
          "serverName": "github-mcp-server",
          "toolName": null
        }
      ]
    }
  }
}

{
  "locations": {
    "/home/YOUR-USER/src/my-repo": {
      "tool_approvals": [
        {
          "kind": "write"
        },
        {
          "kind": "mcp",
          "serverName": "github-mcp-server",
          "toolName": null
        }
      ]
    }
  }
}

Одобрить один MCP-инструмент, запись в памяти и доступ к разрешениям расширения:

{
  "locations": {
    "C:\\src\\my-repo": {
      "tool_approvals": [
        {
          "kind": "mcp",
          "serverName": "github-mcp-server",
          "toolName": "search_code"
        },
        {
          "kind": "memory"
        },
        {
          "kind": "extension-permission-access",
          "extensionName": "my-extension"
        }
      ]
    }
  }
}

{
  "locations": {
    "C:\\src\\my-repo": {
      "tool_approvals": [
        {
          "kind": "mcp",
          "serverName": "github-mcp-server",
          "toolName": "search_code"
        },
        {
          "kind": "memory"
        },
        {
          "kind": "extension-permission-access",
          "extensionName": "my-extension"
        }
      ]
    }
  }
}

session-state/

Содержит данные истории сессий, организованные по идентификатору сессии в подкаталогах. Каждый каталог сессии хранит журнал событий (events.jsonl) и артефакты рабочего пространства (планы, контрольные точки, отслеживаемые файлы). Эти данные позволяют возобновить сессию (--resume или --continue).

Удаление файлов из этой папки удаляет только локальные копии. Если у вас синхронизированы сессии с аккаунтом GitHub , синхронизированные данные хранятся отдельно и не зависят от локального удаления файлов. Вы можете удалить или скрыть синхронизированные сессии из GitHub.com. Дополнительные сведения см. в разделе Сведения о GitHub Copilot данных сеанса.

command-history-state/

Содержит данные истории команд, используемые для обратного поиска (Ctrl R+) и навигации по истории в интерактивном интерфейсе. Этот каталог управляется автоматически и не подлежит редактированию.

session-store.db

База данных SQLite, используемая CLI для межсессионных данных, таких как индексация контрольных точек и поиск. Этот файл управляется автоматически и не должен редактироваться.

Если вы удалите этот файл, его можно восстановить с помощью команды /chronicle reindex . Реиндексация также синхронизирует данные сессии с аккаунтом.

logs/

Содержит лог-файлы для сессий CLI. Каждая сессия создаёт лог-файл с названием process-{timestamp}-{pid}.log. Эти файлы полезны для отладки.

CLI также может создавать логи, специфичные для расширения, в разделе logs/extensions/.

Это отдельно от ~/.copilot/extensions/, где хранится код расширений, созданный пользователем.

installed-plugins/

Содержит файлы для установленных вами плагинов. Плагины, установленные на маркетплейсе, хранятся в .installed-plugins/{marketplace-name}/{plugin-name}/ Напрямую установленные плагины хранятся в .installed-plugins/_direct/ Управляйте плагинами с copilot plugin помощью команд, а не редактировать эту папку напрямую.

Дополнительные сведения см. в разделе Ссылка на плагин GitHub Copilot CLI.

plugin-data/

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

ide/

Содержит файлы блокировки и состояние для интеграций с IDE (например, при Copilot CLI подключении к Visual Studio Code). Этот каталог управляется автоматически.

mcp-oauth-config/

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

mcp-secrets/

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

Изменение расположения каталога конфигурации

Чтобы переопределить местоположение по умолчанию ~/.copilot , установите COPILOT_HOME переменную среды на путь к нужной вам директории.

export COPILOT_HOME=/path/to/my/copilot-config

export COPILOT_HOME=/path/to/my/copilot-config

Вещи, которые следует учитывать

• COPILOT_HOME заменяет весь ~/.copilot путь. Значение должно быть полным путём к нужной директории, которую вы хотите использовать для конфигурационных файлов и подкаталогов.

• Изменение каталога означает, что ваша существующая конфигурация, история сессий, установленные плагины и сохранённые права не будут найдены в новом месте. Скопируйте или переместите содержимое ~/.copilot в новый адрес, если хотите сохранить его.

• Каталог кэша (используемый для маркетплейс-кэшей, автоматического обновления пакетов и других временных данных) следует платформным конвенциям и не подвергается COPILOT_HOMEвлиянию . Он расположен по адресу:

  • macOS:~/Library/Caches/copilot
  • Linux: $XDG_CACHE_HOME/copilot или ~/.cache/copilot
  • Windows:%LOCALAPPDATA%/copilot

  Чтобы отдельно переопределить каталог кэша, установите COPILOT_CACHE_HOME.

Что можно безопасно удалить

Настройки конфигурационных файлов

Настройки применяются в следующем порядке (позже переопределяются раньше):

1. Встроенные значения по умолчанию
2. Управляемые настройки Mobile Управление устройствами (MDM)
3. Пользовательские настройки (~/.copilot/settings.json)
4. Настройки репозитория (.github/copilot/settings.json)
5. Локальные настройки (.github/copilot/settings.local.json)
6. Переменные среды
7. Флаги командной строки

Управляемые настройки MDM загружаются при запуске и объединяются с пользовательскими настройками как базовая база политики. Для большинства клавиш пользовательские настройки могут переопределить эту базовую линию. Для permissions.disableBypassPermissionsMode, MDM-значение "disable" всегда выигрывает. Управляемые sandbox параметры являются еще одним исключением. Вместо переопределения каждое управляемое sandbox значение задает пол, который нельзя расслабить. Если ваш собственный параметр более разрешительный, управляемое значение выигрывает. Параметр sandbox.failIfUnavailable можно задать только администратором. Для получения дополнительной информации см. управляемые настройки MDM.

CLI также читает и для общего кросс-инструментального подмножества настроек репозитория (таких .claude/settings.jsonкак , .claude/settings.local.json, companyAnnouncements, disableAllHooks, и enabledPlugins).extraKnownMarketplaces``hooks

Значения по умолчанию репозитория являются необязательными: задайте enabledPlugins записи false в локальных параметрах репозитория, чтобы переопределить значения по умолчанию репозитория. Управляемые обязательные или заблокированные записи подключаемого модуля всегда выигрывают. См . раздел AUTOTITLE.

Пользовательские настройки (~/.copilot/settings.json)

Эти настройки применимы ко всем вашим сессиям и репозиториям. Вы можете использовать /settings команду slash для запуска интерактивного диалога, или специальные команды для обновления отдельных значений, либо редактировать этот файл напрямую.

Диалоговое /sandbox окно группирует проверку подлинности, gh проверку подлинности и маскированные переменные среды в выделенной вкладке "Учетные данные " и показывает settings.json путь, по которому хранится текущая конфигурация песочницы. На вкладке "Файловая система " список настроенных путей суммируется по разрешениям (например, 2 read/write, 1 read-onlyза строкой, настроенной пользователем ). Нажмите клавишу ВВОД в этой строке, чтобы открыть полный список, который берет на себя курсор и панель вкладок, пока не нажимаете клавишу ESC. Настроенные пути отображаются как абсолютные пути, а не ./относительные или ~сокращенные формы. Ввод ~/path при добавлении пути по-прежнему расширяет его в домашний каталог. Нажмите клавиши CTRL+E в /sandbox диалоговом окне, чтобы сохранить ожидающие изменения и открыть settings.json его в редакторе (COPILOT_EDITORилиVISUAL``EDITOR) с одинаковым ярлыком/settings. Диалоговое окно перезагрузит его состояние с диска после изменения и сохранения файла.

Правила узла и sandbox.userPolicy.network.proxy использование встроенного локального прокси-сервера. При настройке обоих локальный прокси применяет правила узла перед пересылкой трафика в вышестоящий прокси-сервер. Исходящие учетные данные остаются вне изолированного дочернего процесса. Правила узла и параметры прокси-сервера неактивны при отключении исходящего доступа.

Если прокси-сервер не задан в параметрах песочницы, локальный прокси-сервер выбирает его вышестоящий прокси-сервер из первой непустой переменной среды на узле в этом порядке: HTTPS_PROXY, , HTTP_PROXY. ALL_PROXY Поддерживаются только http:// и https:// прокси-серверы, а не socks5.

Назначения, соответствующие обходу узла NO_PROXY , соответствуют только этому наследуемого вышестоящего прокси-сервера. Локальный прокси-сервер песочницы по-прежнему обрабатывает эти подключения и применяет правила узла. Прокси-сервер, настроенный в параметрах песочницы, игнорирует NO_PROXY.

В macOS и Linux песочница ограничивает прямые подключения, поэтому программы не могут избежать прокси-сервера. В Windows песочница зависит от программ с учетом параметров прокси-сервера. В результате программы, которые игнорируют параметры прокси-сервера в Windows, могут напрямую подключаться и обойти правила узла. Windows правила прокси-сервера и узла также требуют поддерживаемого узла и allowLocalNetwork: trueразрешения доступа к частной сети. В Linux параметры прокси-сервера отклоняют литералы адресов IPv6, отличные от подстановочного знака двойного [::] стека. Используйте конечную точку IPv4 или имя узла с поддержкой IPv4.

Параметры песочницы — это управляемые пользователем или предприятиями параметры. Они не переопределяются репозиторием. Инструкции по настройке и ограничения сети см. в разделе Настройка локальных настроек песочницы.

Песочница поддерживается Microsoft контейнер eXecution (MXC), который предоставляет серверные серверы, зависящие от платформы. Copilot CLIиспользуется Seatbelt в macOS, Bubblewrap в Linux и ProcessContainer на Windows.

Настройки репозитория (.github/copilot/settings.json)

Настройки репозитория применимы ко всем, кто работает в репозитории. Они привержены хранилищу и делятся ими с сотрудниками.

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

model, effortLevelи contextTier переопределения применяются только в том случае, если рабочий каталог является доверенным.

Подключаемый модуль, включенный только через репозиторий enabledPlugins , ограничен этим репозиторием: он автоматически устанавливает и активирует в декларируемом репозитории, но остается отключенным глобально, поэтому он никогда не активируется в не связанных проектах. Выход из репозитория или репозиторий, отключающий подключаемый модуль, удаляет сервер MCP и деактивирует агенты и навыки сеанса.

Список разрешений моделей уровня репозитория (.github/allowed_models.txt)

Ограничение того, какие встроенные модели репозитория могут использовать с списком .github/allowed_models.txtразрешений обычного текста, разрешенным из корневого каталога текущего рабочего каталога (или рабочего каталога за пределами репозитория).

Каждая строка — это шаблон глоба, соответствующий идентификаторам модели, или fallback: директива, именующая модель, используемую, если настроенная или запрошенная модель не разрешена:

# .github/allowed_models.txt
fallback: gpt-6-astra
gpt-6-astra
gpt-6-sol
claude-sonnet-*

Негабаритные шаблоны () не поддерживаются, резервная модель должна быть точным идентификатором (!patternа не глобом), а резервная модель должна соответствовать одной из настроенных глобов. Copilot CLI Повторно оценивает политику /cd и отклоняет недопустимый файл с ошибкой перед выполнением.

Список разрешений управляет только Copilotвстроенными моделями. Не удается отфильтровать пользовательские модели, добавленные с помощью метода "Ключи API" (BYOK). Модели BYOK остаются в списке и выбираются независимо от настроенных шаблонов, и fallback: директива никогда не применяется к ним. Дополнительные сведения см. в разделе [AUTOTITLE и Включение пользовательских моделей для GitHub Copilot в организации](/copilot/how-tos/administer-copilot/manage-for-organization/enable-custom-models).

Локальные настройки (.github/copilot/settings.local.json)

Создайте .github/copilot/settings.local.json в репозитории личные перемены, которые не должны быть коммитированы. Добавить этот файл в .gitignore.

Локальный конфигурационный файл использует ту же схему, что и файл конфигурации репозитория (.github/copilot/settings.json), и имеет приоритет над ней.

Управляемые настройки MDM

ИТ-администраторы могут запускать базовую политику с помощью управляемых настроек Mobile Управление устройствами (MDM) вместо необходимости конфигурации для каждого пользователя. Эти настройки применяют устройства по умолчанию для поддерживаемых клавиш и загружаются до пользовательских настроек.

Управляемые параметры применяются равномерно в каждом режиме размещения сеансов — интерактивном, -p, , --acp``--ahp-hostи —поэтому корпоративная MCP, разрешение и --serverполитика подключаемых модулей не могут быть обходить путем запуска сеанса через другую точку входа.

Copilot CLI также загружает параметры, управляемые сервером при запуске, в дополнение к MDM. Параметры, управляемые устройством (MDM) и управляемые сервером, разрешаются на один ключ: значение MDM выигрывает для всех заданных ключей, а значение сервера заполняется ключами MDM не задано. Это позволяет организации задать определенную политику с помощью MDM (например, permissions), получая другие управляемые значения по умолчанию (например, model) с сервера.

Длительные сеансы повторно извлекает и повторно применяет управляемые параметры почасово, поэтому изменения политики, например, организация, включающая permissions.disableBypassPermissionsMode, вступают в силу без перезапуска сеанса.

Источники управляемых настроек MDM

Copilot CLI читает управляемые настройки из специализированных для платформы MDM или файловых локаций.

Формат файла

Пишите управляемые настройки на основе файлов в формате JSON.

{
    "model": "auto",
    "permissions": {
        "disableBypassPermissionsMode": "disable"
    }
}

Поддерживаемые ключи

В управляемых настройках MDM поддерживаются только следующие ключи.

"disable" Установите значение permissions.disableBypassPermissionsMode в управляемых параметрах MDM, чтобы заблокировать все параметры на уровне устройства. Параметры учетной записи не могут переопределить эту политику. Если задано нераспознанное значение, интерфейс командной строки регистрирует проблему и применяется "disable" как неисправное значение по умолчанию. См . раздел AUTOTITLE.

• Большинство управляемых ключей блокируют всю строку: локальное изменение автоматически переопределяется управляемым значением при следующей загрузке. enabledPlugins и extraKnownMarketplaces это исключение— управляемый слой объединяет эти карты с собственными записями по полю вместо того, чтобы заменить их прямо. Это означает, что блокировка применяется для каждой записи, а не ко всему ключу: подключаемый модуль или Marketplace, закрепленный управляемой политикой, не может быть повторно включен, отключен или перенаправлен локально, но другие записи на той же карте остаются полностью управляемыми пользователем.

sandbox.learningModeимеет значение Windows только и может быть задано только с помощью собственного MDM (например, через Intune или реестр) — managed-settings.json значение файла игнорируется. На узле с записью отказа установите его "allow" для запуска изолированных команд оболочки в режиме записи и разрешения вместо режима записи и запрета по умолчанию, записывая каждую файловую систему или доступ к процессу и разрешая ей, а не отказываясь от нее (сетевая политика по-прежнему применяется). Это позволяет администратору отслеживать, какие команды когорты необходимы, прежде чем блокировать их; он не является режимом хранения. В строке состояния отображаются sandbox relaxed и вызовы оболочки отображаются (sandbox relaxed) во время его применения. deny Значение (по умолчанию) или удаление ключа возвращает когорту в обычную песочницу, а deny из любого управляемого канала всегда выигрываетallow. Параметры пользователя и узлы пакета SDK не могут задать этот ключ.

Правила управляемого разрешения

Добавьте denyи ask``allow списки правил под управляемым permissions ключом, чтобы применить политику разрешений для всех. Это работает независимо от того, задано ли permissions.disableBypassPermissionsMode значение.

{
    "permissions": {
        "deny": ["Shell(rm -rf *)", "Domain(*.evil.example)"],
        "ask": ["Shell(git push *)"],
        "allow": ["Read(**)"]
    }
}

Правила объединяются между управляемыми источниками с фиксированным приоритетом: всегда отклонять победы, а затем запрашивать, а затем разрешать— сопоставление deny правила блокирует запрос, даже если правило также соответствует правилу allow . deny и ask объединяются между каждым управляемым источником (сервером, MDM). allow требует каждого источника, объявляющего allow список, чтобы признать операцию — пересечение, а не объединение. Если любой из denyнаборов или ask``allow установлен, операция, которая не соответствует ни одному из них по умолчаниюask, а не падает безмолвно.

Edit(...) и Write(...) правила применяются к более чем встроенным средствам файлов. Они также охватывают файлы, написанные непосредственно командой оболочки. Copilot CLI распознает фиксированный набор этих записей. В ней рассматриваются перенаправления выходных данных Bash (, , , >|, ), выходные перенаправления PowerShell (>, >>, *>``*>>), а также небольшой набор изменений на месте sed (>``sed -iили --in-place, а также формы -i '' BSD и ).-I ''``&>>``&>``>> Когда Copilot CLI можно выработать целевой файл из команды, deny соответствующее правило блокирует запись и ask соответствующее правило сначала запрашивает. Это применяется даже в том случае, если широкое правило, например Shell(*) , разрешает команду. Иногда целевой файл не может быть заранее разработан, например, когда путь поступает из переменной. В этом случае эти правила пути не применяются, и команда проверяется обычными правилами команд оболочки.

Граница домена (limitTo)

Добавьте массив рядом limitTo с ask``denyключом и allow под управляемым permissions ключом для принудительного применения списка разрешений домена закрытого мира:

{
    "permissions": {
        "limitTo": ["gh.asamalin.top", "*.gh.asamalin.top"]
    }
}

Поддерживаются limitToтолько Domain(...) записи. Любой запрос сети агента к домену за пределами списка запрещен без запроса, а правила пользователя, сохраненные утверждения и режимы разрешений не могут расширить его. URL-адреса, обнаруженные в запросах оболочки, обрабатываются как Domain запросы, а также должны соответствовать границе. limitToне ограничивает shell``readсами операции или write операции.

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

deny по-прежнему имеет приоритет над limitTo. ask и allow только уточняйте запросы, которые уже находятся внутри границы. Как allowи, limitTo является пересечением между управляемыми источниками — каждый управляемый источник, объявляющий limitTo список, должен признать запрос.

Список разрешений и запретов управляемого сервера MCP

Администраторы могут управлять серверами MCP непосредственно с помощью управляемых параметров MDM, независимо от списка разрешений MCP предприятия.

Задайте allowedMcpServers и(или) deniedMcpServers в источнике управляемых параметров:

{
    "allowedMcpServers": [
        { "serverUrl": "https://mcp.example.com/*" },
        { "serverCommand": ["npx", "-y", "@example/mcp-server"] }
    ],
    "deniedMcpServers": [
        { "serverName": "untrusted-server" }
    ]
}

Каждая запись идентифицирует сервер точно одним из следующих совпадений.

Правила:

• Доверенные сторонние серверы (например, встроенный GitHub сервер MCP) всегда освобождаются от обоих списков.
• Unset allowedMcpServers разрешает все серверы, отличные от по умолчанию; Пустой массив блокирует все из них (запретить все).
• Отмена набора или пустого deniedMcpServers ничего не блокирует.
• Запрет всегда выигрывает— сопоставление deniedMcpServers сервера блокируется, даже если он также соответствует allowedMcpServers.
• Для удаленных серверов совпадение должно поступать из serverUrl записи; serverName только при отсутствии serverUrl записей. Для серверов stdio совпадение должно поступать из serverCommand записи; serverName только при отсутствии serverCommand записей.

Дополнительные материалы

• GitHub Copilot CLI
• Справочник команды GitHub Copilot CLI
• GitHub Copilot CLI программный справочник
• Ссылка на плагин GitHub Copilot CLI
• Ссылка на крючки GitHub Copilot