Claude Code sessions run for a long time and then stop dead on a prompt — a permission dialog, a plan approval, a yes/no. You walk away, come back, and find it spent nineteen of those minutes waiting for you to press Enter.
shabadoo is a self-hosted control plane for every Claude Code session on every machine you use. One dashboard. A queue of the ones waiting on you. A notification when one has been stuck. And the ability to answer from wherever you are.
It is the round trip back to your attention. Multiply one blocked session by the number of projects you have going, across a workstation and a laptop and a box under the desk, and the cost is not compute — it is you, not being there.
Each host's agent classifies every pane. A session waiting on a prompt is flagged the moment it happens — no polling from your browser.
After 90 seconds of a standing prompt, a notification reaches your phone. Long enough that the ones you answer immediately never buzz.
Tap through to the pane, read what it is actually asking, send the keystroke. From a browser or a phone, over your own private network.
One static binary, three roles. A coordinator you run somewhere always-on, an agent on each machine that has tmux, and the launcher that starts the sessions in the first place.
# on the always-on box shabadoo hub --device-tokens --addr 0.0.0.0:8787 # on every machine you actually work on shabadoo setup --service --coord https://coordinator.example # then, from anywhere shabadoo sessions # every session on every host shabadoo tail homelab # what is that pane asking? shabadoo keys --window 3 Enter
Your laptop needs no inbound port, no tunnel, no static address. It works behind NAT, on hotel wifi, asleep half the day. Only the coordinator has to be reachable.
Copy a single file to a fresh machine and it installs the services, the launcher and the config — with no network and no source tree. No Node, no Python, no Docker required.
Each session is the expert in its own project. They message each other by domain
— send to "homelab" — see who is online, and say what they are working
on.
Every keystroke sent into every pane is recorded and attributed to an enrolled device. Read-only enrolment exists for anything that only needs to watch.
The premise is not a web terminal. It is that you already run several Claude sessions, each holding context nobody else has, and they should be able to act as one system — monitored and driven from anywhere, without any of them leaving your network.
| Capability | What it does |
|---|---|
| Route by domain | Hand a task to whichever session owns a project. Ambiguous names are refused rather than guessed; unknown ones bounce with the list of what exists. |
| Durable inbox | Mail waits for a session that is offline and is delivered when it returns. Draining is final, so nothing is silently redelivered. |
| Declared status | tmux can tell you a window is idle. Only the session can tell you it is idle because it is waiting on a peer. |
| Blocked-session queue | Everything waiting on a human, longest first, at the top of the dashboard — rendered only when it is not empty. |
Not fine print. If any of this is not acceptable to you, this is the wrong tool and it is better to find that out here.
Whoever holds a credential can read every project path, read the full buffer of any pane,
read any Claude session transcript, and send keystrokes into any pane. Those panes
typically run claude --dangerously-skip-permissions, so a keystroke can do
anything Claude can do on that machine.
Read-only enrolment limits a client to watching, and is the right default for anything that does not need to type. It mitigates this; it does not eliminate it.
Authorising an agent is the same decision as handing that machine's Claude panes to anyone who can reach your coordinator. Run it on a private network — a VPN or a tailnet — and never expose it to the internet.
Everything is self-hosted. There is no cloud service, no account, and no telemetry: your prompts, panes and transcripts never leave your machines.
| Limitation | Detail |
|---|---|
| Requires tmux | Sessions must run in tmux. If you use Claude Code in an IDE or a bare terminal, this is not for you. |
| macOS and Linux | No native Windows agent. WSL works. |
| One user | Multi-tenancy is implemented but barely exercised. Treat it as single-operator. |
| Notifications via a relay | Blocked-session alerts go through an Apprise relay to Telegram, Pushover and similar. Native iOS push is in progress. |