Запуск 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. Эта страница — про совместное развёртывание: про совместный запуск двух сред выполнения. Чтобы запустить Claude, Codex или Grok под профилем провайдера, когда среды уже есть, см. Управлять сеансом провайдера.

Как управление на самом деле достигает сессии

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

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

1. Подключение по выбору (opt-in). Образ Olivares не несёт claude. В Docker Olivares устанавливает инструменты агентов в свой том данных и подключает их через продукт, когда вы их запрашиваете; при нативной установке это делает дополнение к установке ниже. Если вы не запускаете управляемый Claude Code, ничего не устанавливается.
2. Официальный источник, никогда не перераспространяемый. Условия Anthropic не разрешают перераспространять бинарник claude, поэтому мы устанавливаем его из официального, GPG-подписанного источника Anthropic при установке (нативно — подписанные репозитории apt/dnf/apk; в образе — подписанный релиз Anthropic, проверенный тем же ключом), с закреплённой версией и отключённым автообновлением. Мы не поставляем стороннего бинарника. Вы также можете принести свой собственный 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, а CI запускает проверку среды агентов образа (scripts/qualify-container-agent-runtime.sh). Топологии 3 и 4 хотят разместить дирижёра и управляемого в разных контейнерах; мостирование stdio через эту границу требует доступа к Docker API (привилегия, которую движок намеренно не берёт по умолчанию). Их честные пути изложены в Смешанных топологиях.

---

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

Стандартный контейнер движка запускает и claude: Olivares устанавливает инструменты агентов в свой том данных и подключает их через продукт. Не-root, корневая файловая система только для чтения — та же позиция, что у базового compose, без второго образа и без файла переопределения.

Запуск

Закрепите движок по digest и сначала проверьте его:

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

export OLIVARES_IMAGE=docker.io/olivaresai/olivares@sha256:<digest>
export OLIVARES_BIND=127.0.0.1
docker compose -f deploy/compose/docker-compose.yml up -d

Установка и вход в Claude Code

Через Инструменты ИИ в консоли или с помощью CLI:

olivares tool install claude
olivares tool login claude

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

---

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

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

Скачать, проверить, затем запустить

Не передавайте установщик в оболочку через конвейер. Проверьте подписанный список контрольных сумм релиза, извлеките ровно тот коммит, который в нём указан, и запустите установщик из этой копии. Тогда install.sh и файлы упаковки берутся из копии, а не из ветки. Блок выполняется в подоболочке с set -eu: он останавливается на первом неудачном шаге и не запускает установщик после неудачной проверки.

(
set -eu
cd "$(mktemp -d)"
ver=0.4
base=https://github.com/olivaresai/olivares/releases/download/$ver
curl -fsSLO $base/checksums.txt
curl -fsSLO $base/checksums.txt.sig
curl -fsSLO $base/checksums.txt.pem
curl -fsSLO $base/release-commit.txt
cosign verify-blob \
  --certificate checksums.txt.pem --signature checksums.txt.sig \
  --certificate-identity "https://github.com/olivaresai/olivares/.github/workflows/release.yml@refs/tags/$ver" \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  checksums.txt
grep ' release-commit.txt$' checksums.txt | sha256sum --check
git clone https://github.com/olivaresai/olivares.git
cd olivares && git checkout --detach "$(cat ../release-commit.txt)"
OLIVARES_TOPOLOGY=native OLIVARES_VERSION=$ver sh scripts/install-agentops.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), гарантирует существование каталога рабочей области и повторяет политику файловой системы базового юнита: ProtectSystem=full, ProtectHome=false, PrivateTmp=false и MemoryDenyWriteExecute=false (среда выполнения claude JIT-компилирует и нуждается в памяти W→X). Домашние каталоги и /tmp остаются видимыми для движка, чтобы выбранные папки были доступны; claude каждой сессии и его stdio-серверы MCP вместо этого работают под изоляцией Landlock продукта на уровне папки. Каждая другая директива укрепления из базового юнита остаётся в силе.
• /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     # listens on every interface by default

Почему нет отдельного сервиса claude

Долго работающий демон claude вывел бы свои stdin/stdout за пределы досягаемости движка — а управляемый транспорт и есть stdio. Поэтому движок сам запускает и владеет процессом claude; «юнит среды выполнения» — это собственный сервис движка, настроенный на роль Operate с помощью drop-in.

---

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

Те же шаги в любой совместно размещённой топологии. Аутентифицируйте 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 это собственная укреплённая граница контейнера/хоста движка.

bypassPermissions место — за управлением (governance)

Запуск claude в безголовом режиме с разрешительным --permission-mode (bypassPermissions, dontAsk) — это именно тот случай, когда вам нужна плоскость управления. Среда движка с allowlist никогда не утекает секрет OLIVARES_*/ANTHROPIC_* агенту, а PEP PreToolUse / бюджет / kill-switch решают, что сессии на самом деле дозволено делать.

---

Смешанные топологии (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. До тех пор безопасный вариант по умолчанию — совместное размещение.

---

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

• Опубликованные порты. Docker Compose по умолчанию публикует HTTPS и gRPC на всех интерфейсах хоста (0.0.0.0). Установите OLIVARES_BIND=127.0.0.1, как в команде выше, чтобы ограничить доступ этим хостом. Движок слушает 0.0.0.0 внутри контейнера; публикация портов хоста определяет доступность. Нативные/systemd слушатели тоже по умолчанию используют все интерфейсы; настройте их адреса для ограничения доступа.
• Не от root, минимальные привилегии. uid/gid 65532, корневая ФС только для чтения, cap_drop: ALL, no-new-privileges (Docker) / директивы ядра и пространств имён Protect*/Restrict*; домашние каталоги и /tmp остаются видимыми, W^X разрешён, а каждая сессия изолирована в своей папке через Landlock (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 — матрица установки, включая это совместное развёртывание.