Развертывание самостоятельно размещаемых окружений в production

​

Усиление безопасности развертывания

• Эфемерные контейнеры для каждого сеанса: запускайте каждый процесс runner в свежем контейнере или VM, который уничтожается при выходе процесса, с --capacity 1 и значением по умолчанию --drain-grace-sec 0, чтобы каждый контейнер обслуживал ровно один сеанс. При более высокой емкости или положительном периоде осушения один контейнер обслуживает несколько сеансов от одного заблокированного владельца; см. Runner lifecycle. Не переиспользуйте файловую систему между перезагрузками runner, кроме намеренной настройки pre-warmed checkout, и никогда между владельцами.
• Нет широких учетных данных в образе: не включайте долгоживущие SSH-ключи, учетные данные облачного провайдера или личные токены доступа, которые предоставляют больше, чем нужно сеансу. Создавайте учетные данные, используемые во время сеанса, такие как токены push или API, для каждого сеанса из вашего скрипта-обертки. Для начального клонирования, которое происходит перед запуском обертки, используйте checkout lifecycle hook или --use-anthropic-git-proxy; см. Configure git.
• Держите секрет окружения в тайне от хостов, запускающих сеансы: секрет окружения может регистрировать runners и получать любой сеанс, поставленный в очередь в окружение. На фиксированном флоте он живет на каждом хосте runner, где код любого сеанса может прочитать файл секрета. Предпочитайте on-demand runners, где секрет остается на хосте оркестратора, который никогда не запускает пользовательский код, и каждый runner получает одноразовый наряд на работу, который регистрирует ровно один runner. На фиксированном флоте рассматривайте файл environment-secret как читаемый каждым сеансом и ротируйте секрет после любого подозреваемого компрометирования сеанса.
• Исходящий трафик по умолчанию запрещен: ограничьте исходящий трафик контейнеров runner и сеанса на границе вашей собственной сети в каждом окружении; Default-deny egress охватывает, что разрешить и почему.
• Наименьшие привилегии хоста IAM: вычислительная идентификация, прикрепленная к хосту runner, такая как профиль экземпляра или учетная запись сервиса узла, должна предоставлять только то, что нужно самому runner. Сеансы должны получать свои собственные учетные данные через ваш скрипт-обертку, а не наследовать идентификацию хоста.
• Блокируйте конечную точку облачных метаданных от сеансов: чтобы держать сеансы вне хоста идентификации, требуется блокировать их доступ к конечной точке облачных метаданных, и политики исходящего трафика на уровне подсети не перехватывают трафик метаданных link-local, поэтому блокируйте его в самом контейнере:
  • IMDSv2 с пределом хопов в один
  • GKE Workload Identity с скрытием метаданных
  • Явный отказ для 169.254.169.254 в пространстве имен сети контейнера сеанса
  Блокировка применяется к вашему скрипту-обертке и lifecycle hooks, так как они используют контейнер. Аутентифицируйте любой обмен токенами с session JWT против вашего собственного сервиса токенов через разрешенный исходящий трафик, или используйте веб-идентификацию на основе файлов, такую как IAM Roles for Service Accounts (IRSA) на Amazon EKS.
• Изоляция файловой системы для каждого runner: каждый процесс runner получает свой собственный рабочий каталог, который никакой другой процесс на хосте не может читать или писать. Сделайте --hooks-dir, скрипт-обертку и хост ~/.claude/ доступными только для чтения сеансом, либо встроенными в образ, либо смонтированными только для чтения.
• Отправка не имеет контроля доступа для каждого окружения: любой член вашей организации Anthropic может отправить сеанс в любое из его окружений. Если Owner направляет каналы Claude Tag в окружение, любой, кого допускает параметр доступа Claude Tag, может запустить сеансы канала, которые работают там. По умолчанию это любой в подключенном рабочем пространстве Slack, с учетной записью Claude или без нее. Рассматривайте каждый хост runner как доступный для выполнения кода всеми, кто может отправить в него, и размещайте на хосте runner только данные и учетные данные, которые все эти люди имеют право читать. --lock-to-account ограничивает, какие сеансы учетной записи выполняет данный хост, но это не сужает, кто может отправить в окружение. Чтобы сделать самостоятельно размещаемые окружения единственным вариантом выбора, Owner может скрыть окружения, размещаемые Anthropic, для всей организации на странице Cloud environments.
• Применяйте защиту repo-settings: выберите режим защиты с помощью --confine-repo-settings. По умолчанию warn регистрирует нарушение и все еще порождает сеанс, enforce отказывает в сеансе, а off отключает сканирование. Runner сканирует параметры каждого репозитория для:
  • Гранта, который разрешается вне рабочего пространства этого сеанса: запись additionalDirectories, правило Edit, Write или NotebookEdit в permissions.allow, или запись sandbox.filesystem.allowWrite или allowRead
  • Непустой блок env
  • Переопределение позиции оператора, такое как sandbox.enabled: false
  Защита работает независимо от --trust-workspace и не охватывает hooks репозитория, .mcp.json или правила Bash; см. Permissions and tool approval для того, где должны находиться эти гранты.

​

Требования к сети

​

Default-deny egress

​

Аутентификация на исходящий прокси

​

Выберите, откуда берется значение Proxy-Authorization

• --proxy-authorization-command <command>: выберите это для токена, который вы генерируете по требованию. Runner запускает команду shell и использует ее обрезанный stdout как значение заголовка, например Bearer <token>.
• --proxy-authorization-file <path>: выберите это для токена, который другой процесс ротирует на месте. Runner читает файл и использует его обрезанное содержимое как значение заголовка.

​

Конфигурации, с которыми runner отказывается запускаться

• Оба флага установлены: один флаг плюс переменная окружения другого флага считается установкой обоих.
• Нет URL прокси: ни HTTPS_PROXY ни HTTP_PROXY не содержат URL http:// или https://. Runner читает обе переменные в верхнем или нижнем регистре и не консультирует ALL_PROXY.
• Любой флаг передан подкоманде orchestrator: self-hosted-runner orchestrator не принимает флаги или их переменные окружения. Вместо этого передайте флаг каждому runner, который запускает оркестратор.

​

Что runner изменяет, пока установлен флаг proxy-authorization

• Слушатель: слушатель является forward proxy на 127.0.0.1. Runner запускает слушатель перед регистрацией в плоскости управления и выходит при запуске, если слушатель не может запуститься.
• Переменные прокси: runner переписывает любой из HTTPS_PROXY и HTTP_PROXY, который вы установили, чтобы он указывал на слушатель. Это переписанное значение достигает самого runner, его lifecycle hooks и каждого сеанса, который он запускает.
• Ротация токена: ротированный токен вступает в силу без перезагрузки. Для каждого соединения, которое слушатель открывает для вашего прокси, runner запускает вашу команду или читает ваш файл снова и добавляет результат как заголовок.
• Окружение сеанса: сеанс достигает вашего прокси только через слушатель. В окружении каждого сеанса runner удаляет ALL_PROXY, удаляет любое написание HTTPS_PROXY или HTTP_PROXY, которое вы не установили, и закрепляет NO_PROXY на собственное значение runner.
• Логи: runner никогда не регистрирует значение заголовка.

​

Конфигурирование git

• Позвольте runner конфигурировать git: запустите runner с --configure-git, чтобы он написал ту же идентификацию и конфигурацию подписи коммитов, которые используют сеансы, размещаемые Anthropic
• Отправьте конфигурацию git в вашем образе: установите идентификацию и учетные данные push самостоятельно, например, чтобы коммитить под вашей собственной идентификацией бота

​

Позвольте runner конфигурировать git

• user.name = Claude и user.email = noreply@anthropic.com, соответствуя сеансам, размещаемым Anthropic
• Подпись коммитов и тегов в формате SSH, маршрутизированная через управляемый runner shim, который подписывает каждый коммит через сервис подписи Anthropic, используя собственные учетные данные сеанса. Подписи проверяются на GitHub против опубликованного SSH-ключа подписи Anthropic.
• push.negotiate = true, чтобы git спросил ваш git-хост, какие коммиты он уже имеет, перед упаковкой push. Требует Claude Code v2.1.257 или позже.
• core.hooksPath, указывающий на управляемый runner каталог hooks. Его hooks commit-msg и prepare-commit-msg добавляют трейлер Co-authored-by: для создателя сеанса к каждому коммиту, построенный из email в CCR_SESSION_ACCOUNT_EMAIL и опущенный, когда эта переменная не установлена. Если ваш образ уже устанавливает core.hooksPath, runner оставляет вашу настройку на месте, пропускает установку этих hooks и печатает предупреждение [runner:git].

​

Отправьте конфигурацию git в вашем образе

RUN git config --system user.name "Claude" && \
    git config --system user.email "noreply@anthropic.com"

• SSH-ключ развертывания, ограниченный одним репозиторием с переписью url.<base>.insteadOf
• credential.helper, который возвращает минимально охватывающий токен
• GIT_SSH_COMMAND, указывающий на узко охватывающий ключ

• Runner устанавливает GIT_TERMINAL_PROMPT=0, чтобы git не спрашивал имя пользователя или пароль.
• Runner запускает SSH с BatchMode=yes, добавленным к вашему GIT_SSH_COMMAND, если вы его установили, чтобы SSH не спрашивал парольную фразу или подтверждение хоста.
• Runner устанавливает GCM_INTERACTIVE=never, чтобы Git Credential Manager не открывал диалог входа.
• Runner очищает core.askPass, поэтому, если вы используете помощника askpass, установите его через переменную окружения GIT_ASKPASS вместо этого.

RUN git config --system --add safe.directory '*'

​

Используйте прокси git Anthropic

​

Переписывайте URL git для приватных сетей

• --git-host-rewrite <from>=<to>: для split-horizon DNS, где Anthropic достигает вашего git-хоста через внешнее имя хоста, но runners должны использовать внутреннее
• --git-ssh-rewrite <host>: для git-хостов, которые принимают только SSH, переписывая https://<host>/owner/repo на git@<host>:owner/repo

​

Постройте образ runner

FROM debian:bookworm-slim
ARG CLAUDE_CODE_VERSION
RUN apt-get update && apt-get install -y --no-install-recommends git curl ca-certificates openssh-client \
 && rm -rf /var/lib/apt/lists/*
RUN curl -fsSL "https://downloads.claude.ai/claude-code-releases/${CLAUDE_CODE_VERSION:?set with --build-arg CLAUDE_CODE_VERSION}/linux-x64/claude" \
      -o /usr/local/bin/claude && chmod +x /usr/local/bin/claude
RUN git config --system user.name "Claude" \
 && git config --system user.email "noreply@anthropic.com" \
 && git config --system --add safe.directory '*'
ENTRYPOINT ["claude"]

docker build --build-arg CLAUDE_CODE_VERSION=2.1.224 -t <your-registry>/claude-runner:latest .

​

Размер CPU и памяти для сеансов

• Память: запрос и лимит 4 ГиБ каждый, что соответствует минимуму 4 ГБ в системных требованиях Claude Code. Держите их равными, чтобы планировщик учитывал полную память контейнера. Когда контейнер достигает своего лимита памяти, ядро убивает процессы внутри него, что может завершить сеанс в середине задачи.
• CPU: запрос 2 CPU и лимит 4 CPU, чтобы сеанс мог всплеснуть выше запроса во время сборок. Ядро дросселирует контейнер на его лимите CPU, а не убивает процессы в нем, поэтому сеансы на лимите работают медленнее, но продолжают работать.

resources:
  requests:
    cpu: "2"
    memory: 4Gi
  limits:
    cpu: "4"
    memory: 4Gi

• Один сеанс на runner: дайте каждому контейнеру значения одного сеанса. Используйте эту размер на --capacity 1, которую раздел усиления безопасности рекомендует, и для on-demand runners, где вы устанавливаете значения на рабочую нагрузку, которую ваш spawn-runner hook отправляет, такую как шаблон pod Kubernetes Job.
• Несколько сеансов на runner: на --capacity выше одного, умножьте значения одного сеанса на емкость, потому что до такого количества сеансов может работать в контейнере одновременно. Рецепты Kubernetes и Docker Compose запускают --capacity 4 без лимитов CPU или памяти, поэтому добавьте лимиты, размер которых соответствует емкости, которую вы запускаете.

​

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: claude-runner
  namespace: claude-runners
spec:
  replicas: 3
  selector:
    matchLabels:
      app: claude-runner
  template:
    metadata:
      labels:
        app: claude-runner
        app.kubernetes.io/part-of: claude-code-self-hosted-runner
    spec:
      terminationGracePeriodSeconds: 90
      containers:
        - name: runner
          image: <your-registry>/claude-runner:latest
          args:
            - self-hosted-runner
            - --environment-secret-file
            - /etc/claude/environment-secret
            - --capacity
            - "4"
          volumeMounts:
            - name: environment-secret
              mountPath: /etc/claude
              readOnly: true
          ports:
            - name: health
              containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 30
            periodSeconds: 30
      volumes:
        - name: environment-secret
          secret:
            secretName: claude-runner-environment-secret

kubectl create namespace claude-runners

kubectl create secret generic claude-runner-environment-secret -n claude-runners --from-file=environment-secret=./environment-secret

​

Docker Compose

services:
  claude-runner:
    image: <your-registry>/claude-runner:latest
    command:
      - self-hosted-runner
      - --environment-secret-file
      - /run/secrets/environment-secret
      - --capacity
      - "4"
    secrets:
      - environment-secret
    restart: always
    stop_grace_period: 90s

secrets:
  environment-secret:
    file: ./environment-secret

​

Время завершения работы

• С периодом grace SIGTERM: установите terminationGracePeriodSeconds на Kubernetes, stop_grace_period на Docker Compose или эквивалент вашего оркестратора по крайней мере на это общее время. Значение по умолчанию Kubernetes в 30 секунд короче, чем путь drain runner, поэтому Kubernetes останавливает pod до того, как runner завершит drain.
• С --retire-at: установите размер margin между временем retire и временем остановки хоста, чтобы охватить типичные turns, плюс background-task hold, который описывает Runner lifecycle, плюс то же самое общее время. Вычислите время retire при каждом запуске, например date +%s плюс предполагаемое время жизни runner.
• С --defer-shutdown-max-min: добавьте две дополнительные части к общему времени drain-path. Первая — это минуты, которые вы настраиваете. Вторая — это post-release grace, который описывает Defer the drain past the first signal, 75 секунд при значениях по умолчанию. Когда флаг установлен, runner также выводит объединённую цифру при запуске, после общего времени drain-path.

​

Defer the drain past the first signal

​

Что происходит с сессиями, которые runner удерживает после первого сигнала

• В течение первых n минут: runner обслуживает свои сессии нормально и продолжает применять --startup-timeout-min и --kill-session-after-min. Если вы также установили --release-idle-session-min, runner выпускает любую сессию, пользователь которой был неактивен столько времени; без этого неактивные сессии остаются на runner.
• Когда истекают n минут: runner выпускает каждую сессию, которую он всё ещё удерживает, неактивную или нет. Runner ждёт, пока turn сессии mid-turn завершится, и до 60 секунд больше для background tasks turn, прежде чем выпустить эту сессию.
• Когда истекает post-release grace: runner drain любые сессии, которые он всё ещё удерживает, и control plane переставляет каждую drained сессию на другой runner сразу же. Post-release grace начинается, когда истекают n минут, и составляет 75 секунд при значениях по умолчанию. Если вы установили --drain-wait-sec выше 60 секунд, post-release grace составляет --drain-wait-sec плюс 15 секунд вместо этого.

​

Установите timeout остановки

​

Что достигает работающего post-session hook

• SIGTERM пока runner уже drain: force-exits runner немедленно, пропуская всё, что остаётся от пути drain. Без --defer-shutdown-max-min, это второй SIGTERM, который получает runner. Ничто не сигнализирует работающему hook post-session, поэтому на голом хосте, где init процесс усыновляет orphans, он завершается самостоятельно, но без надзора: его бюджет timeout больше не применяется, и запись в закрытую трубу логов может убить его с SIGPIPE, поэтому hook, который должен пережить forced exit там, должен перенаправить свой собственный вывод в файл. В рецептах контейнеров на этой странице runner является PID 1 контейнера и его выход завершает контейнер, и при systemd по умолчанию KillMode=control-group cgroup-wide kill достигает hook тоже, как описывает запись Cgroup-wide kills; в обоих случаях рассматривайте forced exit как фатальный для hook и полагайтесь на период grace вместо этого.
• Process-group-wide signals, такие как kill -- -<pid> в скрипте-обёртке, shell job control или group-wide watchdog: достигают runner и subprocess mid-checkout-hook, который остаётся group-attached намеренно, но не mid-run hook post-session или дочерний процесс сессии.
• Cgroup-wide kills, такие как systemd по умолчанию KillMode=control-group или SIGKILL, который Kubernetes доставляет всему контейнеру, когда истекает terminationGracePeriodSeconds: достигают всего, включая hook. Изоляция process-group не защищает от этого, поэтому период grace должен охватывать полный путь drain.
• Собственный timeout hook: когда hook превышает --post-session-hook-timeout-sec, runner отправляет SIGTERM на всю группу процессов hook, затем SIGKILL две секунды спустя, поэтому worker, который fork hook, такой как tar, rsync или git, завершается с оболочкой-обёрткой вместо того, чтобы выжить как orphan. Надзор runner заканчивается, как только stdio hook закрывается: worker, который перенаправил свой собственный вывод в файл и пережил этап SIGTERM, находится вне досягаемости runner.

​

Держите базовый каталог и емкость идентичными на всех runners

​

Переиспользуйте pre-warmed checkout

• Клон в образе: постройте клон в образ runner на этом пути. Каждый свежий контейнер затем начинается с теплым клоном без переиспользования диска.
• Клон на постоянном томе: на runners, которые вы предварительно блокируете для учетной записи одного пользователя с --lock-to-account, укажите --base-dir на постоянный том, поэтому диск только когда-либо обслуживает эту учетную запись. Pre-locked runner никогда не подхватывает сеансы канала Claude Tag, поэтому этот вариант не применяется к runners, которые их обслуживают.

• Любая форма клона работает: полный, неглубокий или однозвездный клон на пути используется как есть. Runner никогда не передает --depth при получении в существующий клон, поэтому полный pre-warm держит свою полную историю и неглубокий остается неглубоким. CLAUDE_RUNNER_FETCH_DEPTH (full, 0 или число; по умолчанию 50) контролирует только холодный клон, который runner делает, когда клон еще не существует.
• Отслеживаемые изменения сбрасываются, неотслеживаемые файлы сохраняются: каждый сеанс начинается с жесткого сброса, который стирает предыдущие модификации сеанса, но runner никогда не запускает git clean, поэтому неотслеживаемые файлы из более ранних сеансов заблокированного владельца остаются в дереве.
• С git proxy, сброс становится checkout: с --use-anthropic-git-proxy, runner дезинфицирует .git/ клона перед каждым сеансом, сохраняя хранилище объектов, refs и неглубокое состояние, но удаляя индекс, поэтому каждый сеанс платит полный checkout рабочего дерева вместо почти мгновенного сброса; он все еще никогда не переклонирует. Pre-warms подмодулей не поддерживаются под proxy.
• Длинные клоны не нуждаются в обходном пути: runner ограничивает каждую операцию git с помощью 120-секундного наблюдателя без прогресса и 30-минутного жесткого лимита, а не плоского тайм-аута, поэтому медленный холодный клон, который продолжает сообщать о прогрессе, завершается.

​

Закрепите версию

• Чтобы держать флот на одной версии: постройте образ с закрепленной версией или на голом хосте установите конкретную версию и отключите auto-updates
• Чтобы обновить: установите более новую версию или пересоздайте образ, затем перезагрузите runners
• Плагины: рынки плагинов тоже не auto-update; установите FORCE_AUTOUPDATE_PLUGINS=1 в окружении runner, чтобы позволить плагинам auto-update, пока бинарный файл остается закрепленным

​

Масштабируйте флот

• Фиксированный флот: запустите статический набор реплик runner и масштабируйте на Prometheus metrics, которые обслуживает каждый runner
• On-demand runners: запустите подкоманду claude self-hosted-runner orchestrator, которая опрашивает Anthropic для сеансов, которые поставлены в очередь без доступного runner и вызывает ваш hook spawn-runner для загрузки одного на сеанс. См. On-demand runners.

​

Известные проблемы и ограничения

​

Трафик коннектора покидает вашу сеть

• https://api.anthropic.com/v2/ccr-sessions/*
• https://api.anthropic.com/v1/code/sessions/*
• https://api.anthropic.com/v1/code/mcp/*

​

Некоторые сеансы не считаются неактивными

• Если сеанс ждет своего пользователя, или его ход закончился и он держит только фоновые задачи, runner выпускает его сразу же. Сеанс возобновляется, когда его пользователь отправляет свое следующее сообщение.
• Если ход все еще работает, runner ждет, пока ход закончится, или пока сеанс не будет ждать своего пользователя, и затем выпускает его.
• Если сеанс все еще на runner, когда окно благодати истекает, runner завершает его, и любая работа работающего хода потеряна. Ход, ожидающий одобрения, запрошенного изнутри работающего вызова инструмента, - это один способ, которым сеанс переживает окно.

​

Дополнительные ограничения

• Возобновленные сеансы теряют неотправленную работу: когда сеанс выпущен или его runner перезагружен, и пользователь отправляет другое сообщение, сеанс возобновляется на свежем runner, который клонирует репозиторий снова с его начальной ветки, поэтому работа, которую сеанс не отправил, потеряна. Установите --push-outcome-on-release, чтобы runner сделал best-effort push веток результата сеанса перед выпуском, поэтому возобновленный сеанс начинается с этих коммитов вместо этого; это сохраняет подтвержденную работу, а не грязное рабочее дерево. Перед включением ограничьте, кто может push на claude/* refs на исходном удаленном, например с помощью набора правил ветки: при возобновлении runner получает ранее отправленную ветку без проверки, кто ее отправил, поэтому любой с доступом push на эти refs может поместить содержимое в возобновленное рабочее пространство. Runner также отбрасывает конфигурацию для каждого сеанса при возобновлении, означая каталог конфигурации Claude сеанса и любое состояние shell, которое сеанс написал; --push-outcome-on-release не охватывает это.
• Приватные репозитории не могут быть добавлены в середине сеанса: репозиторий, добавленный в сеанс после его запуска, не клонируется с учетными данными на самостоятельно размещаемом runner, поэтому добавление не удается. Выберите каждый репозиторий, который сеансу нужен, когда вы его создаете.
• Некоторые коннекторы не появляются в самостоятельно размещаемых сеансах: коннектор, который вы еще не подключили в параметрах claude.ai, не указан в самостоятельно размещаемом сеансе, и сеанс не будет вас приглашать подключить его. Подключите его в параметрах сначала, затем запустите свежий сеанс. Добавление коннектора в уже работающий сеанс тоже не делает его инструменты доступными для Claude; запустите свежий сеанс, чтобы подхватить недавно добавленный коннектор.

​

Сообщите о проблеме

​

Устранение неполадок

claude self-hosted-runner doctor

• Runner не появляется в окружении: подтвердите, что хост может достичь api.anthropic.com через HTTPS, секрет окружения текущий и часы хоста находятся в пределах пяти минут от реального времени; большее смещение вызывает отказ аутентификации. Runner регистрирует [runner:fatal] с причиной отказа при отказе аутентификации.
• Runner выходит при запуске с cannot create or write to base directory: runner не может создать или писать в --base-dir, который по умолчанию /workspace. Исправьте владение каталога или укажите --base-dir на записываемый путь, как описано в Keep the base directory and capacity identical across runners. Если runner вместо этого регистрирует [runner:fatal], говоря, что проверка базового каталога истекла по времени, каталог находится на зависшем монтировании NFS или CSI. Проверьте здоровье монтирования, а не разрешения. Runner печатает оба эти отказа при запуске в stderr перед открытием --log-file, поэтому ищите их в терминале или логах контейнера вашей платформы, а не в файле логов. До v2.1.225, runner не проверял базовый каталог при запуске, и эта неправильная конфигурация не удавалась сеансам после подхвата вместо этого.
• Сеансы остаются поставленными в очередь: каждый онлайн runner может быть заблокирован для другого владельца. Проверьте метрику claude_code_self_hosted_runner_locked_account каждого runner metric или поле locked_account его строки логов [runner:health], чтобы увидеть, кто его держит. Оба показывают email владельца только после того, как runner получил токен сеанса, несущий претензию act.email, которую сеансы агента Claude Tag никогда не делают. Без претензии runner не излучает серию locked_account и регистрирует locked_account=yes, что говорит вам, что runner заблокирован, но не для какого владельца. Добавьте реплики или ждите, пока существующий runner осушится и перезагрузится. Если окружение использует on-demand runners, проверьте оркестратор вместо этого; см. On-demand runners.
• Сеансы не удаются сразу после подхвата: откройте сеанс в claude.ai/code, чтобы увидеть ошибку. Наиболее распространенные причины - отсутствие git credentials в образе runner и инструменты сборки, которые не установлены. Неписываемый базовый каталог останавливает runner при запуске вместо того, чтобы не удавались сеансы. См. запись Runner exits at startup with cannot create or write to base directory в этом списке.
• Сеансы не могут достичь сеть через аутентифицирующий исходящий прокси: когда источник, который вы установили с помощью --proxy-authorization-command или --proxy-authorization-file, не удается, истекает по времени после 30 секунд или дает пустое значение, runner отвечает на это соединение 502 Bad Gateway и регистрирует почему. Runner редактирует stderr команды в этом логе и никогда не регистрирует значение заголовка. С --proxy-authorization-command, запустите команду самостоятельно на хосте, чтобы подтвердить, что она печатает все значение заголовка на stdout. Если runner вместо этого выходит при запуске с could not start the proxy-authorization listener, он не мог открыть свой слушатель loopback.
• Runner регистрирует строки Poll failed, содержащие rejecting the malformed poll response: runner получил ответ на опрос работы, чье тело не является ожидаемым JSON очереди, чаще всего потому что что-то между runner и api.anthropic.com, такое как перехватывающий прокси или captive portal, ответил своей собственной страницей. Runner отклоняет ответ, считает его под видом transport метрики claude_code_self_hosted_runner_poll_errors_total metric и повторяет попытку по расписанию отказа опроса, описанному в Session lifecycle. Runner продолжает обслуживать свои живые сеансы. Конфигурируйте прокси, чтобы пропустить ответы от api.anthropic.com без изменений. До v2.1.246, runner читал такой ответ как пустую очередь работы, которая могла закончить его живые сеансы или заставить его выйти.
• Ветка сеанса больше не существует на удаленном: для источника git, который сеанс только читает, runner пропускает этот источник и продолжает на оставшихся. Для источника, на который сеанс отправляет результаты, удаленная ветка, обычно потому что она была объединена и auto-deleted, не удается сеанс с ошибкой, называющей репозиторий и ветку и просящей вас восстановить ветку и повторить попытку. Runner не удается сеанс с той же ошибкой, когда пропуск оставил бы его без репозитория вообще. До v2.1.228, такой сеанс начинался в пустом каталоге.
• Сеансы занимают минуты для запуска: начальный клон обычно доминирует. Смотрите метрику claude_code_self_hosted_runner_session_init_duration_seconds metric, чтобы подтвердить, и сократите клон с помощью pre-warmed checkout или меньшего CLAUDE_RUNNER_FETCH_DEPTH.
• Pod убивается в середине осушения: поднимите terminationGracePeriodSeconds по крайней мере на значение, которое runner регистрирует при запуске. См. Shutdown timing.

​

Что дальше

• Customize sessions: скрипты-обертки, lifecycle hooks, on-demand runners, MCP servers и разрешения
• Test end to end: проверьте новый образ runner из CI перед продвижением
• Reference: каждый флаг CLI, переменная окружения и метрика