Запуск Claude Code с Olivares (совместное развёртывание)

Это половина Operate (управление выполнением) истории Anthropic-first: не просто наблюдать и регулировать Claude Code, но и дирижировать им. Control plane запускает реальный процесс claude, направляет его ввод-вывод в управляемый поток, закрепляет каждый переход жизненного цикла в аудит-журнале и завершает его — поверх общей рабочей области, из API/CLI (а позднее — и из портала), без SSH. Эта страница совместно развёртывает обе половины на одном Linux-хосте в четырёх топологиях, безопасно по умолчанию.

Про путь кооперативного наблюдения (телеметрия OTLP → access map) см. Подключение Claude Code; про путь регулирования (хуки PreToolUse как PEP) см. пример govern-claude-code. Эта страница — про совместное развёртывание: про совместный запуск двух сред выполнения.

Сессия управляема, потому что движок владеет stdin/stdout процесса claude — это безголовый (headless) транспорт stream-json. Движок порождает claude как дочерний процесс (нативный procRunner) и мостит каждый кадр NDJSON. Это работает только тогда, когда движок и claude разделяют контекст выполнения (один и тот же хост или один и тот же контейнер). Рекомендуемые топологии размещают их вместе именно по этой причине; смешанные топологии и их честные ограничения — ниже.

Два принципа перед началом

Подключение по выбору (opt-in). Базовый образ Olivares — distroless и не несёт claude. Слой Operate-Claude-Code — это отдельный артефакт: комбинированный образ (Dockerfile.agentops) или дополнение к нативной установке. Если вы не запускаете управляемый Claude Code, вы его никогда не скачиваете, и его дополнительная поверхность никогда не касается вашего control plane.
Официальный источник, никогда не перераспространяемый. Условия Anthropic не разрешают перераспространять бинарник claude, поэтому мы устанавливаем его из официального, GPG-подписанного источника Anthropic при сборке/первом запуске (подписанные репозитории apt/dnf/apk), с закреплённой версией и отключённым автообновлением. Мы не поставляем стороннего бинарника. Вы также можете принести свой собственный claude и указать движку на него.

Четыре топологии вкратце

#	Olivares	Claude Code	Как движок дирижирует им	Статус
1	Docker	Docker	Тот же контейнер (комбинированный образ), дочерний procRunner	Рекомендуется (тот же управляемый путь, что и 2)
2	Нативно	Нативно	Тот же хост (systemd), дочерний procRunner	Рекомендуется, проверено сквозным smoke-тестом
3	Docker	Нативно (хост)	Меж-namespace — не управляемо как есть	Размещайте вместе (см. ниже)
4	Нативно	Docker (на каждую сессию)	Контейнер на сессию через Docker API	Последующая работа (документировано)

Две совместно размещённые топологии (1, 2) — это безопасный вариант по умолчанию. Топология 2 (нативная) проверяется сквозным тестом scripts/smoke-agentops.sh; топология 1 переиспользует тот же управляемый путь procRunner (сборка/запуск комбинированного образа пока не подключены к автоматизированному тесту). Топологии 3 и 4 хотят разместить дирижёра и управляемого в разных контейнерах; мостирование stdio через эту границу требует доступа к Docker API (привилегия, которую движок намеренно не берёт по умолчанию). Их честные пути изложены в Смешанных топологиях.

Топология 1 — обе в Docker (рекомендуется)

Один укреплённый контейнер запускает движок и claude; том рабочей области — это общий рабочий каталог. Только loopback, не от root, корневая ФС только для чтения — идентичная posture базовому compose, плюс дирижируемая среда выполнения.

Сборка комбинированного образа

claude устанавливается во время сборки из подписанного apt-репозитория Anthropic, с закреплённым отпечатком ключа подписи (31DD DE24 DDFA B679 F42D 7BD2 BAA9 29FF 1A7E CACE) и отключённым автообновлением. Закрепите базовый образ движка по digest и сначала проверьте его:

# verify the engine image you build FROM (it is cosign-signed)
cosign verify docker.io/olivaresai/olivares:26.8.0 \
  --certificate-identity-regexp '^https://github\.com/olivaresai/olivares/\.github/workflows/release\.yml@refs/tags/v[0-9]+\.[0-9]+\.[0-9]+$' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

docker build -f Dockerfile.agentops \
  --build-arg OLIVARES_IMAGE=docker.io/olivaresai/olivares@sha256:<digest> \
  --build-arg CLAUDE_CHANNEL=stable \
  -t olivares-agentops:26.8.0 .

Используйте свой собственный claude через --build-arg CLAUDE_INSTALL=byo (образ поставляется без claude; смонтируйте свой во время выполнения и задайте OLIVARES_SESSION_RUNTIME_CLAUDE_BIN).

Запуск

export OLIVARES_AGENTOPS_IMAGE=olivares-agentops:26.8.0
docker compose -f deploy/compose/docker-compose.yml \
               -f deploy/compose/docker-compose.agentops.yml up -d

Переопределение меняет только то, что нужно Operate: комбинированный образ, четыре записываемых тома (данные движка, рабочая область, домашний каталог ~/.claude процесса claude, краткоживущий токен вывода) и env среды выполнения сессий. Всё остальное — порты, привязанные к 127.0.0.1, uid 65532, корень read_only, cap_drop: ALL, no-new-privileges — наследуется от базы.

Источник учётных данных закрыт по умолчанию (deny-closed): запуск stream-json читает краткоживущий bearer-токен из OLIVARES_SESSION_RUNTIME_TOKEN_FILE (/run/olivares/session-token, на томе olivares-runtime) и отбрасывает его — хранится только нечувствительный credential_id. Направьте свой обновитель WIF/SPIFFE/OIDC на этот том. Пока токена нет, запуски stream-json падают закрыто (closed) — движок всё равно работает и в остальном управляем; подключение аутентификации — ваш осознанный шаг. (Живой внутрипроцессный обмен токенами реализован отдельно.)

Топология 2 — обе нативно (без Docker)

Движок и claude на хосте; systemd запускает движок, который дирижирует claude. Рабочая область располагается в /var/lib/olivares/workspaces.

Одна команда

curl -fsSL https://raw.githubusercontent.com/olivaresai/olivares/main/scripts/install-agentops.sh | sh

Скрипт автоматически определяет нативную топологию, устанавливает проверенный бинарник движка (защищённый cosign install.sh), устанавливает claude из подписанного репозитория apt/dnf/apk (с проверкой отпечатка ключа — или OLIVARES_CLAUDE_INSTALL=byo, чтобы пропустить), создаёт сервисного пользователя olivares без входа и каталог рабочей области, и добавляет укреплённое переопределение systemd + пример env. Он не запускает автоматически плоскость управления — запуск её — это ваше явное решение.

Что настраивает установщик (и почему)

packaging/systemd/olivares.service.d/agentops.conf — drop-in, который даёт дирижируемому claude записываемый HOME для ~/.claude (держится под /var/lib/olivares, так что ProtectHome=true всё ещё защищает реальных пользователей), гарантирует существование каталога рабочей области и снимает ровно одно свойство песочницы: MemoryDenyWriteExecute (среда выполнения claude JIT-компилирует и нуждается в памяти W→X). Каждая другая директива укрепления из базового юнита остаётся в силе.
/etc/olivares/agentops.env — конфигурация среды выполнения сессий (файл токена, TTL, опциональный базовый URL шлюза, опциональный путь к собственному claude).

Затем, осознанно:

sudo nano /etc/olivares/agentops.env     # wire the short-lived inference token (refresher)
sudo systemctl enable --now olivares     # loopback-only by default

Запуск первой управляемой сессии

Те же шаги в любой совместно размещённой топологии. Аутентифицируйте CLI, зарегистрируйте общую рабочую область, запустите:

export OLIVARES_SERVER_URL=https://127.0.0.1:8443
export OLIVARES_TOKEN=<your-api-token>
export OLIVARES_TENANT=<your-tenant-id>

# 1) register the shared workspace (the session's working dir; jailed file API on top)
olivares agent workspace add /var/lib/olivares/workspaces/project-x --name project-x --mode rw

# 2) launch a governed session over the stream-json transport
olivares agent session create --transport stream-json \
  --permission-mode acceptEdits --model opus \
  --workspace <workspace-ref> --isolation native

# 3) attach to its live, bridged I/O (lossless replay from a cursor); send input; stop
olivares agent session attach <run-ref>
olivares agent session input  <run-ref> --line '{"type":"user","message":{"role":"user","content":"…"}}'
olivares agent session stop   <run-ref>

Каждый переход (created → launched → … → stopped) закрепляется в подписанном аудит-журнале (olivares agent session events <run-ref>); файловый API рабочей области (olivares agent workspace files|get|put|…) изолирован (jailed) и фиксируется в аудите. Контракт воспроизводимости для всего этого — scripts/smoke-agentops.sh, который поднимает нативное совместное развёртывание против герметичного поддельного claude и утверждает, что сессия управляема от начала до конца.

В этом релизе функциональна только --isolation native

--isolation container и --isolation sandbox — это значения шва прямой совместимости (forward-compatibility), пока не подключённые (Runner контейнера на сессию — это документированная последующая работа в Топологии 4). Нативный runner отказывается от запуска container/sandbox (с ясной ошибкой), а не молча запускает claude без запрошенной вами изоляции. Используйте native — под совместным развёртыванием комбинированного образа / systemd это собственная укреплённая граница контейнера/хоста движка.

Смешанные топологии (3 и 4)

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

Топология 3 — Olivares в Docker, Claude на хосте

Чистого управляемого пути нет: контейнеризованный движок не может владеть stdio процесса в namespace’ах хоста, а управляемый транспорт — это stdio. Достижение хостового claude потребовало бы разделения PID-namespace хоста и монтирования в контейнер движка — большая, осознанная деизоляция, которая сводит на нет смысл контейнеризации движка. Размещайте вместе: запустите обе в комбинированном образе (это и есть топология 1) или запустите обе нативно (топология 2). Это реальное ограничение, заявленное, а не замазанное.

Топология 4 — Olivares нативно, Claude в контейнере на сессию

Это естественный дом для изоляции в свежем контейнере на каждую сессию: каждая сессия получает совершенно новый укреплённый контейнер claude (рабочая область смонтирована через bind, корень только для чтения, не от root, cap-drop), создаваемый и завершаемый движком через Docker API, со stdio, смостированным через Docker attach/hijack. Шов модели данных уже моделирует это (--isolation container — допустимое значение, а примитив монтирования исполнителя, который он будет потреблять, уже поставлен) — но runner за ним пока не подключён, поэтому нативный runner сегодня отказывает в этом значении (см. примечание выше).

Это документированная последующая работа, не поставленная в этом релизе. Управление братскими (sibling) контейнерами означает предоставление движку доступа к Docker API (в идеале через прокси-сокет с минимальными привилегиями) — поверхность доверия, которую этот релиз намеренно избегает в пользу комбинированного образа без сокета. Выбор этой топологии — это выбор более сильной изоляции дирижёр/управляемый ценой этого гранта Docker API; она прибудет за существующим швом isolation=container. До тех пор безопасный вариант по умолчанию — совместное размещение.

Безопасность (все топологии)

Loopback по умолчанию. Порты хоста публикуются только на 127.0.0.1. В контейнере движок слушает на 0.0.0.0 внутри контейнера, поэтому отображение порта хоста — это граница раскрытия — никогда не публикуйте его на не-loopback адресе хоста без собственного прокси аутентификации с терминацией TLS. Нативная/systemd привязка по умолчанию — loopback. Раскрывайте осознанно.
Не от root, минимальные привилегии. uid/gid 65532, корневая ФС только для чтения, cap_drop: ALL, no-new-privileges (Docker) / полный набор Protect*/Restrict* минус единственное документированное послабление W^X (systemd).
Минимум данных, env с allowlist. Дочерний claude наследует только явный allowlist (PATH, HOME, локаль…) плюс токен вывода в памяти — никаких ключей подписи OLIVARES_*, никаких окружающих ANTHROPIC_*/CLAUDE_CODE_*, которые могли бы затенить созданный учётный данные.
Проверенная цепочка поставок. Движок подписан cosign (проверьте его / закрепите по digest); claude устанавливается из подписанных репозиториев Anthropic с закреплённым отпечатком ключа. Установщик отказывается запускать непроверенный движок, если вы явно не откажетесь от проверки.
Закреплённый аудит. Каждый переход жизненного цикла и каждая мутация рабочей области запечатываются в hash-chained, подписанный журнал через PayloadHash — байты файлов и содержимое кадров никогда не сохраняются.

Смотрите также

Подключение Claude Code — путь кооперативного наблюдения.
Безопасность и укрепление — базовая posture движка.
Проверка релиза — проверка cosign / SBOM / SLSA.
INSTALL.md — матрица установки, включая это совместное развёртывание.