Repowire connects the coding agents you already have open. Claude Code in one repo, Codex in another, a dashboard in your browser, Telegram on your phone: Repowire gives them names and lets them pass messages without copy-paste.
It is a local control layer for multi-agent work: ask another agent a question, send a quick update, schedule a reminder, or run one session as the coordinator.
Use it when:
- One repo needs a concrete answer from an agent already working in another repo.
- You want a personal orchestrator session to dispatch tasks, collect status, or keep reviews moving.
- You want to monitor or nudge agent work from your phone or browser.
- A session should wake itself or another peer later with a scheduled check-in.
Repowire runs locally by default through a daemon on your machine. The hosted relay is optional and uses outbound connections for remote dashboard access and cross-machine mesh traffic.
Requirements: macOS or Linux. Tmux is required for the default Claude Code workflow and Repowire-managed spawning/lifecycle, but not for pane-less Codex, OpenCode, or Pi connections. Python is not required.
1. Install Repowire and wire your agents.
brew install prassanna-ravishankar/repowire/repowire
repowire setupOr use the checksum-verified native installer:
curl -fsSL https://github.com/prassanna-ravishankar/repowire/releases/latest/download/install.sh | shThe installer downloads a checksum-verified native binary from GitHub Releases.
2. Open your normal agent CLIs.
Use the tools directly; Repowire hooks into them after setup.
# tmux window 1
cd ~/projects/project-a && claude
# tmux window 2
cd ~/projects/project-b && codex3. Check that both peers appeared.
Claude Code registers on session start. Codex registers through App Server when its TUI thread opens, before the first prompt. Run:
repowire peer list4. Ask from one agent to the other.
In project-a, tell your local agent:
Ask project-b what API endpoints they expose.
Your local agent invokes Repowire's ask MCP tool, the second agent receives the question, and the reply comes back as an ack notification. Repowire is the mesh and tool surface around the agents, not a standalone chat UI. The same pattern works across Claude Code, Codex, OpenCode, and Pi when those runtimes are installed.
multi-repo-fast.mp4
You can also spawn peers through Repowire:
repowire peer new ~/projects/project-a
repowire peer new ~/projects/project-b --backend codex --profile fastFor durable recurring workers, scaffold a repo-local agent folder and target it from jobs:
repowire agents create daily-brief --backend codex
repowire jobs create "Daily brief" --path .repowire/agents/daily-brief --backend codex --cron "@daily" --prompt "Prepare the brief."Reach your sessions remotely from Claude or ChatGPT.
Enable the relay. Your relay secret is written to ~/.repowire/config.yaml under relay.api_key.
repowire setup --relayIn Claude Code, install the remote plugin, then authenticate it in /mcp:
/plugin marketplace add prassanna-ravishankar/repowire
/plugin install repowire-remote@repowire
In Claude.ai, ChatGPT, or another remote MCP client, add https://relay.repowire.io/mcp as a custom connector with OAuth. Enter the relay secret on the relay's consent page; the client gets its own scoped credentials, never the secret.
Then, from the remote chat:
Which of my agents are online? Ask project-b what API endpoints they expose and show me the reply.
The client finds the agent with list_agents, sends the question with ask_agent, and collects the answer with get_reply. See Relay MCP for scopes, expiry, and limits.
Full docs: docs.repowire.io.
- Agent-to-agent asks: Non-blocking questions with explicit
ackreplies and reminder injection until a thread is closed. - Human control surfaces: Browser dashboard, Telegram, and Slack can route messages as service peers.
- Human inbox: you are a peer too. Notifies, asks, and replies sent to you are stored in a durable inbox, pushed to Telegram with receipts, and readable with
repowire inbox. - Durable jobs: Track one-off and recurring work through CLI/MCP, with dashboard visibility and controls for run, retry, and cancel.
- Orchestrator pattern: A dedicated peer can dispatch work, check status, coordinate reviews, and keep a queue moving.
- Scheduled wake-ups: Send a future notification or ask to yourself, another peer, or an orchestrator.
- Git trailers: Agent commits carry
Repowire-ThreadandRepowire-Sessiontrailers;repowire whyreplays the conversations behind a commit. - Optional relay: Reach the dashboard remotely and bridge machines without opening inbound ports. The remote MCP plugin adds OAuth-authenticated agent conversations, delegation, and replies from compatible clients.
All peers connect to a local daemon. The daemon keeps the registry, routes asks/notifies, tracks open asks, stores durable jobs, runs schedules, and feeds the dashboard timeline.
The stable public surface is peers, circles, asks, notifications, broadcasts, schedules, and the /jobs tracked-work API exposed through CLI and MCP JSON tools. The v0.14 direction is session-native: sessions become the durable unit of work, while peers remain the live runtime executors. The current dashboard shows the selected peer/session view, merges Claude transcript history where available with realtime events, and is moving toward broader session commands for controls like resume, scheduling, approvals, and future backend/model changes.
Transport notes:
- Claude Code uses hooks plus MCP, with its authenticated native session inbox for delivery. Claude Code 2.1.224+ is required.
- Native session APIs connect through runtime-side bridges; routing remains daemon-owned and transport-neutral.
- Codex uses an App Server bridge plus MCP; daemon-minted thread certificates preserve identity across soft retirement, while tmux remains optional lifecycle/placement support.
- OpenCode uses a TypeScript plugin plus WebSocket; its per-session identity and certificate survive plugin reconnects.
- Pi uses the Repowire extension path when detected by setup, with the same per-session reconnect protection.
- Claude Code's Channel bridge / ACP delivery is experimental and opt-in.
- Relay is optional remote access, not a requirement for local routing.
| Agent runtime | Connection path |
|---|---|
| Claude Code | Hooks + MCP + native session inbox; optional experimental channel/ACP |
| Codex | App Server threads + MCP |
| OpenCode | Plugin + WebSocket |
| Pi | Native Repowire extension + WebSocket |
| Human or service surface | Role in the mesh |
|---|---|
| Dashboard | Browser control surface at localhost:8377/dashboard or through relay |
| Telegram | Phone control surface and notification target |
| Slack | Team chat control surface |
| Orchestrator peer | Long-running coordinator that dispatches and reviews work |
| Relay dashboard | Optional remote dashboard and cross-machine bridge |
repowire setup auto-detects installed runtimes and wires the supported transports it finds.
The agent-orchestration space is moving fast. Most projects cluster around a few shapes:
- Worktree/task runners: Claude Squad, Vibe Kanban, and dmux help launch and review many isolated agent workspaces.
- Deterministic schedulers: Bernstein decomposes goals, runs agents in parallel worktrees, verifies, and merges passing work.
- Hierarchical swarms: multi-agent-shogun defines manager/worker roles and routes tasks through tmux, files, or role-specific protocols.
- Agent IDEs and workflow systems: HumanLayer/CodeLayer focuses on planning, review, team workflows, and richer agent workspaces.
Repowire sits in a different slot: it is a live mesh and control plane for agent sessions you already have running. It does not try to be the scheduler that decomposes every goal, the kanban board that owns every branch, or the merge gate that lands code. It gives your existing terminals, dashboard, Telegram, Slack, and orchestrator session a shared address book, message lifecycle, schedule queue, and local session timeline.
Project A needs the real API shape from Project B. Ask project-b; the peer answers from its live checkout, not stale docs. See multi-repo coordination.
Send work to a peer from Telegram, Slack, or the dashboard, then receive progress updates from agents as notifications. Telegram and Slack human messages open tracked asks by default; use their notify/FYI commands for fire-and-forget nudges. See mobile mesh management.
Run one session as the orchestrator. It can dispatch to project peers, ask for status, review PRs, and wake itself later. See orchestrator coordination.
Schedule a reminder, check-in, or future ask:
repowire schedule self 10m "check CI"
repowire schedule create orchestrator 1h "handoff" --from-peer project-a --kind askClaude Code commits made through Repowire record the ask threads they closed as git trailers. Replay them:
repowire why # HEAD
repowire why abc1234 # any commitEnable the hosted relay when you want remote dashboard access or cross-machine mesh traffic:
repowire setup --relay
The dashboard shows peers, status, descriptions, chat turns, tool calls, attachments, durable jobs, and the selected peer/session timeline. Its non-destructive Fork to… control can start a sibling backend in the same project and circle without stopping the current peer; backend-native conversation history is not copied. For Claude Code peers, the timeline can merge transcript history with realtime events; other backends contribute realtime events as their transports report them.
Run it locally at:
http://localhost:8377/dashboard
With relay enabled, use:
https://repowire.io/dashboard
repowire setup # install runtime transports/service + localhost MCP identity shim
repowire setup --update-checks # let status/doctor report available updates
repowire update # explicit package upgrade + hook reinstall + daemon restart
repowire status # show installed components and daemon status
repowire doctor # run diagnostics
repowire service restart # restart daemon; preserve Codex sessions
repowire service restart bridge # restart the Codex adapter; Codex sessions keep running
repowire peer list # list mesh peers
repowire peer new PATH [--profile P] # spawn a peer in tmux
repowire schedule self 10m "check CI" # wake this peer later
repowire telegram start # manually run Telegram against another daemon
repowire slack start # manually run Slack against another daemonThe daemon uses ~/.repowire/state.db for durable local state. On first startup
after install or update, it applies SQLite migrations and imports legacy
schedules.json, events.json, and sessions.json once while leaving those
files in place for downgrade/export compatibility. Migrated state is written to
SQLite, and repowire doctor reports the SQLite schema, integrity, and import
status.
See the full CLI reference and MCP tools reference.
Repowire is a router whose default strategy is static: an ask goes to the peer it names, and a named peer is never overridden. Other strategies are opt-in. With routing.strategy set to an arm (for example jev-attested), an ask that names no peer is routed to the arm's pick. The pick passes the same circle and addressability checks, and the sender's fallback_to is used if the arm cannot choose. routing.record and routing.shadow_arms record decisions and run arms beside named asks for offline comparison with repowire route replay. See routing configuration.
routing:
strategy: static # default; or an arm name to route asks that name no peerConfig lives at ~/.repowire/config.yaml.
daemon:
host: "127.0.0.1"
port: 8377
auth_token: "rw_local_..."
mcp_http:
enabled: true
bind: "localhost-only"
require_auth: true
allow_dangerous_tools: false
spawn:
commands:
claude-code: "claude --dangerously-skip-permissions"
codex: "codex --dangerously-bypass-approvals-and-sandbox"
pi: "pi"
profiles:
codex:
fast:
args: ["--model", "gpt-5-mini"]
allowed_paths: [~/git, ~/projects]
updates:
check_enabled: false
relay:
enabled: true
url: "wss://repowire.io"
api_key: "rw_..."Update checks are off by default. If enabled with repowire setup --update-checks, repowire status and repowire doctor may report that a newer release is available, but they do not rewrite hooks or restart services. Use repowire update when you want to upgrade explicitly; Homebrew installs delegate that command to brew upgrade. Updates restart the routing daemon but preserve a live Codex bridge, and never restart Codex's App Server, so active Codex sessions remain running.
Security defaults:
- Local daemon binds to
127.0.0.1. - Relay is opt-in and uses outbound WebSocket.
- WebSocket and local HTTP auth are available through
daemon.auth_token. - MCP tools are implemented by the Go daemon at a localhost-only, bearer-authenticated
/mcp; agent runtimes reach it through a thin stdio identity shim, and the relay tunnel rejects that local endpoint. The relay has its own scoped remote MCP endpoint with OAuth. - Spawn requires explicit command and path allowlists.
- Experimental channel/ACP transport is opt-in.
git clone https://github.com/prassanna-ravishankar/repowire
cd repowire
cd web && npm ci && npm run build && cd ..
mkdir -p bin
(cd daemon-go && go build -o ../bin/repowire .)
./bin/repowire setup --non-interactiveHooks and the MCP identity shim run the binary recorded by setup, not an arbitrary binary elsewhere in your checkout. Rebuild that binary after native changes, then restart the daemon service:
(cd daemon-go && go build -o ../bin/repowire .)
./bin/repowire setup --non-interactive # rewrites hooks/MCP/service to this build
./bin/repowire service restart # enough when only daemon code changedIf service management fails, use repowire service status first. Raw launchctl on macOS or systemctl --user on Linux are fallback troubleshooting tools.
Codex (0.158+) starts and upgrades its own shared App Server; the Repowire bridge only attaches to its Unix socket. Repowire never launches Codex, so macOS attributes privacy prompts for Codex's tools to your terminal. Setup removes the App Server LaunchAgent that earlier releases installed; open Codex sessions reconnect to Codex's server with their conversations intact.
repowire uninstall
rm -f ~/.local/bin/repowire
rm -rf ~/.local/share/repowirerepowire uninstall removes hooks, MCP entries, channel transport config, OpenCode plugin files, and the daemon service. It does not automatically remove ~/.repowire/, which contains local config, events, attachments, and relay keys.
See CONTRIBUTING.md. Before opening a PR, run the advisory repo-hygiene checklist:
scripts/pre-pr-hygiene.shIt is an opt-in prompt for docs, README, and agent-instruction follow-ups, not a mandatory hook.
MIT