Многопользовательский сервер для работы команды с AI-агентом в терминале — OpenAI Codex CLI через VS Code Remote-SSH. Каждый разработчик подключается из своего редактора, а код, зависимости, контейнеры и сам агент живут на сервере, изолированно по пользователям.
Это не библиотека и не приложение. Это воспроизводимый рецепт эксплуатации: пошаговый runbook развёртывания на Ubuntu 24.04, ~30 серверных скриптов и — что важнее — объяснение, почему каждое решение принято именно таким. Почти каждая строка здесь появилась после конкретной аварии, и авария описана рядом.
Агент в терминале — это не «ещё один плагин». Он неделями держит контекст, качает зависимости, поднимает контейнеры, гоняет headless-браузер и на каждый прогон оставляет после себя мусор. На ноутбуке это терпимо, пока вы один. На команде начинается другое:
- Железо не тянет. Разнородные ноутбуки, у половины — не Linux, а агенту нужно и то и другое.
- Работа расползается. Исходники, наработанный контекст и артефакты оказываются на личных машинах: не бэкапятся, не передаются, теряются вместе с ноутбуком.
- Нет ни учёта, ни тормозов. Кто сколько потратил, чей процесс съел память, что крутилось ночью — неизвестно, пока не встанет работа у всех сразу.
Сервер снимает все три пункта разом: одна среда, один бэкап, один учёт.
Подходит: небольшая команда (до ~10 человек), интерактивная разработка, клиентские проекты и лёгкие веб-сервисы, потребность в изоляции и учёте.
Не подходит: билд-ферма. Профиль машины — интерактивная работа; тяжёлые нативные сборки одного человека способны положить отзывчивость остальным, и никакие лимиты этого до конца не лечат. Такие задачи выносите на отдельный воркер.
Изоляция пользователей. Домашние папки 700, rootless Docker вместо членства
в группе docker (оно равно root), песочница агента с ограничением записи. Общий
/tmp закрыт через umask — с оговоркой, которую мало кто замечает: обнулять
group-биты нельзя, иначе схлопнется ACL-маска и сломается сквозной доступ.
Лимиты памяти и CPU на человека. cgroup-профиль
MemoryHigh/MemoryMax/MemorySwapMax/CPUQuota для каждой учётки. Здесь же —
измеренная грабля, на которой легко потерять неделю: MemoryHigh делает
MemoryMax мёртвым кодом. Ядро держит потребление НА мягком пороге и до жёсткого
не доводит, поэтому OOM внутри клетки не срабатывает вовсе — за два месяца ноль
срабатываний при сотнях миллионов упоров в мягкий порог. И отдельно: ограничить
RAM без MemorySwapMax — значит выдавить процесс в общий swap и повесить машину
целиком при нулевых OOM-убийствах.
Бэкап. restic → S3: инкрементально, зашифрованно, с ретеншном и еженедельным
prune. Уезжают проекты, docker-тома, конфиги и накопленная память агента.
Мониторинг в Telegram. Ежечасная проверка и суточная сводка: диск, свежесть
бэкапа, OOM, службы и нагрузка — load, swap, залипание процессов на IO. В каждом
алерте имя виновника, вычисленное по cgroup-слайсу, а не безымянный chrome.
Анти-спам ключуется на класс проблемы, а не на её текст: иначе меняющийся процент
(«диск 87%» → «диск 90%») даёт новую сигнатуру, и алерт летит каждый час.
Уборщики, без которых диск умирает тихо. Три независимые протечки, каждая измерена на живом сервере:
| Что течёт | Сколько | Чем закрыто |
|---|---|---|
| Сборки VS Code Server, по ~700МБ | 37ГБ за два месяца на 7 учёток | codex-vscode-prune.sh |
| Профили Chrome от прогонов агента | ~1ГБ в сутки | codex-tmp-reaper.sh |
| Зависшая браузерная автоматика | процесс жил 15 дней, Xvfb — 28 | codex-hungjob-reaper.sh |
Каждый уборщик отказывается работать, если не может доказать, что удаляемое никому
не нужно: живость проверяется обходом /proc и списком юникс-сокетов (в
/proc/*/fd сокет виден как socket:[inode], а не как путь — на этом легко
снести живое), а профиль браузера опознаётся по содержимому, не по имени.
Учёт расхода. Веб-дашборд за Caddy с TLS и basic-auth: кто сколько потребляет, с разбивкой по проектам. Администратор видит имена, общий борд для сотрудников обезличен. История ведётся в отдельном ledger'е, поэтому чистка файлов сессий её не стирает.
Несколько аккаунтов провайдера (пулов лимита). Недельная квота считается на
аккаунт, а не на человека, поэтому команда выжигает её за считанные дни. Карта
codex-token-map.conf закрепляет людей за аккаунтами, codex-token-switch.sh
переводит человека или всю группу одной командой, codex-token-check.sh показывает,
у кого какой токен лежит фактически. Главное правило распределения неочевидно:
делить надо не поровну по головам, а по доле расхода, и самых тяжёлых
потребителей разводить по разным аккаунтам — типовая авария не «все понемногу
исчерпали пул», а «один человек выжег недельную квоту за сутки».
Обслуживание. Автообновления безопасности и перезагрузка только тогда, когда никто не работает.
У каждой страховки есть негативный тест. Защита, которую не пытались обмануть, неотличима от её отсутствия: обе молчат. Поэтому в репозитории лежат харнессы, которые не просто проверяют «сработало», а требуют, чтобы механизм покраснел на плохом входе и чтобы версия без защиты дыру пропустила:
codex-tmp-reaper-harness.sh— 16 проверок на канарейках в изолированном корне: каталог, который держит живой процесс или сокет, обязан выжить, а после снятия держателя — обязан быть удалён;codex-token-map-harness.sh— 23 проверки логики раздачи токенов, включая «аккаунт не подключён → человек уехал на резервный» и обратный контроль «аккаунт появился → уехал на свой»;codex-monitor-cgoom-harness.sh— проверка, что монитор вообще умеет заметить убийство процесса внутри лимита.
Написано, почему, а не только как. Отклонённые гипотезы сохранены рядом с принятыми решениями — чтобы вы не потратили день на путь, который уже оказался тупиком.
# 1. Развернуть сервер по шагам DEPLOYMENT.md (Ubuntu 24.04)
# 2. Завести сотрудника
codex-add-user.sh ivan # обычный, изолированный
codex-add-user.sh petr admin # второй администратор
# 3. Собрать комплект подключения из setup-new-pc/_templates/codex-add-user.sh создаёт учётку, настраивает изоляцию и rootless Docker,
выдаёт токен агента по карте аккаунтов и печатает приватный ключ для передачи
человеку. Комплект для его машины (Windows/macOS) собирается из шаблонов:
конфиг SSH, ключ, инструкция.
| Файл | Для чего |
|---|---|
| DEPLOYMENT.md | Развернуть с нуля — пошаговый runbook |
| DOCUMENTATION.md | Как устроено и почему: изоляция, лимиты, авторизация, бэкап, мониторинг, дашборд |
| server-scripts/ | Всё, что лежит в /usr/local/sbin/, /usr/local/lib/ и /etc/ |
| setup-new-pc/ | Шаблоны комплектов подключения для сотрудников |
Рецепт написан под OpenAI Codex CLI, но к самому агенту привязана только часть
про авторизацию. Изоляция, cgroup-лимиты, бэкап, мониторинг, уборщики диска и
дашборд одинаково работают для любого CLI-агента, который вы запускаете на
сервере через VS Code Remote-SSH, — включая Claude Code. Скрипты раздачи токена
(codex-auth-sync.sh, codex-reauth.sh, codex-token-*) специфичны для схемы с
общим аккаунтом ChatGPT; при персональных ключах они просто не нужны.
Тремя вещами, которые локально не решаются: бэкап всей работы в одном месте, учёт расхода по людям и проектам, и лимиты, из-за которых чужой тяжёлый процесс не отбирает у вас машину. Плюс общее окружение: «у меня не воспроизводится» перестаёт быть аргументом.
Отправная точка, на которой это отработало: 4 ядра, 8ГБ RAM, ~120ГБ диска на
7–9 человек интерактивной работы. Узкое место — не CPU, а память и диск:
один headless-браузер агента занимает ~2ГБ, а .vscode-server и /tmp
накапливают десятки гигабайт, если их не убирать (см. таблицу протечек выше).
Нет, если не дать им sudo и группу docker — любая из двух привилегий равна
root. Домашние папки 700, у каждого свой rootless-движок Docker, контейнеры
работают от его имени. Отдельно учтите: песочница агента ограничивает запись,
а не чтение, поэтому границы всё равно задаёт ОС, а не настройка агента.
Технически да, код для этой схемы здесь есть — мы так работали. Но прочитайте раздел «Ограничения» ниже: цена высокая, и она не техническая.
Проверялось на Ubuntu 24.04 (systemd 255). Всё, что касается cgroup-лимитов,
pam_umask, tmpfiles и rootless Docker, зависит от версии systemd — на других
системах перепроверяйте не документацию, а фактическое поведение:
systemctl show вместо «файл на месте».
Схема с общим аккаунтом провайдера опубликована как есть, но у неё высокая цена:
- Это, по всей вероятности, нарушает условия использования провайдера. Гарантий никаких: аккаунт может быть заблокирован в любой момент вместе с работой всей команды. Решение и ответственность — ваши.
- Общий лимит. Один человек способен выжечь недельную квоту команды за сутки, и остальные узнают об этом, когда работа встанет.
- Общая смерть токена. Отзыв или истечение останавливает всех сразу; до ручного восстановления команда простаивает.
- Веб-вход извне убивает сессию. Логин в тот же аккаунт из браузера с другого IP отзывает токен у всей команды.
Персональные учётки или API-ключи снимают все четыре пункта разом. Если идёте по общей схеме — несколько аккаунтов с картой закрепления (см. выше) снижают радиус аварии, но не отменяют первый пункт.
Все примеры обезличены: <SERVER_IP>, codex.example.com, логины ivan, petr
и другие условные. Подставьте свои.
В репозитории нет и не должно быть приватных ключей, паролей и токенов. На сервере они лежат так:
| Где | Что |
|---|---|
/etc/restic/env |
ключи S3 и пароль шифрования бэкапа |
/etc/telegram/env |
токен бота и chat_id для алертов |
/root/codex-usage-credentials.txt |
пароли логинов дашборда |
/etc/codex-usage-account.env |
токен сервиса смены паролей |
Пароль шифрования restic храните отдельно от сервера — без него копии не восстановить.
A multi-user server for running a terminal AI coding agent (OpenAI Codex CLI) with a team over VS Code Remote-SSH. Not a library — a reproducible operations recipe: a step-by-step Ubuntu 24.04 runbook, ~30 server scripts, and the reasoning behind every decision.
What you get: per-user isolation (700 homes, rootless Docker, agent sandbox),
per-user cgroup limits (MemoryHigh/MemoryMax/MemorySwapMax/CPUQuota),
encrypted incremental backups with restic to S3, hourly monitoring with Telegram
alerts that name the offending user via its cgroup slice, disk reapers for the
three leaks that actually kill the disk (VS Code Server builds, abandoned Chrome
profiles, hung browser automation), a per-user token-usage dashboard behind Caddy
with TLS and basic auth, and a map that pins people to several provider accounts
when one weekly quota is not enough.
What makes it different: every safety mechanism ships with a negative test. A guard nobody tried to fool is indistinguishable from no guard — both stay silent. The harnesses require the mechanism to fail loudly on bad input, and require the version without the guard to let the hole through.
The recipe targets Codex CLI, but only the authorization scripts are agent-specific; isolation, limits, backups, monitoring, reapers and the dashboard apply to any CLI agent you run on a server (Claude Code included). Read Ограничения / Limitations before adopting the shared-account scheme: it very likely violates the provider's terms of service, and one person can burn the team's weekly quota in a day.
Docs are in Russian: DEPLOYMENT.md to deploy from scratch, DOCUMENTATION.md for how and why it works.
MIT — см. LICENSE.
Материал предоставляется «как есть», без гарантий. Вы разворачиваете многопользовательский сервер с доступом к своему коду и данным: оцените риски под свою ситуацию и не переносите чужие решения не глядя.