GitHub notifications on two (or more) computers

Updated August 2026 · 5 min read

You clear your notifications at the office, come home, open your laptop — and the badge says 17 unread, all of which you already dealt with. If you work on more than one machine, GitHub notification state seems to split into parallel universes. Here's why it happens and how to make every device agree.

Why the counts diverge

GitHub itself has exactly one source of truth: the /notifications API, tied to your account. Mark something as done, read or unsubscribe, and it changes server-side for everyone. The divergence is almost never GitHub — it's what each client does between polls:

• Clients that cache locally. A browser tab you left open, an email client that downloaded notifications, or any tool that stores "unread" state on disk will keep showing yesterday's world until it refreshes. Some only reconcile when reopened.
• Different polling intervals. Machine A polled 30 seconds ago; machine B last polled 40 minutes ago. Both are "correct" — just at different moments.
• Email as a second copy. If you get notification emails, every machine's mail client holds its own read/unread state that has nothing to do with GitHub's. Clearing one doesn't touch the other.
• Different accounts or tokens. Easy to hit with work and personal setups: if one machine uses an old token or a different account, its count is genuinely for a different universe of notifications.

The sync-first checklist

1. Pick one account per machine. In each client, confirm whose token is in use. On GitHub, check Settings → Applications → Authorized OAuth Apps / Personal access tokens to see what's live and revoke strays.
2. Drop email as a notification surface. Keep it archived for search if you like, but don't let mail clients own read state — that's the copy that never syncs. See how to turn off GitHub email notifications.
3. Prefer clients that read the API directly. Anything that polls /notifications fresh shows server truth within one poll interval, on every machine, no shared state needed.
4. Accept the interval, shrink it. With API-based clients the worst-case skew equals the poll interval. A 60-second poll means the two machines disagree by at most about a minute — usually shorter than the walk between them.

What "synced" should feel like

The test: mark everything done on machine A, then refresh on machine B. If B still shows old items after a normal refresh, B isn't reading the API — it's replaying its own cache. That's also why phantom counts survive even on a single machine after using both the web UI and a client; we cover that cousin of this problem in phantom notifications that won't clear.