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 userThe 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 uninstalluninstall removes the plugin, marketplace registration, generated launcher, and Claude profile. It keeps your Rensei login.
What gets installed
| Piece | What it does |
|---|---|
rensei MCP server | Remote HTTP MCP over /api/cli/mcp - the same six spawn/lifecycle tools and four mailbox tools documented in Spawning sub-agents. |
rensei-events MCP server | A stdio channel that uses the same pinned profile, pushes swarm events into your live session, and relays tool-approval requests. |
| A background monitor | A flag-free fallback: prints one line per new event without needing the channel to be active. |
| Hooks | A 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
userauth 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:
- Team/Enterprise org: an Owner enables channels and adds this plugin to the allowed list in managed settings.
- 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.
- 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
| Rung | Mechanism | Needs |
|---|---|---|
| 1 | Channel push + permission relay | The allowlist/launch-flag requirement above |
| 2 | Background monitor | Nothing |
| 3 | Stop-hook drain check | Nothing |
| 4 | Durable 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_childand 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. Rerunrensei claude install --scope userto 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.
Related pages
- Coordinator Overview - comparing this front-end to on-platform Claude and Codex
- Spawning sub-agents - the tool vocabulary this plugin wires up
- A2A Delivery Tiers - the durable-floor model the fallback ladder is built on
- API Key Authentication - the underlying credential the CLI manages for you