claude-session-driver — плагин

Плагин превращает одну сессию Claude Code в руководителя, который раздает задачи воркерам в tmux и собирает их результаты.

  • 114 ★ репозитория
  • Последний коммит
  • MIT
Плагин

Широкий доступ

Почему такой уровень

  • Воркеры запускаются с обходом подтверждений и выполняют команды и правки без вопросов.
  • Для Codex и Pi в воркера копируется ваша авторизация.
Все причины и проверки

obra/claude-session-driver

Установка

Работает в

Ручная установка

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: команды, роли, автопилот и распределение задач между скиллами и субагентами

ПлагинШирокий доступ40,8 тыс.Звезды репозитория

Рабочие процессы для Claude Code: команды /do, /omo, /bmad-pilot и другие, а код пишут Codex, Gemini или OpenCode через codeagent-wrapper

ПлагинШирокий доступ2,8 тыс.Звезды репозитория

Плагин Claude Code поручает кодинг-задачи агентам Codex, следит за их работой и проверяет результат независимо

ПлагинШирокий доступ92Звезды репозитория

Терминальное приложение для параллельной работы нескольких Claude Code, Codex, Gemini CLI и Aider в отдельных сессиях tmux и git worktree

CLIШирокий доступ8,8 тыс.Звезды репозитория
Нужен VPN

Среда для Claude Code, которая держит контекст между сессиями через хуки, леджеры и передачи, оркеструет агентов и экономит токены

ВоркфлоуШирокий доступ3,9 тыс.Звезды репозитория

claude-mods ставит в Claude Code 112 скиллов, 3 агента и 3 команды: стеки, запуск агентов, защита, непрерывность сессий.

ПлагинШирокий доступ81Звезды репозитория

Коротко о 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>`:

Сообщить о проблеме