Beekeeper v1.1.0: install posture, and the loop that remembers

Beekeeper v1.1.0. Install posture replaces the package-manager nudge, the TUI learns to read your package managers, and two pieces of v1.0.0 finally get the introduction they were owed.

The nudge is retired

Earlier builds shipped a package-manager nudge: when an agent ran npm install, Beekeeper would steer it toward pnpm or Bun, because those package managers blocked install lifecycle scripts by default and npm did not. It was a reasonable hedge at the time. It was also opinionated about which tool you should use, and it only helped the npm case.

npm v12, landing in July, blocks install lifecycle scripts by default. Once the default that everyone already reaches for is the safer one, steering between package managers stops earning its complexity. So the nudge is gone, and the old nudge subcommands and config set nudge.* keys go with it. What replaces it is not another opinion about your tooling. It is a check that does not care which package manager you use.

Install posture, the tool-agnostic successor

Install posture is a default posture that Beekeeper evaluates at the agent pre-exec hook for every package install, whichever package manager the agent reaches for. Three rules:

• Release age. A package first published less than 24 hours ago warns.
• Lifecycle scripts. An install that would run a pre or post-install script warns.
• Git or remote-URL dependencies. A dependency pulled from a git ref or an arbitrary URL instead of a registry warns.

All three warn by default and fail soft. An unknown answer, a registry timeout or a missing publish timestamp, warns rather than blocks, so a slow or offline check never stops an agent. Install posture rides the same hook and the same fail-closed evaluation point as the corroboration check that catches known-malicious packages: two different supply-chain protections on one decision.

When warn is not enough, you opt a single rule up:

beekeeper posture enforce lifecycle-scripts --block

--warn lowers it back, and the unknown / fail-soft path still warns even under --block, so a registry outage never blocks an install. For a one-off, beekeeper posture allow <package> grants a scoped, audited exception. An allow is posture-scoped: it silences a posture warn but never downgrades a catalog malware block. Every override writes its own audit record.

The TUI learns to read your package managers

The new thing to look at is the posture view. beekeeper posture prints each detected package manager's own install behavior side by side with what Beekeeper enforces, and names the gaps it covers:

• npm runs scripts by default, does not enforce release age, and allows git deps, so Beekeeper covers all three.
• A hardened pnpm that honors minimumReleaseAge and blocks exotic subdeps is shown as aligned, with no gap to cover.
• bun lands somewhere in between depending on whether the Socket scanner is wired.

The same comparison appears as a read-only card in the dashboard, so the package-manager metadata sits right next to the live decision feed and the audit log. Read-only means read-only: the view reads your .npmrc, pnpm-workspace.yaml, and bunfig.toml and never writes them. beekeeper posture --full prints the full enforcement-boundary statement, which is honest about where posture is actually prevented versus where it is only observed and audited.

A correction: two things v1.0.0 already shipped

The launch post told the install-and-quarantine story well, but it under-sold two pieces of machinery that were already in the v1.0.0 signed release. They are the part that turns "noticed something" into "catches it faster next time," so here they are properly.

The first-responder loop

Confirm a threat once, catch it instantly after that. When a background catalog sync, or an adjudication pass that runs off the hot path, confirms an installed package malicious (two independent sources agree; one source can only warn), Beekeeper reacts on the same machine:

1. Confirm. The corroborated hit is recorded.
2. Contain, reversibly. It arms the TUI quarantine card for any matching install, and tightens the detection-only Sentry watch on that package's process subtree if the privileged layer is running. Quarantine is a reversible directory move with a restore manifest; the permanent purge always stays human-gated. Automatic moves are opt-in and dry-run by default.
3. Remember. It writes a local-only catalog overlay entry that survives the next catalogs sync, so the next install of that same package is caught the moment it lands, instead of waiting for the upstream feed to carry the signature.

The corpus flywheel

The remember step has a deeper, opt-in form. With the corpus enabled, Beekeeper appends every confirmed incident to a local record as a four-layer event: behavior, decision, outcome, and context. The outcome label is the one thing you cannot reconstruct after the fact, so the corpus captures it from the very first write. Adjudication assigns it off the hot path, never inside a synchronous tool-call check, and only at the same two-source confidence bar used everywhere else.

Nothing leaves the machine. The corpus and the catalog overlay are owner-only local files with no remote sink, and Beekeeper stores machine and repository identifiers as non-reversible HMAC fingerprints. You opt in from your config (corpus.enabled) or in the dashboard's first-responder settings (beekeeper dashboard --admin, then press s). There is no config set for it by design. Cross-machine sharing is a later milestone, not a capability that ships today.

Try it

go install github.com/home-beekeeper/beekeeper/cmd/beekeeper@v1.2.0
beekeeper hooks install --target claude-code
beekeeper posture

The third command shows you exactly how your package managers compare to what Beekeeper enforces, before you change anything. For the full picture:

• Getting started
• Security posture and known gaps
• v1.1.0 release notes
• Introducing Beekeeper, the original v1.0.0 story