akaribrahim

Claude Agent Bus — Data skill for Claude Code

Data community

Claude Code plugin: parallel sessions on one machine see each other, take turns on shared services (dev server, bundler, simulator, database), and exchange messages — enforced in hooks, not documentat.

How to install Claude Agent Bus

This entry records only its repository, not the path inside it, so there is no exact command to give. Open akaribrahim/claude-agent-bus and copy the folder into ~/.claude/skills/, or the file into ~/.claude/agents/.

What Claude Agent Bus does

Alternatives in Data

Financial Services — Reference agents, skills, and data connectors for the financial-services workflows we see most — investment ba 34.5k ★
Context Mode — Benchmark Results — Benchmarked against real outputs from popular Claude Code MCP servers, Skills, and dev tools 5.6k ★
12 Services Layer — Prompt 12: Wire Up Services Layer (Analytics, Policy, Settings, Sessions) 2.3k ★

README

agent-bus

A Claude Code plugin for running several sessions on one machine without them quietly ruining each other's work.

The problem

You open two Claude Code sessions, each in its own git worktree. Their file edits never collide — separate checkouts. Two other things collide constantly, and both do it silently.

**The shared service lies about whose code it is running.** A reloading dev server watches the tree it was started in. You edit your worktree while the other one owns `:3000`, and your change never runs: the endpoint keeps its old behaviour and you conclude your fix does not work. Or your test suite goes green — against somebody else's branch. Nothing announces this. The port hides which checkout is answering.

**Agents are helpful at the wrong moment.** The other session is halfway through editing `api/service.py`. Yours runs the build, sees a syntax error in a file it has never touched, and fixes it. Now two sessions are editing one file, each undoing the other, and neither knows why.

A README explaining the rules does not fix either one, because an agent has to remember to read the README. This does, because the decision is made in a hook: the command does not run, and the agent is told what is wrong and how to fix it.

What it looks like

Not invented — copied from a run. A session in `wt2` curls a dev server that another session started from a different checkout:

agent-bus: BLOCKED. "web" (the demo server on :8099) is serving a different
checkout, so this command would exercise that code and report it as yours.

  serving   : …/repo
  you are in: …/wt2
  started by: repo-main, just now

  It serves the tree it was started in, so a request to it answers with THAT
  checkout's files.

Point it at your worktree — this stops the current one and starts
yours, and tells the other sessions it moved:
  agentbus serve web

Or run one command against your own tree and leave it there:
  agentbus run web --

A session runs the