The docs say flags override the config file for that run. They also ended up in the file. Start octoscope with --theme amber, pin a repository, and amber was your theme from then on. Same for --refresh, --compact, --public-only and --no-sponsor: the next save about anything else wrote them all.

I measured it before touching anything: four flags, then p twice (public-only on and off again, so a net change of nothing), and the config held all four.

Now a flag is for the run it is given to. If you change a setting in the app, in the settings panel or with p, that is a choice and it is saved. A flag you never touched is not.

Second fix: q quits on the launch screen. Before the first dashboard, a comma opened the settings panel behind the launch screen, and the next q went to a panel you could not see. Until there is a dashboard the screen now takes q, the help and rate-limit overlays, and a tab chosen ahead. Nothing else.

Archived repositories stop counting as work in octoscope 0.40.0

octoscope 0.27.0 the integrity scan stops describing a repo and starts noticing things about it.

Before this release the supply-chain scan could only talk in the present tense: here is what auto-executes right now, here is a commit tip that looks forged. Useful if you happen to scan while the implant is sitting there. Useless for the two questions you actually have when a worm is circulating did something change, and what could whoever got in reach?

Your lockfile is the one part of a pull request nobody reads line by line. 0.33.0 reads it for you.

It opens on your last dashboard, not on a spinner

On a busy account octoscope's first fetch takes about ten seconds, and until 0.39.0 you spent them looking at a launch screen. Now the dashboard you saw last is on screen the moment it starts.

The supply-chain scan used to work one repository at a time, from the dashboard. If a worm had pushed an implant into one of your 90 repos, you'd have had to open them one by one to find out.

Now one command does the round:

Your GitHub inbox now reaches your scripts

octoscope 0.36.0 is out and this time the terminal has someone in it.

Hey everyone octoscope 0.30.0 is out, and this one has an odd origin story: three of its four changes were written by one of you.

They came in as a comment under the 0.27.0 launch. He didn't ask for a single feature. Instead he found three places where octoscope's report claimed more than it had actually verified and every one of them held up when I went and measured it. One even turned up a bug that had been sitting in the code for several releases.

octoscope 0.28.0 is out, and the integrity scan can now see an attack that lives in two files instead of one.

Here's the shape it used to miss. You read a workflow, it triggers on pull_request_target so anyone can start it, and it holds nothing worth stealing. Fine. Except the last line is uses: ./.github/workflows/build.yml with secrets: inherit and that file reads your deploy token. Neither file is a finding on its own. Together they're a stranger's pull request opening a path to your secrets.