Your agents run in parallel.
Your attention doesn't.
Every Claude Code session in your menu bar — which one finished, which one is blocking on you, and one click back to its terminal.
macOS 13.0 or later · Apple Silicon & Intel · Signed & notarized by Apple · Zero network calls
It reads process state and the status files the hooks write — not your transcripts.
Three things, done properly.
Status you can trust
TaskBeacon does not decide a session's state from one signal. It fuses the Claude Code hook events, live inspection of the process tree, and the daemon's own session state. That is why it does not stay red after you click approve, and why it keys everything by tty — the one identifier that stays put for the life of a terminal.
One click back to the exact terminal — even the third pane in the same VS Code window
Click a row and you land in that session's terminal with the cursor in its input box, and a breathing ring lights up the pane you landed on. Pane-level, not window-level. ⌃⌥⌘N walks you to the next session that needs you.
Status and usage in one place
A working row shows the tool step it is on right now (▸ Edit · router.ts). A finished row shows elapsed time, tokens, the model that session is on, and how much of its context window is gone — so you know who is burning Opus on chores before you open anything.
✓ tests passed
3 files changed
? Bash(git push)
Do you want to
proceed?
▸ Edit router.ts
esc to interrupt
Why does it need Accessibility access?
Because jumping you back to the right terminal means touching other apps. That is macOS's definition of an "accessibility" action, and macOS is right to gate it. Here is exactly what TaskBeacon does with the permission — and what it never does.
What it does with the permission
- Reads window and tab titles, so it can find the terminal that belongs to a session
- Raises that window and focuses the correct split pane when you click a row
- Draws the highlight ring on the pane it landed on
What it never does
- Read the contents of your terminal, your code, or your Claude transcripts
- Take screenshots or record your screen — Screen Recording is not requested at all
- Send anything over the network. TaskBeacon makes zero network calls.
- Keep running in the background once you quit it
- It asked for one permission, and it isn't network. The entitlement
list lives inside the code signature — change one byte of the app and the
signature breaks and macOS won't launch it.
codesign -d --entitlements - /Applications/TaskBeacon.app → com.apple.security.automation.apple-events — that's the whole list → no network.client, no network.server, nothing else
- The binary has no network stack in it. An app can't make requests
without the machinery to make them, and it verifiably isn't there.
otool -L /Applications/TaskBeacon.app/Contents/MacOS/TaskBeacon → Cocoa, AppKit, Foundation, Carbon, CoreGraphics, Swift runtime → no CFNetwork, no Network.framework, no libcurl, no libssl
- Zero sockets while it runs. Not "a few harmless ones" — none, on
launch and after a week of uptime.
lsof -i -a -p $(pgrep -x TaskBeacon) → no output at allStronger versions of the same check: leave it behind Little Snitch or LuLu for a week — it will never once ask you to allow a connection. Or just turn off Wi-Fi and use it all day: every feature behaves identically, because none of them ever involved the network.
- It's the copy we signed, and Apple scanned it. Signed with an Apple
Developer ID and notarized, so macOS can prove the app on your disk is
byte-for-byte the one that was signed
(
spctl -a -vvv /Applications/TaskBeacon.app→source=Notarized Developer ID).
How it compares
Every row below is a fact someone else can check — a line of source, a reproducible run, or a config value. Rows we could not measure say so.
| Behaviour |  TaskBeacon |
c9watch v0.8.1 reads the transcript |
claude-status-bar hook-driven |
|---|---|---|---|
| Still reports "needs attention" after you already approved | No — cleared by process probing plus a timestamp guard | Conditional — allowlisted commands are read correctly | Yes, until the command ends (replayed against its own hook code) |
| Flips a busy session to "idle" once the transcript has been quiet for 30 s | No — process tree + daemon state, never file mtime | 0 of 27 correct past its own 30-second threshold | n/a — not transcript-driven |
| Reports a session that is genuinely blocked waiting on you | 18 of 18 | 0 of 18 — the user sees "waiting for input" | not measured |
| Finds every live session | Yes — discovered from live processes | one live session missed at all 58 sample points | not measured |
| Lands on the correct split pane, not just the window | Pane level + a ring on the landing spot | window level | window level |
| Minimum macOS | 13.0 | claude-status requires 26.2 or later — 13 major versions newer | |
| Network use | Zero network calls | varies by project | |
- Sample. One machine, a five-minute window of real work: 58 sample points, 348 observations. macOS 26.6, Apple Silicon, 2026-08-03, c9watch v0.8.1, claude-status-bar 19281b2. These are not exhaustive-scenario numbers, and we do not present them as universal.
- The trade-off. TaskBeacon needs its hooks installed. c9watch needs nothing at all. Its lag is the price of that zero-integration design — quoting the scores without quoting the trade-off would not be an honest comparison.
- No circular scoring. The daemon's own state is both a reference and one of TaskBeacon's inputs. In all 18 blocked-session observations, TaskBeacon's raw hook state was already needs on its own, so the 18 of 18 is not the reference marking its own homework.
- Our own weak spot. TaskBeacon keys sessions by terminal tty. In a host that never allocates a pty, it stays completely silent — the session does not appear as a wrong row, it does not appear at all. Everything above assumes a terminal session. The full write-up is here.
- The four Notification-hook failure modes are on record as issues in anthropics/claude-code (#12048 / #59718 / #58909 / #19627); TaskBeacon has a signal source for each that does not depend on that hook. Three of the four are closed — this is not a claim that the official hook is broken today.
Install in 30 seconds
Download the installer
One file, one icon. Nothing to configure first.
Open it and click Install
It puts TaskBeacon in Applications, installs the status hooks into
~/.claude, and adds the companion editor extension if you have
VS Code, Cursor or Windsurf. Nothing else on your system is touched.
macOS asks you to confirm — once
That is the standard prompt every app downloaded from the web gets. Click Open. It does not come back.
Stop patrolling terminals. Let them tell you.
Free while it is in beta. Runs on macOS 13.0 and later, Apple Silicon and Intel, and never phones home.
Signed & notarized by Apple · Zero network calls · This build expires 1 October 2026 · Uninstalls cleanly (how)
Free while it is in beta.
Still under active development — new builds and fixes land on this page.
One email per release — new builds and bug fixes, nothing else. No newsletter, no drip sequence.
Frequently asked
Why does TaskBeacon need Accessibility permission?
For two things only: reading window and tab titles so it can match a session to its terminal, and raising and focusing that window — including the correct split pane — when you click a row. It never reads terminal contents, your code, or your Claude transcripts, never takes screenshots, and makes no network calls. It does not request Screen Recording at all.
Does it send my code or session data anywhere?
No. TaskBeacon runs entirely on your Mac and makes zero network calls.
It reads local process state and the local status files under
~/.claude/taskbeacon/.
You can verify that from outside the app: run it behind an outbound firewall such as Little Snitch and nothing will ever ask for permission, because nothing is ever sent.
It's closed source — why should I trust it?
You shouldn't have to. Publishing the code wouldn't actually settle this question either: what runs on your Mac is the binary, not the source, and nothing ties one to the other unless you compile it yourself.
So TaskBeacon is built to be audited from outside instead — against the exact copy
you downloaded. Its signed entitlement list contains one permission and no network
one (codesign -d --entitlements -). Its binary links no network stack at
all (otool -L). It opens no sockets while running
(lsof -i -a -p $(pgrep -x TaskBeacon) prints nothing). And Apple has
notarized this exact build (spctl -a -vvv). Four checks, none of which
rely on our word — the full walkthrough with expected output is on the
privacy page.
How does it know a session's status?
Three independent sources, resolved in priority order: the Claude Code hooks write a state file per terminal; the app inspects the process tree of that terminal to see whether work is actually running; and the daemon's session state fills in cases the hooks cannot reach, such as a background subagent asking for permission.
Everything is keyed by controlling tty, which is unique per terminal
and stable for its whole life — unlike session IDs, which can change inside a
single process, or the SSE port, which every terminal in one VS Code window
shares.
Is TaskBeacon affiliated with Anthropic?
No. TaskBeacon is an independent, unofficial tool and is not affiliated with, endorsed by, or sponsored by Anthropic. Claude and Claude Code are trademarks of Anthropic, PBC.
How do the hooks get installed?
The installer writes ~/.claude/hooks/taskbeacon-status.sh and
registers the hook entries in ~/.claude/settings.json for you. If you
already have hooks configured, yours are preserved. Hooks only affect sessions
opened after installation, or sessions that are still active — a terminal that has
fired no event since install has no state file yet.
Which Claude Code versions are supported?
TaskBeacon uses the documented Claude Code hook events and the local session state the CLI already maintains, so it tracks current releases. The exact verified version range is published with each release on the changelog.
macOS says it cannot open the app — what do I do?
On first launch macOS shows a one-time confirmation for anything downloaded from the web: click Open. That is the normal dialog, not an error, and it does not come back.
If you instead see "unidentified developer" or a blocked-app message, you did not get the build from this site — TaskBeacon is signed with an Apple Developer ID and notarized by Apple. Re-download it from taskbeacon.app/download.
How do I update it?
Download the current build and run the installer again — it replaces the app in place. Your settings, custom project icons and hidden-project list live outside the app bundle and are kept.
There is deliberately no update check yet, because today TaskBeacon makes zero network calls and that is a property worth keeping simple. If an opt-in update check is added, it will be announced on the changelog and documented on the privacy page before it ships.
How do I remove it completely?
Three steps, and nothing is left behind:
1. Drag TaskBeacon.app to the Trash — or use the uninstall option in
the installer, which does all of this for you.
2. Delete the state directory: rm -rf ~/.claude/taskbeacon, and remove
the taskbeacon-status.sh hook entries from
~/.claude/settings.json.
3. Revoke the permission in System Settings › Privacy & Security ›
Accessibility.
What does it cost?
Nothing while it is in beta. Each build carries an expiry date — this one stops working on 1 October 2026, and the app tells you well in advance; you then download the current build from this page. What will never happen: a build that quietly stops working. If you want an email when a new build lands, the form is just above.