claude-session-driver — плагин
Плагин превращает одну сессию Claude Code в руководителя, который раздает задачи воркерам в tmux и собирает их результаты.
- 114 ★ репозитория
- Последний коммит
- MIT
Широкий доступ
Почему такой уровень
- Воркеры запускаются с обходом подтверждений и выполняют команды и правки без вопросов.
- Для Codex и Pi в воркера копируется ваша авторизация.
Установка
- Работает в
Ручная установка
claude plugin install claude-session-driver@superpowers-marketplaceНужны tmux и CLI выбранной среды. Если кеш маркетплейса устарел, сначала `claude plugin marketplace update superpowers-marketplace`.
Доступ и проверки
Как мы проверяемШирокий доступИнструмент может менять данные, выполнять команды или работать с секретами.
- Воркеры запускаются с обходом подтверждений и выполняют команды и правки без вопросов.
- Для Codex и Pi в воркера копируется ваша авторизация.
Это чужой код. Посмотрите файлы в репозитории перед установкой.
Что делает
Плагин добавляет CLI `csd` и скилл `driving-claude-code-sessions`. Главная сессия запускает воркеров в tmux: Claude Code, Codex или Pi, дает каждому задачу, следит за ходом работы и забирает ответы. Воркеры работают параллельно, а что делать с их результатами, решает руководитель. Каждый воркер пишет события жизненного цикла в JSONL: старт сессии, отправленный запрос, вызовы инструментов с именем и входными данными, остановку. Набор команд одинаков для всех трех сред: `launch`, `send`, `converse`, `wait-for-turn`, `read-turn`, `read-events`, `status`, `stop`, `handoff`. Скилл описывает схемы: передать и дождаться, раздать веером, выстроить конвейер, вести диалог с воркером, отдать сессию человеку.
Для кого. Разработчикам, которые гоняют несколько сессий кодинг-агентов сразу и хотят управлять ими из одной главной сессии.
Подходит, если
- Три независимые задачи в разных каталогах идут параллельно, и главная сессия ждет все три.
- Результат одного воркера служит входом для следующего в цепочке.
- Рабочую сессию на середине надо передать человеку в tmux.
- После перезагрузки машины воркеров возвращают скриптом `recover-workers.sh`.
Не подходит, если
- Задача укладывается в один сеанс без параллелизма.
- Нельзя запускать агентов с отключенными подтверждениями.
- На машине нет tmux.
Пример запроса к агенту
Запусти двух воркеров: один пусть обновит тесты в каталоге api, другой напишет миграцию в каталоге db, и дождись обоих.Ограничения
Нужны tmux и CLI хотя бы одной среды: `claude`, `codex` или `pi`; node входит в Claude Code. Воркеры стартуют с обходом подтверждений и выполняют вызовы инструментов без вопросов, а события лишь наблюдаются и ничего не блокируют. Перед первым запуском проходят единоразовое согласие `csd grant-consent`. Для Codex и Pi плагин копирует в воркера вашу авторизацию из `~/.codex` и `~/.pi/agent`. Команда `adopt` работает только с Claude.
Как отключить. Удалите плагин командой Claude Code, остановите воркеров через `stop` и очистите каталог `/tmp/csd-workers`.
Частые вопросы
Как поставить claude-session-driver?
Выполните `claude plugin install claude-session-driver@superpowers-marketplace`. Если кеш каталога старый, сначала `claude plugin marketplace update superpowers-marketplace`.
Как запустить воркера на Codex?
Передайте флаг: `csd launch --harness codex my-task /path/to/project`. По умолчанию берется `claude`, третий вариант: `pi`.
Как забрать ответ воркера?
Вызовите `read-turn` для последнего хода или `converse`, чтобы отправить запрос и сразу получить ответ. События смотрят через `read-events`.
Что нужно для работы плагина?
Нужны tmux и CLI хотя бы одной среды: `claude`, `codex` или `pi`. Отдельно ставить `jq` не требуется.
Куда пишутся события воркеров?
В файл JSONL: старт сессии, отправленный запрос, вызовы инструментов, остановка и конец сессии. Путь выводит команда `events-file`.
Обсуждение
Вопросов и отзывов пока нет.
Похожие
ПлагиныОркестрация нескольких агентов для Claude Code: команды, роли, автопилот и распределение задач между скиллами и субагентами
Рабочие процессы для Claude Code: команды /do, /omo, /bmad-pilot и другие, а код пишут Codex, Gemini или OpenCode через codeagent-wrapper
Плагин Claude Code поручает кодинг-задачи агентам Codex, следит за их работой и проверяет результат независимо
Терминальное приложение для параллельной работы нескольких Claude Code, Codex, Gemini CLI и Aider в отдельных сессиях tmux и git worktree
Среда для Claude Code, которая держит контекст между сессиями через хуки, леджеры и передачи, оркеструет агентов и экономит токены
claude-mods ставит в Claude Code 112 скиллов, 3 агента и 3 команды: стеки, запуск агентов, защита, непрерывность сессий.
Коротко о README
Плагин ставится через маркетплейс Claude Code. Дальше управление идет единственным бинарным файлом `csd` и шимами `/tmp/csd-workers/bin/<имя>`, а хуки написаны на node.
Бейдж для README
Исходный SKILL.md
--- name: driving-claude-code-sessions description: Use when acting as a project manager that delegates tasks to other coding-agent sessions (Claude Code, Codex, or Pi) - launch workers, assign them work, monitor progress, review their tool calls, and collect results --- # Driving Coding-Agent Sessions ## Overview You can launch coding-agent sessions — Claude Code, Codex, or Pi — as "workers" in tmux, send them prompts, wait for them to finish, read their output, and hand them off to a human. Workers run with permissions bypassed, so they execute tool calls without prompting. Each worker emits lifecycle events to a JSONL file so the controller can observe what it's doing — Claude and Codex through their hook systems, Pi through a native extension `csd` loads into it. All operations go through a single CLI: `csd`. After launching a worker, the controller receives a **shim path** at `/tmp/csd-workers/bin/<tmux-name>` that bakes in the worker handle. Every per-worker operation goes through that path — no positional state to thread between calls, no absolute skill path to prepend. A small set of environment variables tune behavior; see [Environment variables](#environment-variables) at the bottom. (The worker dir moved from `/tmp/claude-workers` to `/tmp/csd-workers`; when the default path is in use, `csd` creates a back-compat symlink `/tmp/claude-workers → /tmp/csd-workers`, so old paths and muscle memory still resolve.) The shim path is deterministic: if you pick a memorable tmux name at launch, you can reconstruct `/tmp/csd-workers/bin/<tmux-name>` whenever you need it. For agents driving via tool calls, that's the right model — shell state doesn't persist between calls, so a `SHIM=...; $SHIM cmd` pattern just adds noise. The examples below use the bare path. ## Harnesses Pick a harness with `--harness` at launch (default `claude`): ```bash $SKILL/csd launch --harness codex my-task /path/to/project $SKILL/csd launch --harness pi my-task /path/to/project ``` The controller-facing command surface is **identical across all three harnesses** — `launch`, `send`, `converse`, `wait-for-turn`, `read-turn`, `read-events`, `status`, `stop`, and `handoff` behave the same regardless of harness. A few things differ: - **Auth.** Each harness authenticates from its own home — Claude `~/.claude`, Codex `~/.codex`, Pi `~/.pi/agent`. `csd` stages that login into the worker at launch, so to rotate credentials, relaunch. - **`adopt` is Claude-only.** Claude takes a caller-assigned session id, so a session can be resumed by id (`claude --resume`). Codex and Pi mint their own ids on the first prompt and offer no resume-by-id — relaunch them instead. - **Codex isn't queryable until its first prompt.** Codex mints its session id only when you send the first prompt, so between `launch` and the first `send`/`converse` a codex worker's `status`, `session-id`, and `wait-for-turn` return `no worker known` — it *is* running, it just hasn't registered yet. `converse` handles this internally, so the typical launch→converse path is fine; only the lower-level commands see the gap. (Claude takes its id at launch and Pi registers at launch, so both are queryable immediately.) ## Prerequisites - **tmux** - a harness CLI — at least the one you launch: **claude** (default), **codex**, or **pi** (No `jq` and no bash hooks: `csd` is a TypeScript/node tool and its hooks are node programs. `node` is required, but it's already present wherever Claude Code runs.) ## Setup The CLI lives at `<skill>/scripts/csd`. Top-level subcommands need the skill path: - `csd launch [--harness <claude|codex|pi>] <tmux-name> <cwd> [-- harness-args...]` — bootstrap a worker (harness defaults to `claude`) - `csd adopt <tmux-name> <cwd> <session-id> [-- claude-args...]` — re-adopt an existing Claude session as a worker (claude-only; see [Recovering workers](#recovering-workers-after-a-reboot)) - `csd list [--all]` — enumerate workers - `csd grant-consent` — one-time consent for running workers with permissions bypassed Once a worker is launched, run subsequent commands against `/tmp/csd-workers/bin/<tmux-name>`: