Агенти й worktree
Кожна сесія агента, що працює через rtok, отримує один id агента rtok, а кожен worktree прив'язаний до агента, який ним володіє, однаково на кожному хості. Агенти й користувач можуть надсилати одне одному повідомлення за цим id. Ця сторінка — опис для користувача (рішення D34); таблиці встановлення для кожного хоста є в agents.md, а ключі конфігурації — в config.md.
Id агента
- Id — це випадковий UUIDv4, який rtok видає сам; він показується першими 8 символами й приймається будь-де як будь-який унікальний префікс завдовжки 4 символи або більше. Id сесій хостів не унікальні між хостами, а кілька хостів їх узагалі не мають, тому їх ніколи не використовують як id.
- Хуки реєструють агента на першій події сесії й оновлюють його на кожній наступній (
SessionStart, виклики інструментів,SessionEnd). Хосту, чиє встановлення несе хуки, більше нічого не потрібно. - MCP обслуговує хост без хуків.
rtok mcp --host <host>прив'язується до агента сесії за власним id сесії хоста, якщо хост кладе його в середовище (Grok Build:GROK_SESSION_ID), інакше — за єдиним живим агентом цього хоста в тому самому каталозі, якого бачили після запуску процесу. Два кандидати нікого не прив'язують, тож повідомлення ніколи не потрапляє не до того агента. Хост, який не може нести ні хуків, ні id сесії, отримує власний рядок, який реєструє процес MCP. - Агент завжди береться із сесії. Жоден інструмент не приймає аргументу агента чи власника, тож модель не може заявити права на worktree або надіслати повідомлення від імені іншого агента.
rtok agents whoamiвиводить id (RTOK_AGENT_ID, який хук Claude Code кладе в середовище сесії й наводить у рядку контексту початку сесії; якщо його немає, як у десктопному застосунку Claude, — агент сесії зCLAUDE_CODE_SESSION_ID); MCPwhoamiповертає його разом зі способом прив'язки.
Бачити агентів і говорити з ними
| Команда | Інструмент MCP | Що робить |
|---|---|---|
rtok agents sessions [--all] | agents_list | кожен агент із хостом, станом (live, idle, ended), активністю, статусом, заявленими worktree і кількістю непрочитаних; --all додає завершених |
rtok agents show <id> | agent_show | один агент: хост, модель, id, батько й субагенти, cwd, заявлені worktree, статус, непрочитані |
rtok agents status <text> | agent_status_set | чим зайнятий цей агент (не більше 120 символів); порожній текст очищає його |
rtok agents send <id> <text> | agent_send | повідомлення одному живому агенту (з обмеженням розміру); --all-live надсилає кожному живому агенту проєкту відправника; --task <id> (task у MCP) позначає повідомлення завданням, про яке воно, наприклад A12 |
rtok agents inbox [<id>] | agent_inbox | ваші власні повідомлення, від найстаріших, позначаються прочитаними; з id — черга цього агента, нічого не позначається; --task <id> (task у MCP) читає листування за одним завданням, решта лишається непрочитаною |
[agents] idle (типово 30 хвилин) визначає, хто живий. [agents] enabled = false зупиняє реєстрацію та надсилання.
Повідомлення
- Хост із хуками отримує нові повідомлення, надіслані в наступний промпт або результат інструмента, в оформленому вигляді й у межах
[agents] push_bytes; решту оголошено як… and N more, її читають черезagent_inbox. Кожен інший хост забирає їх сам: рядок початку сесії каже викликатиagent_inbox, а повідомлення читає інструмент MCP абоrtok agents inbox. - Безпека: тіло повідомлення — це текст від іншого агента чи людини, а не інструкція. Кожне приходить усередині фіксованої рамки, що називає id відправника, керівні символи вилучено, розмір обмежено, і жоден аргумент інструмента не може назвати відправника. Сприймайте його як інформацію.
Worktree
Сирий git worktree не записує власника, вік чи розмір. rtok worktree дає кожному worktree одне розташування, одну назву, одного власника й одного агента:
| Команда | Інструмент MCP | Що робить |
|---|---|---|
rtok worktree add <task> [<slug>] | worktree_add | створює <root>/<repo>-<task> на гілці <task>[-<slug>] зі свіжого origin/<default>, заблокований як <owner> | <task> | <date> | agent <uuid>, і записує заявку |
rtok worktree adopt [<path>] [--task <id>] | worktree_adopt | прив'язує worktree, створений хостом, до викликаного агента; каталог лишається там, де його поклав хост |
rtok worktree claim <path> | — | те саме для наявного worktree, який ви називаєте; переписує його блокування, лише коли його немає або воно вже ваше |
rtok worktree list | worktree_list | кожен worktree репозиторію з власником, прив'язаним агентом і його станом, origin, розміром; а також осиротілі, яких git більше не показує |
rtok worktree remove <path|task> | worktree_remove | видаляє ваш власний чистий worktree і його злиту гілку; відмовляє для брудного, незлитої гілки, того, у якому ви стоїте, і чужого блокування, якщо задачу не завершено (злита, чиста, з власними комітами); ніколи не примушує |
rtok worktree gc, clean | — | прибирають завершені worktree, видаляють неактивні кеші збірки; пробні запуски, доки немає --yes; worktree живого агента зберігається, а якщо його задачу завершено й він простоює довше за --idle, його видаляють за будь-якого блокування; чуже блокування на злитому чистому worktree, якого не торкалися --stale-lock (7d), вважається покинутим |
Власник — це <host> / <model> агента, доки виклик CLI не передасть --owner; виклик MCP ніколи цього не робить. Корінь — це [worktree] root, типово ~/.rtok/worktrees. З [worktree] enabled = false rtok не чіпає worktree: кожна команда rtok worktree (і list теж) каже, що вони не ввімкнені, MCP не показує жодного інструмента worktree_*, а хуки Claude WorktreeCreate/WorktreeRemove роблять те, що Claude робить без rtok.
Worktree, які хост створює сам
Хост, що створює worktree у власному пулі (Cursor, Codex, Windsurf і Devin, Kilo, Claude Code, Conductor), не лишає rtok вибору місця. Запустіть worktree_adopt (або rtok worktree adopt) усередині нього: rtok виводить origin зі шляху, бере завдання з --task, інакше зі старого блокування, інакше з гілки, і прив'язує його.
- Cursor, Codex і Windsurf/Devin самі видаляють worktree, щоб не перевищити ліміт (приблизно 25, 15 і 20). Чи переживає блокування git таке видалення, не підтверджено, тож прийняття там записує заявку лише в сховищі rtok і не пише блокування.
- Кожне інше походження отримує те саме блокування v2, що й
worktree_add. - Worktree, заблокований кимось іншим, ніколи не береться.
- Запуск
adoptзі скрипта після створення в хості (Cursor.cursor/worktrees.json, Kilo.kilo/setup-script, Windsurf і Devinpost_setup_worktree) — налаштовується командоюrtok agents install <host> --project(хостиcursor,kilo,windsurf,devin): вона додає один запис у файл проєкту й нічого більше не чіпає;rtok agents uninstall <host> --projectйого прибирає. Без названого агентаadoptприв'язує єдиного живого агента хоста цього пулу, чий робочий каталог — репозиторій, а якщо таких немає або їх кілька, відкладає claim без агента й без git-блокування; його завершує наступнийadoptабоSessionStartсесії, що працює всередині worktree;worktree gcтакий worktree не чіпає. Через skill нижче агент може прийняти worktree завжди.
Skill worktrees розповідає агентові все це: worktree_add для нової роботи, worktree_adopt для worktree, створеного хостом, worktree_remove, коли злито.
За хостами
Хуки — чи звичайне rtok agents install несе хуки (рядок агента й надсилання повідомлень); хост без них реєструється через MCP. Факти про нативні worktree й джерела — у research.md §26.
| Хост | Хуки | Рядок агента з | Нативні worktree | Прийняття worktree, створеного хостом |
|---|---|---|---|---|
claude | так | хуки | .claude/worktrees/<name>; WorktreeCreate/WorktreeRemove можуть замінити типовий (перенаправлення rtok очікує T159) | worktree_adopt |
cursor | так | хуки | ~/.cursor/worktrees/, ліміт 25 | worktree_adopt; скрипт після створення: agents install --project |
codex | так | хуки | $CODEX_HOME/worktrees, зберігає 15 | worktree_adopt |
windsurf | ні | MCP | ~/.windsurf/worktrees/<repo>, ліміт приблизно 20 | worktree_adopt; скрипт після створення: agents install --project |
devin | так | хуки | ділить пул із Windsurf | worktree_adopt; скрипт після створення: agents install --project |
kilo | ні | MCP | .kilo/worktrees/ | worktree_adopt; скрипт після створення: agents install --project |
grok | ні | MCP (GROK_SESSION_ID) | worktree субагентів --parallel, шлях не перевірено | worktree_adopt |
mimo | ні | MCP | auto_worktree і режим оркестратора | worktree_adopt |
omp | ні | MCP | ізоляція на завдання | worktree_adopt |
antigravity | ні | немає (ні хуків, ні запису MCP) | режим на розмову, шлях не перевірено | CLI rtok worktree adopt |
opencode | ні | MCP | вбудованих немає | worktree_add |
pi | ні | немає (ні хуків, ні запису MCP) | у ядрі немає | лише CLI |
zcode | так | хуки | не знайдено | worktree_add |
kimi | так | хуки | не задокументовано | worktree_add |
copilot | так | хуки | не задокументовано для цього інтерфейсу | worktree_add |
vscode | ні | MCP | окрема функція вікна Agents, шлях не перевірено | worktree_adopt |
commandcode | так | хуки | не задокументовано | worktree_add |
gemini | так | хуки | не знайдено | worktree_add |
cline | так | хуки | немає (checkpoints, не worktree) | worktree_add |
roo | ні | MCP | ще не перевірено | worktree_add |
junie | ні | MCP | ще не перевірено | worktree_add |
droid | ні | MCP | ще не перевірено | worktree_add |
kiro | ні | MCP | ще не перевірено | worktree_add |
amp | ні | MCP | ще не перевірено | worktree_add |
warp | ні | MCP | ще не перевірено | worktree_add |
crush | ні | MCP | ще не перевірено | worktree_add |
openhands | ні | MCP | ще не перевірено | worktree_add |
augment | ні | MCP | ще не перевірено | worktree_add |
reasonix | ні | MCP | ще не перевірено | worktree_add |
qwen | так | хуки | ще не перевірено | worktree_add |
codebuddy | так | хуки | ще не перевірено | worktree_add |
goose | ні | MCP | ще не перевірено | worktree_add |
continue | ні | MCP | ще не перевірено | worktree_add |
codewhale | так | хуки | не задокументовано | worktree_add |
aider | ні | немає | немає | лише CLI |
zed | ні | MCP | треди можуть вказувати на worktree, який ви створили | worktree_adopt |
Кожен хост може створювати worktree через worktree_add (MCP) або rtok worktree add (CLI); хост без рядка агента передає --owner у CLI. Worktree, чий шлях не збігається з жодним із пулів вище, показується з origin other і приймається так само. worktree add також записує env.CLAUDE_CODE_TASK_LIST_ID = <project>-<task> у .claude/settings.local.json нового worktree, щоб сесії Claude Code там ділили один список завдань; записується лише цей ключ, решта файлу не змінюється, файл, що не є коректним JSON або вже задає цей id, лишається недоторканим із попередженням, а .claude/ ігнорується git.
Десктопний застосунок Claude
У вкладці Code десктопного застосунку MCP-інструменти rtok обслуговує один rtok mcp, який застосунок запускає з claude_desktop_config.json для всіх сесій одразу, а не процес самої сесії. Цей процес не перебуває під жодною сесією і в жодному її каталозі, тому MCP whoami, worktree_* і agent_* не можуть визначити, який агент їх викликав, і відповідають «not linked to an agent session» з цією причиною. Там використовуйте rtok agents і rtok worktree з shell агента. Щоб спільний запис не приховував власний сервер сесії — задача T456.