You rename packages/cli to apps/cli. The next scan tells you a dependency started running code at install, and another one stopped. Nothing started you moved a folder.
0.34.0 is four changes that are the same sentence from different angles: a security signal is only worth reading if it fires on what happened, not on what you did to your own repo. An axis that cries wolf is one you learn to skip, and then it's worth nothing on the day it's right.
Two additions that close the loop between watching (what v0.14.0 widened) and noticing (what's actually waiting for your attention). One feature lands on screen, one in your macOS notification center; both keep octoscope read-only.
octoscope 0.32.0 answers a question the Repos tab could not: which of your repositories do you actually commit to most?
Until now you could see your commit count for one repo at a time, in the drill-in. Fine for "how much did I do here", useless for "where does my year actually go" that is a question about the ordering of the whole list, and you cannot answer it one row at a time.
Until this release there were two doors: Homebrew, or go install. Both fine, both assuming you wanted a binary on your machine which is not what you want when you're inside gh already, or writing a CI step, or on a box you'll throw away in ten minutes.
Following up on what @sk_uxpin asked for on the v0.11.0 launch thread: you can now read pull-request diffs inside octoscope.
Press Enter on any PR for the drill-in. Press f for a full-screen list of the changed files. Enter on a file row opens its unified diff with syntax highlighting chroma's diff lexer, monokai palette, the universally recognised red/green for - / + lines and a scrollable viewport so a 400-line patch fits without pushing anything off-screen.
Four things still made me open a browser every day, even with octoscope running. 0.29.0 is those four.
A gist I needed the code out of. What I actually did this week. Who funds the work. And the notification that mentioned me.
Gists now open into the file contents, syntax-highlighted c copies the code, not the link. A one-file gist opens straight into it, because that was the only thing there was to see.
Quick backstory on the "why": octoscope's repo drill-in shows a 12-month star-history sparkline, and that reads GitHub's stargazers endpoint which GitHub has been tightening (a scoped token is now required) and which throws the odd 5xx. The catch: one failed star-history call used to abort the whole detail view. Not great.
Now it's best-effort. If star history can't load, octoscope just drops the sparkline and still shows the description, license, latest release, recent commits and open issues/PRs. The star count itself was never affected that's a public number, not the restricted list.
The biggest UX shift since I shipped octoscope. The drill-in pattern I prototyped for Repos in v0.10.0 now works on PRs and Issues too and it's bound to Enter, the universal TUI gesture for "go deeper".
Issues state chip, markdown-rendered description, assignees, recent comments, labels, linked PRs (the ones that would close the issue when merged), curated timeline.
Repos description, license, language chips, latest release, languages bar, recent commits with a "N total M by you in the last year" counter, open issues / PRs preview, topics.
Each detail is fetched in a single targeted GraphQL query for that one item no fan-out across your list, zero rate-limit pressure. Descriptions and comments render through glamour (https://github.com/charmbracelet...) with chroma syntax highlighting, so a "## heading" is a heading and a fenced code block is colourised.
octoscope's Repos tab has had pinned repos for a while now a sticky section up top for the handful you actually live in. This release gives the Issues tab the same treatment.
Press P on any issue (or pick Pin from the space action menu) and it sticks to the top, in the order you pinned it, across refreshes and restarts. It composes with everything else you already do: the sort cycle (s) reorders only the rest, and the / filter narrows both sections at once. The set is saved to your config under pinned_issues, so the next launch brings them right back press P again to unpin, and a pinned issue that gets closed just stops showing.
