Claude Code в CI полезен ровно настолько, насколько узко ему выданы права. Официальная GitHub Action - anthropics/claude-code-action@v1; она сама выбирает режим интерактивного упоминания или немедленной автоматизации по триггеру и конфигу. Основные входы - prompt, ключ anthropic_api_key или облачная аутентификация и claude_args для флагов. Но главное в CI - не то, что агент умеет, а то, что ему разрешено: least privilege здесь не рекомендация, а условие безопасности.

Разумный workflow начинается с минимальных permissions. Полезно один раз увидеть цельный пример: триггер на pull_request, permissions в объёме contents read и pull-requests write, concurrency с отменой предыдущих прогонов, checkout с persist-credentials false и вызов action с prompt и узким claude_args. Ключ хранится только в GitHub Secrets, а claude_args ограничивает max-turns и allowedTools чтением. Такой workflow делает ровно то, что нужно для review, и ничего сверх.

Permissions выдают строго под требуемое поведение. Комментировать issue может потребовать issues write, а commit и push - contents write; выдавать write "на всякий случай" нельзя. Отдельная осторожность - fork-PR: у GitHub своя secret-модель для форков, и запускать привилегированный недоверенный код без отдельного дизайна опасно. Быстрая установка есть через /install-github-app, но production-workflow всё равно ревьюят как код, а для Bedrock и Google Cloud предпочитают OIDC вместо долгоживущих ключей.

GitLab интегрируют похоже, но своими средствами. Официальная интеграция использует CI-job, Claude Code и GitLab MCP-сервер, и для production документация рекомендует ручную настройку. Переменные хранят API- или облачные credentials и доступ к GitLab, а job rules ограничивают источники и ветки pipeline. Полезно один раз увидеть минимальный read-only пример: job на merge-request, установка Claude Code, bare-прогон с dontAsk и узким allowlist, результат в артефакт.

Важно понимать границы такого минимального примера. Read-only job сам по себе не публикует комментарий - он лишь готовит результат. Для полноценного взаимодействия с GitLab следуют официальной настройке MCP-сервера и выдают только необходимые API-scopes; write-инструменты вроде mcp__gitlab не добавляют, пока job действительно не должен комментировать или создавать merge request. Это тот же принцип least privilege: сначала read-only и артефакт, а право записи - только под доказанную потребность.