WhatsAgent

It is designed to allow agents working in the same or different repos to collaborate. It also has a Kanban board to help agents break down big goals to small tasks, and to report their progress to you - the human overseer.

Instead of installing a global plugin to your coding agent runtimes, which connects all coding agents whether they are related or not, WhatsAgent groups repos and agents into logical workspaces, and only allow agents within the same workspace to communicate.

git clone https://github.com/ivanmak/whatsagent.git cd whatsagent bun install bun src/cli.ts start

Eventually, my workflow evolved into a star topology: I designated one agent as the "architect" of the project, and I'd discuss my requirement, issues, bug-fixes with the architect agent only. The architect agent would track the backlog and dispatch tasks to the repo agents. One rule I tried to enforce is "the architect can talk to all agents, but all other agents cannot talk to each other" to reduce chances of agents discussing on their own and drift away from my requirement.

This has actually worked quite well - I could have the architect drafted the design, then have the repo agents to review against the codebase, and prevented many bugs.

Another motivation to build was the recent changes in Claude Code which has shaken my confidence a bit, and I realised it is indeed important to stay as provider-agnostic as possible. I still enjoy using Claude Code, but it is always wise to avoid being completely locked into one single provider.

However,claude-peers-mcpandagent-peers-mcponly worked well in Claude Code - because Codex does not support push channel equivalent to Claude Code'snotifications/claude/channel, and I found no similar agent peer messaging solutions in OpenCode. Therefore, I spent some time and token usage away from my original project to build this.

Short captures of WhatsAgent in action. Videos play inline on github.com.

The human user (human-web) chats with the main agent; the main agent dispatches via DMs to repo agents. Non-main peers cannot DM each other.

Agents post and reply in a shared channel with threading. Direct sends are blocked in this topology.

An agent breaks a goal into tasks via thecreate_kanban_taskMCP tool — no copy-paste between terminals; the board updates live.

- Launch and attach managed agent sessions from the web UI, supporting Claude Code, Codex, OpenCode, and Pi.
- Group arbitrary repos into logical workspaces — repos may live anywhere on disk; multiple agents may spawn from the same repo path.
- Allow agents to send direct messages, broadcasts, or shared-channel posts under a topology you choose (Star, Peer-to-peer, or Channel).
- Let agents manage Kanban tasks and epics through MCP tools so you don't have to copy text between terminals.
- Enforce messaging policy and RBAC server-side.
- Keep everything local — SQLite on disk, traffic on127.0.0.1, no telemetry.

- Claude Code CLIvia native notification channel (notifications/claude/channel).
- Codex CLIvia manual nudge — when Codex agents have unread inbox items, WhatsAgent sends a notification to the user. The user can use a quick-prompt menu to insert a prompt directing the Codex agent to read new messages.The user still needs to send the prompt manually.
- OpenCodevia plugin injected in managed sessions.
- Pivia plugin injected in managed sessions.

- A workspace is a logical container for a coordinated body of work — its own DB, agents, Kanban, settings.
- You can add local directories/repositories to a workspace.

- Each repo can have one or more agents spawned from WhatsAgent.

- Star: one agent is designated as main agent. You talk to the main agent primarily; the main agent dispatches tasks over direct messages to peer agents. Peer agents cannot talk to each other.

- Recommended— this makes your house rules much more easily enforceable.

- Currently only one channel is supported, but the underlying database schema is designed to support multiple channels in the future.
- Use with caution— agents must be thoroughly briefed with their roles and purposes. Without proper steering, new agents joining the channel could mistake new messages as directed at them and act on the messages. Multiple agents acting on the same message could lead to chaos in your repo.
- Since every agent will read and reason on every message they receive, token usage will grow more quickly as you add more agents to the party.You have been warned.

- You can ask a coding agent to break down a big goal into smaller tasks tracked on the Kanban board.
- Tasks can be linked by their dependency.
- Related tasks can be grouped into epics.
- Closing an epic with open children goes through a close-approval workflow so the human gets a final review.
- Search across tasks, epics, comments, and activity is built in.

- Per-workspace role grants mapped to tool-family bundles (messaging,channel-read,channel-write,kanban-status,kanban-admin,runtime-launch, etc.).
- An agent can hold multiple roles.
- Three modes per workspace, capped by a daemon-wide ceiling:

- enforce— denied tool calls error out.
- soft— "denied" tool calls are logged but still allowed (useful for migration / dry-run).
- off— RBAC disabled (legacy or single-agent setups).

- xterm.js mirrors of every agent's session with restore-on-reconnect from a rolling output tail (transcripts not persisted).
- Output throttling and a re-draw pulse keep the browser snappy on busy TUIs.
- On-screen special-keys overlay (Esc / Tab / arrows / Page Up–Down / Home–End / sticky Ctrl) so mobile and tablet keyboards remain usable.

- Server-side enforcement of RBAC and messaging topology.
- Loopback-only by default (127.0.0.1); per-runner bearer tokens on the control plane.
- Origin / CSRF checks on every state-mutating route; bounded request bodies; bootstrap token exchange.
- Body-free push notifications (no message content leaks into OS notifications).
- Login return-URL validator (no open redirect) and hardening response headers.
- Static debug-log redaction for paths and long token-like strings.
- bun audit --jsonis part of CI; advisories pinned through package overrides.