OpenCode на сервере: как заставить ИИ-агента работать, пока вы спите

Знакомая история: запустили ИИ-агента в терминале, он завис на самом интересном месте, а потом вы закрыли ноутбук, и вся сессия пропала. Claude Code и Codex закрыты и заточены под модели своих авторов. OpenCode, open-source harness, этого лишён: он работает с любым провайдером, а главное, его можно поселить на сервере.

Почему это вообще возможно

Под капотом у OpenCode клиент-серверная схема. TUI общается с локальным HTTP-сервером, который публикует OpenAPI-спецификацию на эндпоинте /doc. Команда opencode serve поднимает тот же сервер без интерфейса. По умолчанию он слушает 127.0.0.1:4096, адрес и порт меняются флагами --hostname и --port. К нему можно обращаться из CI, из cron или из другого скрипта, а ещё держать его прогретым, чтобы не платить за холодный старт MCP и LSP.

Если сервер доступен не только с localhost, обязательно задайте OPENCODE_SERVER_PASSWORD. Включится HTTP basic auth, имя пользователя по умолчанию opencode. Одного пароля мало: поставьте сервер за nginx или Caddy с HTTPS, иначе basic auth по открытому HTTP защищает только от случайного сканирования.

Где это пригодится

Самый простой сценарий — CI/CD и ревью пул-реквестов. Через GitHub-приложение достаточно упомянуть /opencode или /oc в комментарии, и агент стартует в GitHub Actions runner, прочитает контекст и при необходимости откроет PR с исправлением. Без приложения в workflow пишется шаг с opencode run --standalone: в CI нет запущенного TUI, и команда сама поднимет приватный сервер под задачу. Вывод моделей недетерминирован, так что оценки по шкале поручать агенту не стоит, а для ревью он вполне подходит.

Второй сценарий — ночные задачи. Плагин opencode-scheduler использует launchd на macOS и systemd на Linux, с запасным вариантом на cron. Ежедневный аудит зависимостей или отчёт по git log вешается на расписание и забывается. Третий — общий сервер для команды: IDE-плагины, веб-интерфейс или Telegram-мост подключаются к одному процессу и видят одни и те же сессии.

Systemd или Docker

На чистом VPS хватит systemd-юнита с командой opencode serve. Главная ловушка — PATH. Сервисы systemd не наследуют PATH вашей оболочки, поэтому не находится не только сам OpenCode, но и всё, что агент вызывает через bash: git, node, rg, make. Задайте Environment=PATH=... и HOME явно.

Docker даёт изоляцию файловой системы и повторяемость. Фиксируйте конкретную версию образа, монтируйте workspace отдельным volume, конфиги и сессии — ещё одним. Но это страховка от случайного rm, а не от целенаправленного побега.

Права, провайдеры, безопасность

Провайдер подключается через @ai-sdk/openai-compatible: подойдёт любой совместимый эндпоинт, от локальной Ollama до облачного шлюза. В статье в примере используется BotHub, который является спонсором материала. API-ключ лучше не хранить в конфиге, а положить через opencode auth login. Для служебных задач вроде заголовков сессий задайте дешёвую small_model.

На сервере нельзя оставлять правило ask: opencode serve может часами ждать ответа, которого не будет. Используйте точечные allow поверх deny или флаг --auto, который превращает ask в allow, но сохраняет deny.

Самое важное: в SECURITY.md прямо сказано, что OpenCode не песочница, а система разрешений — только UX. Внешние MCP-серверы лежат вне границы доверия, и недавний случай с вредоносным MCP, выполнявшим код через OAuth, это подтвердил. Отдельная боль — Bun: он нестабильно читает HTTP_PROXY, не понимает socks5://, и без NO_PROXY для localhost агент может зациклиться на собственных запросах.

Мониторинг и вывод

Есть health-check /global/health, логи в journald или Docker, а плагин opencode-otel отправляет трейсы в Jaeger, Grafana Tempo, Datadog или Langfuse. Для CI удобен opencode run --format json. Следите за расходом токенов: ночью агент работает без присмотра.

Практический вывод: поднять агента на сервере — дело одного вечера, а настоящая работа начинается потом. Изоляция, HTTPS, строгие права и наблюдаемость обязательны. Лучше всего он работает там, где встроен в процесс: ночные аудиты, ревью PR. В продакшен ему лучше не давать доступа, пусть готовит PR, а кнопку нажимаете вы.