PenguPool
VS CODE · CURSOR · PI

Every agent session.
In your editor.

The PenguPool extension puts your Claude Code and pi sessions in the VS Code or Cursor sidebar: a session tree, a live map of who is talking to whom, the message log, and a terminal that switches between live sessions without restarting them.

curl -fsSL https://pengupool.nduwork.com/install.sh | bash

Installs the CLI, the wiring for each installed harness, and the extension in every VS Code and Cursor it finds. Needs Python 3.11+, Make, tmux 3.2+, and Claude Code and/or pi. Other install options →

See the plugins Read the guide

Open source · MIT · macOS & Linux · v0.1.0 · local only, no hosted account

THE PLUGINS

One backend, three ways in.

Each harness gets its own wiring. They all read the same local model under ~/.pengupool/, and one tag ships a matching backend and extension.

▣

VS Code & Cursor extension

  • Sessions and pi Sessions trees; drag a row to regroup
  • Live map with cards sized to their text and a ⟳ Refresh button
  • Message log coloured by edge: parent → child, child → parent, @session
  • One tmux-backed terminal per harness that switches sessions in place
  • Shift+R Restart & Resume after a Claude Code or pi update
⚓

Claude Code hooks

  • A <pengupool> block each prompt: tree, parent, children, role
  • SendMessage guard: parent and direct children only
  • ROUTE REQUIRED when a prompt matches a child's keywords, checked again at Stop
  • ROLE REQUIRED until the session describes itself
π

pi extension

  • The same tree block, appended to pi's system prompt
  • pi-intercom send/ask checked against the routing rule
  • Workflow chain in pi's footer and prompt
  • Its own tmux server; never grouped with Claude Code sessions
WORKING WITH A POOL

Brief the tree, then let it route.

PenguPool enforces the tree, but the agents only know what you tell them. These habits keep work flowing to the session that owns it.

1

Tell the parent about every new child

After you add and group a session, tell its parent it exists and how you plan to use it. Then give the child its job.

I added api under you. It owns the REST endpoints in server/. Route API work to it and keep planning and review yourself.
2

Check each role, edit when needed

Roles are automatic: a new session is told ROLE REQUIRED until it describes itself, routing keywords included. Hover a row to review it. Right-click → Describe Role… to edit the summary and brief, or set keywords yourself.

pengupool ctl describe <id> --keywords "api, endpoint, auth"
3

Talk to the top, let triage route

Prompt the root session and read the Triage: line that starts each reply. To keep one task local, say so.

Fix the login copy typo. Do it yourself.
4

Use @session for a one-off direct line

Tagging a session lets the one you typed into message it directly until your next prompt, without regrouping anything.

@reviewer check the diff in api before I merge.
5

Pick folder or worktree on purpose

Use the same folder for reviewers, readers or a second pair of hands, even when a session already runs there. Use a worktree when two sessions edit the same files.

6

Keep the tree intact

Compact with c or /compact. /new and /clear start a new session, which leaves the group. After a Claude Code or pi update, press Shift+R to restart in place.

Read the full guide →
BUILT FOR MANY MOVING PARTS

Keep the whole pool in sight.

PenguPool makes local agent work easier to follow while the agents keep running in their own sessions.

⌘

Switch without starting over

Open live tmux sessions from any editor window. Close the editor and come back to the same work.

⑂

Route work, not guesses

Group sessions into a tree. Messages go only one edge at a time, and tagging @reviewer in a prompt opens a direct line until your next one.

◎

Give each session room

Start in the same folder as other sessions or in an isolated git worktree, describe each session's role and routing keywords, and track its current phase.