{"schemaVersion":"1.0","type":"Article","types":["Article"],"slug":"octoscope-0-33-0-the-part-of-a-pull-request-nobody-reads-line-by-line-8x3b5","url":"https://api.zyvop.com/octoscope-0-33-0-the-part-of-a-pull-request-nobody-reads-line-by-line-8x3b5","title":"octoscope 0.33.0 — the part of a pull request nobody reads line by line","subtitle":"The scan now reads your npm lockfile and tells you when a dependency starts running code at install — or when the same version quietly ships different bytes.","tldr":"The scan now reads your npm lockfile and tells you when a dependency starts running code at install — or when the same version quietly ships different bytes.","keywords":["tui","GitHub","git","cli","@babeltea","Product Showcase","CLI & Terminal"],"entities":["Giovambattista Fazioli","Senior Full-stack Engineer, Lead Developer","tui","GitHub","git","cli","@babeltea","Product Showcase","CLI & Terminal","ZyVOP"],"keyTakeaways":["The changed functions, the new test, maybe the workflow file.","Then there is a four-hundred-kilobyte block of hashes at the bottom, and you scroll past it — because nobody reads that, and there is nothing in it a reviewer would recognise as suspicious anyway.","Your lockfile is the one part of a pull request nobody reads line by line."],"headings":["What it can see now","Why the subset, and not the whole file","What it does not check, it tells you","Upgrading"],"outboundLinks":["https://gfazioli.github.io/octoscope","https://octoscope.substack.com/","https://hachyderm.io/@undolog"],"contentText":"You read the diff. The changed functions, the new test, maybe the workflow file. Then there is a four-hundred-kilobyte block of hashes at the bottom, and you scroll past it — because nobody reads that, and there is nothing in it a reviewer would recognise as suspicious anyway. Your lockfile is the one part of a pull request nobody reads line by line. octoscope 0.33.0 reads it for you. What it can see now Since v0.27.0 the scan could tell you that something in your own repository had started auto-executing — a hook that appeared, a workflow whose contents moved. It could not see the other half: a dependency that starts running code the moment you install it. That is not a new file and it is not a code change. It is a lockfile diff, and branch protection does nothing about it. Now the scan reads package-lock.json (or npm-shrinkwrap.json) on your default branch and compares the subset of your dependencies that carry an install script. Press s on any repository in the Repos tab, exactly as before. Three things it can tell you: a package that did not run code at install and now does — something in your dependency tree began executing on your machine; the same version whose content changed. That version was republished, and no upgrade explains it. It is the heaviest thing this part of the scan will say; an ordinary version bump, or a package that stopped running code at install. Both are listed, neither is scored. Why the subset, and not the whole file Because a lockfile changes constantly and the interesting part of it does not. I measured the last twenty revisions of the lockfile in three busy repositories — axios, npm/cli and undici, fifty-seven revisions in all. The files churned the entire time. The subset that runs code at install moved twice. The same version was republished zero times. That zero is the point. It is a measured rate of false alarms, not a guess, and it is what lets the sharp case actually mean something when it fires. An axis that goes off constantly is one you learn to skip, and then it is worth nothing on the day it is right. What it does not check, it tells you This is npm only, and the report says so rather than going quiet. pnpm used to declare install scripts in its lockfile and dropped the field; Yarn never had one. Building on something that has already disappeared once would ship a rule that quietly decays, so if your lockfile is theirs, you get a line naming it and saying your dependency surface was not compared. The same goes for a repository with no lockfile at all, one too large to read, or a format this scan has not measured. Silence would look exactly like nothing here runs code at install, and that is the one thing it must never imply. And it never looks at the registry. The claim is that your dependencies' auto-execute surface changed — never that a dependency is malicious. What to do about it is yours. Upgrading brew upgrade gfazioli/tap/octoscopeOr gh extension upgrade octoscope, go install github.com/gfazioli/octoscope@latest, or pull the container image. The first scan after upgrading will say it is the first comparison of your dependency surface rather than claiming nothing changed — there is nothing recorded to diff against yet. The one after that is the one that talks. Site: https://gfazioli.github.io/octoscope Newsletter: https://octoscope.substack.com Mastodon: https://hachyderm.io/@undolog","contentHash":"sha256:44b530afc4d703ea47af0a86a4b1c8b359e544a17ec97cf1c07731f024279131","authorName":"Giovambattista Fazioli","authorUrl":"https://api.zyvop.com/author/giovambattista","authorSameAs":["https://gfazioli.github.io","https://github.com/gfazioli","https://x.com/gfazioli","https://www.linkedin.com/in/giovambattistafazioli/"],"category":"Product Showcase","tags":["tui","GitHub","git","cli","@babeltea"],"audience":"Developers, software engineers, and students learning Product Showcase","tone":"Professional, senior full-stack engineer, lead developer perspective","readingTimeMinutes":3,"wordCount":598,"faqs":null,"primaryTopic":"Product Showcase","publishedAt":"2026-09-08T12:17:53.165Z","updatedAt":"2026-09-08T12:17:53.165Z","canonicalUrl":"https://api.zyvop.com/octoscope-0-33-0-the-part-of-a-pull-request-nobody-reads-line-by-line-8x3b5"}