Privacy & permissions
TaskBeacon makes zero network calls. There is no account, no server, no telemetry, no crash reporting, and no update ping. Nothing about you or your work leaves your Mac, because nothing is ever sent anywhere.
TaskBeacon is closed source, so "trust us" is not an answer. Neither, honestly, is "read the code" — what runs on your Mac is the binary, not the source, and nothing ties one to the other unless you compile it yourself. So this page is written the other way round: every claim on it is paired with a command you can run against the copy you downloaded, and the output you should expect.
Verify the no-network claim yourself
Four checks. They are independent of each other, they need nothing from us, and inspecting the app this way is expressly permitted by its licence.
1. Its entitlements — one permission, signed by Apple
Expected: exactly one entitlement, and it is not a network one.
That single entitlement is what lets a click raise your terminal window. The list itself lives inside the code signature: alter one byte of the app and the signature breaks, at which point macOS refuses to launch it. This is not a web page promising you something — it is a cryptographically signed manifest you read out of the binary yourself.
~/.claude/ and drives other apps' windows through
Accessibility, and the sandbox permits neither. So read check 1 as "here is the
complete, tamper-proof list of everything it asked the system for" — not as
"the kernel is stopping it". Checks 2 to 4 are what close that gap, and they
are the stronger evidence.
2. The binary carries no network stack
An app cannot make HTTP requests without the machinery to make them, and that machinery is verifiably absent from the shipped binary. This is also enforced when the app is built: the build fails if any networking API appears in the sources, and fails again if the linked binary pulls in a network library. A release that broke the promise would not compile.
3. Zero sockets while it runs
Not "a few harmless connections" — none. Not on launch, not after a week of uptime. Run it again tomorrow. Two stronger versions of the same check:
- Leave it behind an outbound firewall — Little Snitch, LuLu, or macOS's own network privacy report. It will never once prompt you to allow a connection, because none is ever opened.
- Pull the plug. Turn off Wi-Fi and use it all day. Status, jumping, the focus ring, stats — every feature behaves identically, because none of them ever involved the network.
4. It is the copy we signed, and Apple has scanned it
Signed with an Apple Developer ID and notarized by Apple: Apple has scanned this exact build for malicious behaviour, and macOS can confirm the copy on your disk is byte-for-byte the one that was signed.
And two claims that need no command at all
- The screen claim — macOS will not let any app read your screen without listing it under System Settings › Privacy & Security › Screen Recording. TaskBeacon is not there and never asks to be.
- The files claim — everything it writes is plain text in one
visible directory,
~/.claude/taskbeacon/. Open it and read it.
The one permission it asks for
TaskBeacon requests Accessibility, and nothing else. It does not request Screen Recording, Full Disk Access, camera, microphone, contacts, calendars, or location.
Accessibility is a genuinely powerful permission — it lets an app observe and drive other applications — and macOS is right to gate it behind an explicit grant. Here is the entire list of what TaskBeacon does with it.
| What it does | Why it needs Accessibility for that |
|---|---|
| Reads window and tab titles of terminal and editor windows | To work out which window owns a given session, so a click can jump to it. Titles only — never window contents. |
| Raises a window and focuses the correct split pane when you click a row | Activating and focusing another app's UI is, by definition, an accessibility action. |
| Locates the pane it landed on to draw the highlight ring | The ring is positioned from the pane's frame in the accessibility tree. |
| Detects whether the desktop Claude app is generating a reply | That app has no hooks, so its state is read from the presence of its "Stop response" button. |
What it reads
Everything below is local to your Mac.
- Status files it wrote itself, under
~/.claude/taskbeacon/: the status per terminal (working / done / needs / idle), the current tool step, a session title, a background-subagent ledger, which terminal is currently focused, elapsed-time and token events, and your subscription quota percentage. - Live process information for running claude processes — process id, controlling terminal, working directory, and what is running underneath them. This is how a session is discovered at all, and how the app can tell "still working" from "waiting on you".
- Claude Code's own local session state under
~/.claude/sessions/, used as a fallback signal for cases the hooks cannot reach. - Window and tab titles, as described above.
What it never does
- Read the contents of your terminal, your source code, or your Claude conversations and transcripts.
- Take screenshots or record your screen. Screen Recording is not requested at all.
- Send anything anywhere. No analytics, no telemetry, no error reporting, no licence check, no update ping.
- Run in the background after you quit it, or install any daemon, launch agent or login item you did not ask for.
- Collect anything to build a profile of you. There is no identifier of any kind, anonymous or otherwise.
This website is not the app
Everything above is about the app running on your Mac. This website is a different thing, and it would be sleight of hand to let one stand in for the other — so, plainly: this site uses Cloudflare Web Analytics.
It counts page views and clicks on the download button, which is how we find out whether anyone is arriving and whether the page is any good at explaining itself. It is cookieless, it sets nothing on your device, and it does not follow you to any other site. Block it — any content blocker will — and every page here still works exactly the same.
The reason this is worth a section of its own: “makes zero network calls” is a claim about the app, and it stays exactly as true as it reads. A website that measures its own traffic does not weaken it. Quietly hoping nobody asked the question would have.
What the installer writes
The installer touches exactly three places, and nothing else on the system:
/Applications/TaskBeacon.app— the app itself.~/.claude/— the status hook script, and its entries added to~/.claude/settings.json. Existing hooks of yours are preserved.~/.vscode/extensions/(or the Cursor / Windsurf equivalent) — the companion extension that makes pane-level jumping possible. If you have none of those editors, this step is skipped rather than failed.
Removing it
The installer has an uninstall option that reverses all of the above. By hand it is three steps:
- Drag TaskBeacon.app to the Trash.
rm -rf ~/.claude/taskbeacon, and remove the taskbeacon-status.sh entries from~/.claude/settings.json.- Revoke the grant in System Settings › Privacy & Security › Accessibility.
If this ever changes
If any future feature needs a network call — an update check, for instance — it will be opt-in, it will be described on this page before it ships, and it will be called out in the changelog — never switched on quietly in a background update.
The no-network guarantee is not only a claim on this page: it is a binding term of the licence the app ships under (§4). Breaking it quietly would not just be bad manners — it would be a breach of the agreement you accepted when you installed it.