Rensei docs
Coordinator

Coordinator: Claude Off-Platform (Plugin)

Install the public Rensei Claude Code plugin with one pinned user identity and tenant scope, then use its four-rung delivery ladder.

The Rensei Claude Code plugin turns a Claude Code session running on your own machine into a coordinator. It wires up the swarm/A2A MCP tools and adds several ways to hear back from children without polling by hand. The plugin is distributed from the public RenseiAI/claude-plugin marketplace.

Install

Install the rensei CLI, sign in through the browser, and select the organization and optional project Claude should use:

brew install RenseiAI/tap/rensei
rensei auth add --user --name claude-acme
rensei auth activate claude-acme
rensei setup
rensei claude install --scope user

The last command uses Claude Code's native marketplace and plugin commands. It also creates a metadata-only Rensei profile that pins the selected user login, platform origin, organization, and optional project. No bearer token is written to Claude settings or the plugin cache.

Restart Claude Code, or run /reload-plugins in an active session. Then run /rensei:setup to confirm the MCP tool surface is reachable.

Manage the integration from your terminal:

rensei claude status
rensei claude update
rensei claude uninstall

uninstall removes the plugin, marketplace registration, generated launcher, and Claude profile. It keeps your Rensei login.

What gets installed

PieceWhat it does
rensei MCP serverRemote HTTP MCP over /api/cli/mcp - the same six spawn/lifecycle tools and four mailbox tools documented in Spawning sub-agents.
rensei-events MCP serverA stdio channel that uses the same pinned profile, pushes swarm events into your live session, and relays tool-approval requests.
A background monitorA flag-free fallback: prints one line per new event without needing the channel to be active.
HooksA session-start preflight check, and a Stop-time drain check that blocks ending your turn with a reason when events are still pending.
Skills/rensei:setup, /rensei:swarm, /rensei:delegate, /rensei:swarm-status - usage patterns over the tool vocabulary above.

Auth: one pinned profile, refreshed on reconnect

The installer binds four values:

  • the saved user auth context name;
  • the exact platform origin;
  • the organization id;
  • the optional project slug.

Claude runs the plugin's header helper on each connection and reconnect. Before reading the secret store, Rensei compares Claude's actual MCP URL with the pinned origin and confirms that the saved context is still a user login. Only then does it refresh the user credential and emit Authorization, X-Rensei-Org, and optional X-Rensei-Project together.

The channel, monitor, and Stop hook load the same profile. Changing the active Rensei CLI context later does not silently move Claude to another tenant. To change any bound value, select the new context and rerun rensei claude install --scope user.

The installer writes a 0700 launcher inside Claude's persistent plugin-data directory. Plugin processes use Claude's own ${CLAUDE_PLUGIN_DATA} path, so launching Claude from a desktop app does not depend on Homebrew or ~/.local/bin being present in its PATH.

The channel allowlist caveat - read this before assuming push works

The live-push mechanism (rensei-events) rides Claude Code's channels, which are a research-preview feature with an allowlist a third-party plugin cannot self-serve onto. Stated plainly:

  • The channel MCP server always connects and its tools still work regardless of allowlist status - only the live push notifications don't arrive. Nothing breaks; you just don't get the fastest rung.
  • To actually receive channel push, one of the following must be true:
    1. Team/Enterprise org: an Owner enables channels and adds this plugin to the allowed list in managed settings.
    2. Anyone else: launch Claude Code with a per-entry development-channel bypass flag - a full-screen "I am using this for local development" warning dialog gates it.
    3. Either way, listing the server in the plugin's MCP config is not enough by itself - the session must also be launched with the channel explicitly named on the command line.
  • Individual Pro/Max accounts have no org-level check at all - only the launch-flag requirement above applies to you.

You do not need any of this to get real value from the plugin. The background monitor and the Stop-hook drain check need no flags, run by default, and degrade to nothing worse than finding out at the next turn boundary instead of mid-turn.

The fallback ladder

RungMechanismNeeds
1Channel push + permission relayThe allowlist/launch-flag requirement above
2Background monitorNothing
3Stop-hook drain checkNothing
4Durable poll (a2a_inbox, or /rensei:swarm-status)MCP reachability only

Rungs 2 and 3 run by default. A duplicate is safer than a lost event, so the monitor does not suppress itself merely because the channel process has a fresh polling heartbeat. Every event carries a stable id for deduplication. If you launch with a working channel and prefer to suppress monitor duplicates, set RENSEI_MONITOR_RESPECT_CHANNEL=1. This ladder is one implementation of the honest delivery model described in A2A Delivery Tiers: only rung 1 is genuinely live push; rungs 2-4 automate the durable-floor poll.

What's real vs. what needs a live platform rollout

Everything client-side here - the MCP protocol handling, the mailbox tool calls, event mapping, the permission relay, and the redelivery sweep - is implemented and unit-tested against fake MCP servers. Two things depend on your specific org's platform rollout and are not guaranteed just because the plugin is installed:

  • Whether the typed spawn/lifecycle tools (dispatch_child and its five companions) are live on your org's MCP door yet. If a call to one of them fails with a connection/handshake error rather than a normal tool error, check with your platform admin - the four mailbox tools (a2a_list_agents/a2a_send_message/a2a_inbox/a2a_complete_task) do not depend on this rollout and should work regardless.
  • The permission relay posts approval requests to a placeholder mailbox handle. Until something on the platform side reads that handle and answers, every relayed approval request times out - expected today, since there is no dedicated approval UI shipped yet.

Troubleshooting

  • Setup or auth failure: run rensei claude status. Rerun rensei claude install --scope user to reconcile the native plugin registration, endpoint option, profile, and launcher.
  • You selected the wrong org or project: activate the intended Rensei context and rerun the installer. Do not edit the plugin cache.
  • MCP tools connect but spawn calls are refused: a missing spawn capability is an organization-side grant, not a local authentication failure.
  • No channel push, ever: expected unless you did one of the allowlist/launch-flag things above. Confirm the background monitor is running instead - that's the rung most installs actually use.
  • Duplicate notifications for the same event: a documented, tolerated overlap between rungs 2 and 3, not a bug - every event carries a stable id you can dedupe on.

On this page