octoscope 0.37.0 — your inbox reaches your scripts

Your GitHub inbox now reaches your scripts 📬

Until today, octoscope's Inbox lived in one place: the TUI tab. If you wanted your unread notifications in a status line, a cron job or a morning summary, you were back to gh api /notifications, and to redoing what the tab already does: sorting threads GitHub doesn't return in time order, and turning API URLs into links you can actually open.

octoscope 0.37.0 adds --inbox to the scriptable side. octoscope --plain --inbox adds an Inbox section to the summary: when, why (review_requested, mention, ci_activity…), what kind of thread, which repo, and the title.

With --json you get the same page as an inbox array: up to 50 unread threads, newest first, each with GitHub's own reason and type.

A couple of ways to use it:

→ count what's actually waiting on you:

octoscope --json --inbox | jq '[.inbox[] | select(.reason == "review_requested")] | length'

→ pair it with --activity for "what I did" and "what's waiting" in one document, and add --public-only to keep threads from private repos out.

One heads-up: GitHub's notifications endpoint doesn't accept fine-grained tokens, whatever permissions they carry. A classic token or gh's own works, and if yours gets refused, the error now says exactly that instead of a bare 403.The detail I enjoyed getting right: an empty inbox is an answer. If you didn't ask for it, there's no inbox key at all; if you asked and you're at inbox zero, it's []. And if the fetch fails, the run fails. It never quietly prints something that looks like inbox zero.

brew upgrade gfazioli/tap/octoscope

How do you keep up with GitHub notifications today: the web bell, email filters, gh? And where would you pipe this first? 👀

Site:

Newsletter:

Mastodon:

8 views

Add a comment

Replies

Be the first to reply

Have a question or a thought to share? Add a comment above to start the conversation.