Bug hunt ledger: Bun

[Mikola Lysenko (mikolalysenko)]

[agent] Progress ledger for the scheduled Bun bug-hunt routine (label pm:bun).

Last updated: 2026-10-07 (run 27), main 9c43dfc, latest release 4.0.0, latest Bun 1.4.2 (canary 1.4.3-canary.1).

Method (run 16 note: the sandbox shell exports BUN_OPTIONS=--smol, so unset it; run 17 note: on Bun ≥ 1.2, bunfig [install] saveTextLockfile = false writes a binary bun.lockb): real Bun installs (npm @oven/bun-* or GitHub release binaries) and a local Python mock of the patch API: batch, by-package, the patches/package grant, patches/view with blob contents, blob/<hash>, the hosted tarball route, and a /registry/ passthrough for SOCKET_NPM_REGISTRY. Set SOCKET_PATCH_SERVER_URL to the mock. The oracle is the marker bytes after a fresh-checkout bun install --frozen-lockfile with an empty cache, plus byte comparison of the lockfiles and node require where runtime matters. The repo's own matrix (scripts/backtest-bun.py, bun-compatibility.yml) already covers plain hosted and vendored shapes across Bun 0.8.1–1.4.2. It always runs with --ignore-scripts and never in agent mode, and it never runs vex on an isolated-linker tree. This ledger tracks what it doesn't.

Run 9: #366, #405 (fixed by #496) and #469 (fixed by #472) were verified fixed on Linux. Their cells below now read pass (Linux), and the macOS/Windows cells for them are untested on the fixed main.

Run 10: #599 still reproduces on 045d7ec. New: #635 (Bun ≥ 1.3.14 globalStore).

Run 11 (main unchanged at 045d7ec): #599 still reproduces. No new bugs. All the new cells pass: the run 11 section below, and the vendored row of the globalStore table.

Run 12 (main unchanged at 045d7ec, so no re-triage): no new bugs. Bun 1.1.39, the oldest release in range, is now covered and passes. All the new cells pass: the run 12 section below.

Run 13 (main unchanged at 045d7ec, so no re-triage): new #720. Lockfile-only discovery can't see hosted pins, so a hosted re-run in CI never picks up a superseding patch, and scan --mode vendored skips the takeover. Both report success. The other new cells pass: the run 13 section below.

Run 14 (main unchanged at 045d7ec, so no re-triage): new #739. A bun.lockb holding X@1.0.0 + X@1.0.0-beta.1 is refused as a metadata-hash mismatch, and hosted exits 0 with nothing patched (a regression since 4.0.0). Bun cells added to #626 (agent mode overwrites first-party workspace members). The other new cells pass: the run 14 section below.

Run 15 (main unchanged at 045d7ec, so no re-triage): new #764. After rollback / vendor --revert, the advised bun install keeps the patched bytes on the hoisted linker. The other new cells pass: the run 15 section below.

Run 16 (main unchanged at 045d7ec, so no re-triage): new #784. A vendored bun.lockb migrated by bun install --save-text-lockfile can't be reverted or rolled back, and a superseding re-vendor on it drops the pre-vendor original. remove added to #764. The other new cells pass: the run 16 section below.

Run 17 (main unchanged at 045d7ec, so no re-triage): new #803. A hosted or vendored workspace bun.lockb migrated to text by Bun 1.4.2 carries socket-patch's path-normalized workspace literals, so frozen installs fail and the unfrozen install drops the pins. The other new cells pass: the run 17 section below.

Run 18 (main unchanged at 045d7ec, so no re-triage): no new bugs. #764 is confirmed on a Bun 1.2.23 hoisted workspace. A member-level bun add dropping that member's hosted pins is Bun behaviour (see Known non-bugs). The other new cells pass: the run 18 section below.

Run 19 (main unchanged at 045d7ec, so no re-triage): no new issue. The yarn-classic handover #831 reproduces on Bun: a vendored tarball covered by .gitignore (*.tgz, vendor/, .socket/) exits 0, the commit drops it, and fresh frozen installs fail. That holds on text v1/v2, bun.lockb and an isolated workspace, and the Bun matrix is commented on #831. bun ci reproduces #803. The other new cells pass: the run 19 section below.

Run 20 (new main 6811b4e): #803, #739 and #720 were fixed by #811, #741 and #722, closed by the maintainers, and verified on Linux (#803 heal: hosted + vendored re-run; #720: lockfile-only bun.lockb supersede + vendored takeover). #599 and #497 still reproduce, and #497 also gives a false not_affected from lockfile-only default vex (commented). New: #861. A vendored re-run after a new dependent duplicates a bun.lockb tarball record, and isolated frozen installs fail EEXIST intermittently on 1.3.9/1.4.2. The other new cells pass: the run 20 section below.

Run 21 (new main 9c43dfc): #861 still reproduces. No new issue. The isolated-workspace member-run shape (hosted scan from a member: success, nothing pinned) is now tracked on #884 (commented), and is no longer a known non-bug. Three generic npm-family findings were handed to npm. The other new cells pass: the run 21 section below.

Run 22 (main unchanged at 9c43dfc, so no re-triage): no new bugs. All the new cells pass: multi-package and large-tree (express) bun.lockb hosted / vendored / takeover by writers 1.1.45–1.4.2, two versions of one patched package (nested + direct, and per workspace member), and scoped rollback / remove of one of two same-name pins. See the run 22 section below.

Run 23 (main unchanged at 9c43dfc, so no re-triage): no new issue. #861 also reproduces when bun add runs inside an existing member (commented). All the new cells pass: a vendored bun.lockb upgraded from binary format 2 to 3 by a newer Bun, bun.lockb takeovers by writers 1.1.39 / 1.3.4 / 1.3.10, globalStore + hosted workspace, and BOM / no-final-newline text locks. See the run 23 section below.

Run 24 (main unchanged at 9c43dfc, so no re-triage): no new bugs. The Bun 1.3.10 text-lock row is now covered (agent hoisted + isolated, hosted, rollback byte-exact). A hosted 1.2.0 workspace bun.lockb upgraded to format 3 by 1.4.2 picks up a superseding uuid. Concurrent and SIGKILLed vendored runs, mixed-case names (JSONStream) and catalogs all pass. See the run 24 section below.

Run 25 (main unchanged at 9c43dfc, so no re-triage): no new bugs. Mixed per-package modes (vendored ⇄ one package hosted, on text and bun.lockb, single and workspace, 1.2.23 / 1.3.9 / 1.4.2) pass, as do globalStore + vendored workspace lockb, overrides/resolutions and Bun lock re-serializations. #861 also reproduces under globalStore. bun remove of a vendored package leaves vendor --check red with a no-op remedy; it's generic, so it was handed to npm (related #900). See the run 25 section below.

Run 26 (main unchanged at 9c43dfc, so no re-triage): no new bugs. Explicit trustedDependencies and bun pm trust on hosted / vendored packages with a postinstall keep the script running (text + bun.lockb, single + workspace, 1.2.23 / 1.3.9 / 1.4.2). Mixed per-package modes plus a superseding uuid, re-run in each mode, pass. bun install --filter frozen installs on rewired workspaces pass. Probe-branch deletion is still refused (now by the sandbox's permission classifier). See the run 26 section below.

Run 27 (main unchanged at 9c43dfc, so no re-triage): new #992. Hosted bun.lock rollback / remove / hosted→vendored→vendor --revert write "" into the registry slot, and Bun 1.1.39–1.3.6 resolve "" against npmjs, ignoring the bunfig registry. Custom-registry projects then fail cold frozen installs (404), or silently bypass their mirror. Bun's own boundary is 1.3.7. Also passing: preinstall / install / postinstall on a scoped package with a bin and an unscoped preinstall-only package (hosted / vendored × text / bun.lockb × single / workspace × 1.2.23 / 1.3.9 / 1.4.2). In untrusted projects, rewiring doesn't start running scripts. bun pm trust and --filter work on 1.2.23. Plain re-installs leave a rewritten bun.lockb byte-identical. Bun 1.4.3-canary.1 passes hosted / vendored / agent, the takeover chain and rollback. Packages with only a sha1 shasum rewire fine. See the run 27 section below.

Coverage matrix

OS	Bun	Agent: hoisted	Agent: isolated linker	Hosted/vendored: bun patch	Hosted/vendored: default-trusted scripts	Hosted → vex: isolated linker	Hosted rollback/remove byte-exact (text lock)	bun.lockb takeover ⇄ revert
Linux	1.1.39 / 1.1.40	pass (1.1.39; run 12)	n/a	untested	untested	n/a	pass (v0 hosted + vendored; lockb refuses / semantic, as documented; run 12)	pass (1.1.39 single; workspace takeover refuses, documented; run 23)
Linux	1.1.45	untested	n/a	untested	pass	n/a	pass (v0)	pass (semantic; run 10)
Linux	1.2.23	pass	pass (opt-in; run 9; peer variants run 21)	fail #367	pass	pass, but fail #599 after an in-place reinstall	pass (v1 single + workspace; run 21)	pass (semantic; workspace takeover refuses, documented; run 21)
Linux	1.3.0–1.3.4	pass (1.3.0, 1.3.4)	pass (1.3.0, 1.3.4; run 9)	untested	pass	pass (1.3.0, 1.3.4; run 9)	pass (single: hosted + vendored; workspace: hosted, vendored refuses as documented)	pass (1.3.4 single + isolated workspace, semantic; run 23)
Linux	1.3.10	pass (workspace; run 24)	pass (workspace; run 24)	untested	untested	untested	pass (v1 workspace hoisted + isolated; single vendored + superseding uuid + revert byte-exact; run 24)	pass (single + isolated workspace, semantic; run 23)
Linux	1.3.5–1.3.9	pass (1.3.9; run 14)	pass (1.3.9; run 14; peer variants run 21)	fail #367 (1.3.9)	fail #371	untested	pass (1.3.9 v1 single + workspace; run 21)	pass (1.3.9 semantic; workspace takeover refuses, documented; run 21)
Linux	1.3.14	pass	pass (run 9)	fail #367	fail #371	pass fresh; fail #599 in place	pass (v1, workspace, catalog)	pass (semantic; vendored lockb isolated workspace too; run 10)
Linux	1.4.2	pass; fail #635 with globalStore; fail #626 (first-party workspace member)	pass (run 9; peer-hash entries, symlink backend)	fail #367 (text + lockb)	fail #371	pass fresh (text + lockb workspace); fail #599 in place	pass (v2, alias, overrides)	pass (semantic; not byte-exact, see Known non-bugs); workspace lockb → text migration healed by a re-run (#803 fixed, run 20); vendored re-run after a new dependent: fail #861 (isolated)
macOS	1.2.23	pass	fail #366	fail #367	untested	fail #405	untested	untested
macOS	1.3.4 / 1.3.5	untested	untested	untested	pass / fail #371	untested	untested	untested
macOS	1.3.14 / 1.4.2	pass	fail #366	fail #367	fail #371 (1.4.2)	fail #405	untested	untested
Windows	1.2.23	pass	fail #366	fail #367	untested	fail #405	untested	untested
Windows	1.3.4 / 1.3.5	untested	untested	untested	pass / fail #371	untested	untested	untested
Windows	1.3.14 / 1.4.2	pass	fail #366 (bunfig)	fail #367	fail #371 (1.4.2)	fail #405 (bunfig + default workspace)	untested	untested

Isolated-store edge cases after #496 (run 9, Linux)

Bun	agent: peer-hash +<hash> entries	agent: --backend=symlink	hosted vex fresh clone	hosted vex after in-place frozen reinstall (orphaned .bun entries)	vendored vex after in-place reinstall	bundled in a workspace member
1.4.2	pass	pass (no write-through)	pass	fail #599	false vendored_tree_out_of_sync (#599)	pass (hosted warns; vendored refuses)
1.3.14	untested	untested	pass	fail #599	untested	untested
1.2.23	untested	untested	pass	fail #599	untested	untested
macOS, Windows	untested	untested	untested	untested	untested	untested

Bun globalStore (machine-wide isolated store, Bun ≥ 1.3.14; run 10, Linux)

Bun	config	agent: sibling project untouched by apply/rollback	agent: transitive .bun entries patched	hosted vex on stale/unpatched transitive	vendored
1.4.2	bunfig globalStore = true	fail #635	fail #635	fail #635 (verified)	pass (run 11: sibling untouched, vex verified, no false out-of-sync)
1.4.2	BUN_INSTALL_GLOBAL_STORE=1	fail #635	fail #635	untested	untested
1.3.14	bunfig / env	fail #635	fail #635	fail #635	untested
1.4.2	bunfig globalStore = true, hosted isolated workspace	pass (run 23: sibling untouched, URL-keyed links)	n/a	pass (in-place not_affected; after rollback vex refuses)	—
1.3.13	bunfig (key ignored)	pass	pass	n/a	n/a
macOS, Windows	all	untested	untested	untested	untested

Hosted pins and registry credentials (run 10, Linux)

No Authorization header reaches the hosted tarball host for any of: bunfig default-registry token or basic auth, .npmrc host _authToken, global _authToken, always-auth, scoped .npmrc, [install.scopes] token, NPM_CONFIG_TOKEN. That holds on 1.4.2, 1.3.14, 1.2.23 and 1.1.45, cold-cache frozen installs: pass. Control: the same configs send Bearer to the configured registry.

Platform-specific optional deps (run 10, Linux)

os/cpu meta (fsevents, @esbuild/darwin-arm64, @esbuild/linux-x64). The hosted rewrite keeps the meta, and Linux frozen installs fetch only linux-x64 (patched), on 1.1.45 v0 + lockb, 1.2.23, 1.3.14, 1.4.2 text + lockb: pass. Hosted rollback is byte-exact (1.4.2): pass. minimumReleaseAge with hosted pins (1.4.2): pass.

Run 26 cells (Linux, main 9c43dfc)

Fixture: a fake registry on its own origin (bunfig [install] registry) serving hookpkg@1.0.0 (a postinstall that writes a file), plainpkg and otherpkg, plus the patch-API mock on a second origin. Oracle: fresh clone, cold bun install --frozen-lockfile (scripts enabled), the marker bytes, the postinstall's output file, bun pm untrusted, and vex.

Cell	1.2.23	1.3.9	1.4.2
explicit trustedDependencies: ["hookpkg"], hosted, text / lockb × single / workspace	pass	pass	pass
same, vendored	pass (text workspace refuses vendor_bun_workspace_unsupported, documented)	pass (same documented refusal on text workspace)	pass
no trust, rewire, then bun pm trust hookpkg, hosted + vendored × text / lockb (single)	untested	pass (script runs, vex attests)	pass
mixed modes + superseding uuid: vendored ×3 → get plainpkg --mode hosted → both hookpkg and plainpkg superseded → scan --mode vendored twice	pass (lockb single)	pass (text single); lockb isolated workspace: plainpkg stays hosted at the old uuid with redirect_revert_failed (documented: "workspace dependency behaviors it normalized … checkout remedy"), vex attests only the 2 vendored	pass (text + lockb single, text isolated workspace)
same, re-run scan --mode hosted twice	pass (lockb single; rollback refuses, documented)	pass (text single)	pass (text + lockb single, lockb isolated workspace)
cold frozen install with --filter m1 / --filter proj / --filter '!m1' / --filter './packages/*' on hosted + vendored workspaces (text + lockb)	untested	pass	pass

In every superseding cell the cold frozen install had the new markers, the postinstall ran, vex named the new uuids, vendor --check was clean, the stale artifacts were removed and the second re-run was a no-op. After vendor --revert + rollback the frozen install was unpatched; the lock differs from the pre-vendor one only by "" in the registry slot of entries that went through hosted mode (the custom-registry case in Known non-bugs).

Run 25 cells (Linux, main 9c43dfc)

Cell	Bun	Result
Vendored, then get <purl> --mode hosted for one package: cold frozen, vex (vendored + redirected), vendor --check, vendor --revert keeps the hosted pin, rollback	1.4.2 text v2 single + isolated workspace, 1.4.2 lockb single + isolated workspace, 1.3.9 text v1, 1.2.23 lockb	pass (text rollback byte-exact; lockb rollback refuses, documented)
Hosted, then get <purl> --mode vendored for one package: cold frozen, vex, rollback unwinds both	1.4.2 text v2 single + isolated workspace, 1.4.2 isolated workspace lockb, 1.2.23 lockb	pass
globalStore = true + vendored isolated workspace lockb: cold frozen, vex, vendor --check	1.4.2	pass
Same + #861 trigger (new member, vendored re-run)	1.4.2	fail #861 (EEXIST 2/4, 1/3)
overrides / resolutions forcing the patched version: hosted + vendored	1.4.2 text v2 + lockb, 1.2.23 lockb, 1.3.9 text v1	pass
After hosted / vendored: bun install --lockfile-only, --force, bun add <present>, bun remove <other>	1.4.2 text v2 + lockb	pass
bun remove <vendored pkg> → vendor --check	1.4.2 text v2 + lockb (npm 10 too)	red with a no-op remedy; generic, handed to npm (related #900)
get --mode agent on a vendored package → scoped rollback → bun install	1.4.2 lockb hoisted	patched bytes stay = #764; vex honest

Run 24 cells (Linux, main 9c43dfc)

Cell	Bun	Result
Hosted workspace bun.lockb written by 1.2.0 (format 2), bun add by 1.4.2 (format 3), superseding uuid, lockfile-only hosted re-run, cold frozen install, vex	1.2.0 writer; 1.4.2 reader	pass (updates names the new uuid, MARK2 installed, vex attests the new record's vuln; 1.2.0 can't read format 3, same as a socket-patch-free control)
Agent hoisted + isolated (text v1 workspace): apply, Bun cache stays unpatched, rollback	1.3.10	pass
Hosted text v1 workspace (hoisted + isolated): sha512 on every URL tuple, cold frozen install, rollback byte-exact	1.3.10	pass
Single text v1: hosted → vendored takeover, superseding-uuid vendored re-run, vendor --revert byte-exact	1.3.10	pass
3 concurrent vendored scans (text v2)	1.4.2	pass (one lock_held, the others serialize; vendor --check clean)
Vendored bun.lockb scan SIGKILLed at 5–60 ms: cold frozen install, re-run, vendor --check, vendor --revert (bun pm hash-string equals the original)	1.4.2	pass
Mixed-case legacy name JSONStream@1.3.5: hosted, vendored, vex, vendor --revert, agent + rollback, on text v2 + bun.lockb	1.4.2	pass
Catalogs (catalog: + named catalog:old) in an isolated v2 workspace: vendored, vendored → hosted takeover, rollback byte-exact	1.4.2	pass
--dry-run hosted / vendored on an isolated workspace bun.lockb (no writes); get <purl> --mode vendored (member copies written, only that package wired)	1.4.2	pass
Mixed per-package modes (vendored lockb, then get <purl> --mode hosted for one package)	1.4.2	blocked (the session's permission classifier refused the fixture step)

Run 23 cells (Linux, main 9c43dfc)

Cell	Bun	Result
Vendored bun.lockb format 2, upgraded to format 3 by a 1.4.2 bun add: re-run, vendor --revert, scoped rollback / remove, vendored → hosted	writers 1.1.45 (single + workspace) / 1.2.0 (workspace); readers 1.4.2 / 1.3.9 / 1.2.23	pass (revert matches the control hash)
bun.lockb hosted, hosted → vendored, vendored → hosted, vendor → vendor --revert	writers 1.1.39 / 1.3.4 / 1.3.10, single + workspace; readers writer + 1.4.2	pass (1.1.39 workspace takeover refuses, documented)
globalStore = true + hosted isolated workspace: sibling project, in-place vex, rollback	1.4.2	pass
Text bun.lock with a UTF-8 BOM, or with no final newline: hosted, rollback, vendored, revert (byte-exact)	1.4.2	pass
#861 via bun add inside an existing member	1.4.2 / 1.3.9 isolated lockb	fail #861 (commented)
Bun 1.4.3 canary	1.4.2-canary.20261005.1	blocked (session policy refused running an unreleased binary)

Run 22 cells (Linux, main 9c43dfc)

Cell	Bun	Result
Multi-package bun.lockb (5 patches, scoped + nested ms): hosted, vendored, vex, semantic vendor --revert	writers 1.1.45 / 1.2.23 / 1.4.2; readers 1.1.45 / 1.2.23 / 1.4.2	pass
Nested ms@2.1.2 + direct ms@2.1.3, both patched: text v2 + lockb × hoisted + isolated × hosted + vendored; hosted rollback pkg:npm/ms@2.1.2 keeps the other pin	1.4.2	pass
express tree (71 packages, 7 patches): hosted lockb, vendored lockb, hosted → vendored → vendor --revert	writers 1.1.45 / 1.2.23 (isolated) / 1.4.2 (isolated); readers writer + 1.4.2	pass
Vendored non-workspace isolated lockb → bun add a new dependent → vendored re-run → 4× cold frozen	1.4.2	pass (no #861 duplicate outside workspaces)
Workspace members on different patched versions (ms@2.0.0 / ms@2.1.3): hosted lockb, vendored lockb, vendored text v2, hosted text v1	writers 1.1.45 / 1.2.23 / 1.4.2 (hoisted + isolated); readers 1.1.45 / 1.2.23 / 1.3.9 / 1.4.2	pass
Scoped remove pkg:npm/ms@2.0.0 on those vendored workspace lockbs: member copies removed, other version kept, vendor --check	1.1.45 hoisted / 1.4.2 isolated	pass
Agent apply → bun install --force → vex refuses → apply re-patches	1.4.2 hoisted + isolated	pass

Run 21 cells (Linux, main 9c43dfc)

Cell	Bun	Result
Agent over isolated peer-variant entries (+<hash> ×2): apply, no cache write-through, vex, rollback; a new peer variant → vex refuses → apply patches only it	1.4.2 / 1.3.9 / 1.2.23	pass
File modes after the #858 write core: bun.lock / bun.lockb 0664 (hosted + vendored); agent bin file 0755 / 0777 through apply + rollback	1.4.2	pass
Hosted rollback byte-exact + frozen install, text v1 single + workspace	1.2.23 / 1.3.9	pass
bun.lockb hosted → vendored → revert; vendored → hosted → rollback refusal; single + workspace	1.2.23 / 1.3.9	pass (as documented)
Dual bun.lock + stale bun.lockb: hosted / vendored, vex, vendor --check, frozen	1.4.2	pass
Symlinked bun.lockb / bun.lock, vendored	1.4.2	pass (refused; text leaves an orphan artifact, handed to npm)
Hosted scan / get --mode hosted from an isolated workspace member	1.2.23 / 1.3.9 / 1.4.2	fail #884 (commented)
bun.lock + package-lock.json vendored → vendor --check	1.4.2	wrong message, no-op remedy (generic, handed to npm)
bun.lock wired + stale package-lock.json without the package → lockfile-only vex	1.4.2	attests (generic cross-lock rule, handed to npm)

Run 20 cells (Linux, main 6811b4e)

Cell	Bun	Result
Vendored workspace bun.lockb → new member depending on the patched pkg → bun install → vendored re-run → fresh frozen install	1.4.2 / 1.3.9 isolated	fail #861 (EEXIST, ~50%)
Same	1.2.23 isolated, 1.4.2 hoisted, 1.4.2 text v2 isolated; hosted on 1.2.23 / 1.3.9 / 1.4.2	pass
#803 heal (migrated by 1.4.2, then re-run): hosted + vendored; hosted rollback after the heal	writer 1.4.2	pass
#803 heal shapes: scoped member, packages/*/*, dir with space/ü/#, peer workspace edge, nameless root, dir ≠ name	1.4.2	pass
catalog: + named catalogs: workspace bun.lockb: hosted, frozen by each reader	writers 1.4.2 / 1.3.9 / 1.2.23	pass (takeover refuses, documented)
Vendored isolated catalog bun.lockb: frozen, vex, byte-exact revert; deleted member mirror → vendor --check / vex fail closed → repair	1.4.2	pass
#720: lockfile-only bun.lockb hosted supersede; lockfile-only vendored takeover	1.4.2	pass
Lockfile-only URL-only dependency (now inventoried): hosted / vendored	1.4.2 text	pass (same as with node_modules)
#497 shape, lockfile-only default vex	1.4.2 text	fail #497 (attests)

Run 19 cells (Linux)

Cell	Bun	Result
Vendored + .gitignore *.tgz / vendor/ / .socket/ → commit → fresh-clone frozen install	1.4.2 text v2 + bun.lockb, 1.2.23 text v1, 1.1.45 bun.lockb, 1.4.2 v2 isolated workspace	fail #831 (scan exit 0, no warning; vendor --check 0 under vendor/ / .socket/; vex fails closed)
bun ci on the #803 shape (workspace bun.lockb + workspace:*, hosted, migrated to text by 1.4.2)	1.4.2	fail #803 (control without socket-patch passes)
Superseding uuid on a hosted workspace bun.lockb re-serialized by a root bun add; fresh frozen install; vex	writers 1.4.2 / 1.1.45, readers writer + 1.4.2	pass
Vendored clone with core.autocrlf=true: frozen, vendor --check, vex, vendor --revert, post-revert install	1.4.2 / 1.2.23 text	pass (mixed EOL, see Known non-bugs)
Hosted clone with core.autocrlf=true: frozen, vex, rollback (CRLF kept), post-rollback install	1.4.2 text v2	pass

Run 18 cells (Linux)

Cell	Bun	Result
Lockfile-only hosted re-run with --max-new-patches 1 over 2 hidden pins	1.4.2 v2	pass (nothing deferred or unwired; lock unchanged)
Workspace bun.lockb without inter-workspace deps → --save-text-lockfile by 1.4.2 → fresh frozen install	writers 1.1.45 / 1.4.2	pass
Hosted rollback → bun install, workspace (hoisted default)	1.2.23 v1	fail #764
bun add inside a workspace member after hosted	1.2.23 / 1.3.14 text v1, 1.4.2 text v2 + bun.lockb	member pins dropped by Bun; re-run heals; no false vex (Known non-bugs)
Symlinked text bun.lock, hosted	1.4.2	pass (redirect_symlinked_file_unsupported, nothing written)
Scoped rollback <purl> with 2 hosted pins → frozen install; then full rollback byte-exact	1.2.23 v1 / 1.4.2 v2	pass
Superseding uuid on a hosted workspace bun.lockb re-serialized by bun add	1.1.45 / 1.4.2 writers	blocked (session permission policy)

Run 17 cells (Linux)

Cell	Bun	Result
Hosted bun.lockb → --save-text-lockfile → hosted → vendored takeover → fresh frozen install → vendor --revert	1.1.45 → 1.4.2	pass (in-place reinstall afterwards = #764)
Hosted workspace bun.lockb → --save-text-lockfile → fresh frozen install	writers 1.1.45 / 1.2.23 / 1.3.14 / 1.4.2, migrated by 1.4.2	fail #803 (migrated by 1.3.14: pass)
Vendored workspace bun.lockb → --save-text-lockfile → fresh frozen install	writers 1.1.45 / 1.4.2, migrated by 1.4.2	fail #803
Lockfile-only get <purl> --mode hosted picks up a superseding uuid; frozen install; rollback	1.4.2 v2	pass

Run 16 cells (Linux)

Cell	Bun	Result
Hosted bun.lockb → bun install --save-text-lockfile: pins kept, install patched, list, rollback, fresh frozen install	writer 1.1.45, migrated by 1.4.2	pass
Vendored bun.lockb → --save-text-lockfile: vendor --revert / rollback / hosted takeover	writers 1.1.45 / 1.2.23 / 1.4.2 × migrated by 1.2.23 / 1.4.2	fail #784
Same, then a superseding re-vendor → vendor --revert → bun install	1.1.45→1.4.2, 1.2.23→1.3.14, 1.4.2→1.4.2	fail #784 (exit 0, still vendored); controls (text from the start, unmigrated lockb) pass
Hosted workspace, fresh frozen --filter <name> / --filter ./path / --production	1.2.23 / 1.3.14 / 1.4.2	pass
remove <purl> → advised frozen install, hoisted, hosted + vendored	1.4.2	fail #764 (no warning at all)

Run 15 cells (Linux)

Cell	Bun	Result
bun.lockb meta hash, numeric/alphanumeric prerelease pairs (beta.2/beta.10, 1/alpha, rc.1/rc.1.0, x.9/x.10/x.100): hosted + frozen installs	writers 1.1.45 / 1.2.23 / 1.3.9 / 1.4.2	pass
Patched package with optionalPeers, optionalDependencies, bin; npm aliases beside the direct copy: hosted, frozen install, vex	text 1.2.23 / 1.3.9 / 1.4.2; lockb 1.1.45 / 1.4.2	pass
Agent ⇄ hosted takeovers, then vex / apply / rollback	1.4.2	pass
Hosted scan → in-place warm frozen install (hoisted); superseding uuid in place	1.1.45 / 1.2.23 / 1.3.9 / 1.4.2; 1.4.2	pass
rollback / vendor --revert → advised in-place bun install restores upstream bytes, hoisted	1.1.45 (lockb vendored) / 1.2.23 / 1.3.9 / 1.3.14 / 1.4.2	fail #764
Same, isolated linker	1.2.23 / 1.4.2	pass

Run 14 cells (Linux)

Cell	Bun	Result
Prerelease / build-metadata (+) / legacy-uppercase / scoped dotted names: hosted, vendored, agent (isolated), vex, rollback, vendor --revert	1.4.2 text v2	pass
Same five on bun.lockb: hosted, frozen installs by each reader, hosted → vendored → revert	writer 1.1.45; readers 1.1.45 / 1.2.23 / 1.3.9 / 1.4.2	pass (revert semantic)
Agent / hosted / rollback	1.3.9 v1, isolated	pass
Root X@1.0.0-beta.1 + nested X@1.0.0 (also under a scoped parent), text lock	1.4.2	pass
Same pair in bun.lockb (patch on any package)	writers 1.1.45 / 1.2.23 / 1.3.9 / 1.4.2	fail #739 (hosted exit 0, vendored exit 1; v4.0.0 passes)
Agent mode with a workspace member / link: target matching a patched name@version	1.1.45 / 1.2.23 / 1.3.9 / 1.4.2 (hoisted + isolated)	fail #626 (npm-owned; file: passes, hosted / vendored safe)

Run 13 cells (Linux)

Cell	Bun	Result
Lockfile-only hosted re-run picks up a superseding patch	1.4.2 text v2, 1.3.14 v1 workspace, 1.1.45 bun.lockb	fail #720 (with node_modules: pass)
Lockfile-only scan --mode vendored over hosted pins (takeover)	1.4.2 text v2, 1.1.45 bun.lockb	fail #720 (vendor command: pass)
Lockfile-only vendored re-run picks up a superseding patch	1.4.2 text v2	pass
SIGKILL during hosted → vendored takeover (52×) and vendored → hosted (30×)	1.4.2 text v2	pass (installable, honest vex, exact heal)
SIGKILL during agent apply on an isolated workspace (~200×)	1.4.2	pass (no torn files; heals with apply or a --json re-run)
repair on a vendored bun.lockb isolated workspace (deleted / corrupt artifact)	1.1.45 writer, 1.4.2 reader	pass
bun ci and --production frozen installs with hosted pins	1.4.2 v2, 1.3.14 v1	pass

Run 12 cells (Linux)

Cell	Bun	Result
Text v0 + bun.lockb: hosted / vendored scan, frozen installs, vex, idempotent re-run, rollback / revert; agent scan → vex → rollback	1.1.39 (oldest in range), 1.1.40	pass
bun.lockb with overrides + trustedDependencies, hosted and vendored	writers 1.2.23 / 1.3.9; readers 1.2.23, 1.3.9, 1.3.10, 1.3.14, 1.4.2	pass
v2 isolated workspace, member dirs a b ü and c#d, scoped patched dep: hosted, hosted → vendored, byte-exact vendor --revert, scoped remove	1.4.2 (text); 1.4.2 lockb read by 1.2.23 / 1.3.14 / 1.4.2	pass
get by CVE / GHSA / UUID / PURL / scoped name, hosted + vendored	1.4.2	pass
SIGKILL mid scan (hosted, vendored), mid rollback, mid vendor --revert; then re-run	1.4.2	pass (every intermediate lock installable and attested consistently; only a 0-byte stage temp file is left over)
Vendored artifact deleted or corrupted → vex skip → repair rebuilds	1.4.2	pass
--offline / --prefer-offline with hosted pins + warm registry cache	1.4.2	pass (--offline fails closed)
Bun auto-migration of a hosted yarn.lock	1.4.2	fail-closed until a re-run of scan --mode hosted heals it (same as package-lock.json)
Bun auto-migration of a hosted pnpm-lock.yaml	1.3.14 / 1.4.2	Bun fails with IntegrityCheckFailed (see Known non-bugs)
Digest-less hosted re-save after bun add → re-run re-pins; lockfile-only vex attests nothing without a pin	1.2.23 / 1.3.9 (1.3.10 keeps the digest)	pass
ignorePaths over workspace members (hosted + agent)	1.3.14 text v1, 1.1.45 lockb	pass
Multi-project policy (includePaths, minSeverity flag > file, !/tests/)	1.1.45 lockb	pass

Run 11 cells (Linux)

Cell	Bun	Result
Hosted text lock, patched package with bin (semver): meta kept, .bin linked after frozen install	1.4.2 (v2)	pass
Hosted bun.lockb (1.1.45 writer) with bin + scoped packages, frozen install by each reader	1.1.45 / 1.2.23 / 1.3.14 / 1.4.2	pass
bun update drops hosted pins; vex then refuses (manifest_not_found), no false attestation	1.4.2	pass
v0 text lock (hosted and vendored), then a plain install migrating it to v1; pins survive; rollback / vendor --revert after the migration	1.2.23 / 1.3.14 / 1.4.2	pass
Name-colliding alias ("left-pad": "npm:is-number@6.0.0"), hosted + vendored	1.4.2	pass (agent: #356)
v2 isolated workspace with nested version keys: hosted → vendored takeover → vendor --revert (byte-exact pre-hosted lock)	1.4.2	pass
bun.lockb workspace with nested version keys, hosted (writers 1.1.45 and 1.4.2)	readers 1.1.45–1.4.2	pass (1.1.45 can't read a 1.4.2 lockb, Bun limitation)
Concurrent hosted scans (lock_held); lockfile-only hosted vex	1.4.2	pass
Bun auto-migration of a hosted package-lock.json	1.4.2	fail-closed until a re-run of scan --mode hosted heals it (see Known non-bugs)

Global mode (-g, agent; run 3)

OS	Bun	default layout: scan report / apply / vex / rollback / get	BUN_INSTALL_BIN set	BUN_INSTALL_GLOBAL_DIR set	npm-installed bun (shim only)	-g --mode hosted refusal
Linux	1.1.45 / 1.2.23 / 1.3.14 / 1.4.2	pass	fail #443	fail #443	pass (1.4.2)	pass
macOS	1.1.45 / 1.2.23 / 1.3.14 / 1.4.2	pass	fail #443	fail #443	pass	pass
Windows	1.3.14 / 1.4.2	pass	fail #443	fail #443	fail #434 (bun.cmd)	pass
Windows	1.1.45 / 1.2.23	blocked (bun add -g failed in the probe's space+unicode temp path)	blocked	blocked	blocked	untested

Untested: a non-writable global dir, a symlinked BUN_INSTALL, and Bun 1.0.x.

Bundled dependencies (bundled: true lock entries; run 4)

OS	Bun	lock	hosted scan warns/skips	vendored scan warns/skips	bundled copy patched after frozen install	vendored vex	hosted vex	hosted vex --no-verify
Linux	1.1.45	text v0 / lockb	fail #469 (lockb: pass after #472, run 9)	fail #469 (lockb: pass, run 9)	fail #469	fail #469 (attests; lockb: pass, run 9)	pass (not_applied)	fail #469 (lockb: pass, run 9)
Linux	1.2.23 / 1.3.14	text v1	fail #469	fail #469	fail #469	fail #469	pass	fail #469
Linux	1.4.2	text v2 / lockb	pass (run 9, #472)	pass (run 9)	n/a (warned)	pass (run 9)	pass	pass (run 9)
macOS, Windows	all	all	untested	untested	untested	untested	untested	untested

Non-registry copies of a patched name@version (run 5, Linux)

Bun	lock	URL tgz + nested registry copy: scan warns	root copy patched after frozen install	vendored vex	hosted vex	hosted vex --no-verify	URL-only refusal
1.1.45	text v0	fail #497	fail #497	fail #497 (attests)	pass (not_applied)	fail #497	untested
1.2.23	text v1	fail #497	fail #497	fail #497	pass	fail #497	untested
1.3.14	text v1	fail #497	fail #497	fail #497	pass	untested	untested
1.4.2	text v2 (URL and file: tgz)	fail #497	fail #497	fail #497	pass	fail #497	pass
1.1.45 (read by 1.1.45 / 1.2.23 / 1.4.2)	bun.lockb (URL tgz; run 6)	fail #497	fail #497	fail #497	pass	fail #497	untested
any	github: tuples	untested	untested	untested	untested	untested	untested
macOS, Windows	all	untested	untested	untested	untested	untested	untested

socket.yml policy and staged rollout (run 6, Linux)

Bun	lock	hosted maxNewPatches: 1 advance	vendored maxNewPatches: 1 advance	vendored → hosted takeover under cap	ignorePackages keeps pin	enabled: false writes nothing	hosted upgrade (new uuid)	rollback after upgrade
1.1.45	lockb (workspace)	pass	untested	untested	pass	pass	pass	n/a (refuses, documented)
1.3.14	text v1 (workspace)	pass	untested	untested	untested	untested	pass	pass (byte-exact)
1.4.2	text v2 (workspace)	pass	pass	pass	pass	pass	untested	untested
macOS, Windows	all	untested	untested	untested	untested	untested	untested	untested

socket.yml across several independent Bun projects in one repo (run 7, Linux)

Bun	lock	includePaths (hosted, PATH glob)	shared maxNewPatches across dirs	minSeverity flag > env > file	ignorePaths keeps pins byte-identical	!/tests/ re-include	**/bun.lockb marker	vendored PATH glob
1.4.2	text v2	pass	pass	pass	pass	pass	n/a	pass
1.1.45	lockb	untested	untested	untested	untested	untested	pass	n/a
macOS, Windows	all	untested	untested	untested	untested	untested	untested	untested

Agent mode applies path policy only at the scan root, so nested independent projects are always patched. That's generic, not Bun-specific: handed to npm (entries/npm/20261002T072532Z-from-bun.md).

Workspace members under ignored paths, and growth after a scan (run 8, Linux)

Bun	lock	tests/ member: agent	tests/ member: hosted (frozen patched)	ignorePaths over members keeps them (agent / hosted / vendored)	rollback / revert byte-exact	re-run rewires a newly added registry copy	dual package-lock.json + bun.lock hosted
1.4.2	text v2	pass	pass	pass	pass	pass	pass (rollback byte-exact, .npmrc removed)
1.3.14	text v1	untested	pass	untested	untested	untested	untested
1.1.45	lockb	untested	pass	untested	n/a (refuses, documented)	pass	untested
macOS, Windows	all	untested	untested	untested	untested	untested	untested

Between a scan and its re-run, an unwired registry copy of a patched name@version in the same lock is still attested by vendored vex and by hosted vex --no-verify. npm does the same, so it's handed to npm (entries/npm/20261002T133747Z-from-bun.md), not filed as a Bun bug.

Also passing in run 6: a dual-lock checkout (bun.lock + a stale bun.lockb, where Bun ≥ 1.2 reads bun.lock and hosted rewrites only it), and global mode with a symlinked BUN_INSTALL (1.4.2: agent scan, vex -g, rollback -g).

Lock-shape edge cases (run 5, Linux)

• CRLF bun.lock + CRLF package.json (1.1.45 v0, 1.3.14, 1.4.2): hosted scan → frozen install → rollback, and vendored → vendor --revert. Both byte-exact: pass.
• bun install --yarn (sibling yarn.lock), on 1.1.45 lockb, 1.2.23 and 1.4.2: hosted rewires both locks; lockb rollback refuses and touches neither file: pass.
• [install.scopes] custom-registry scope (1.3.14, 1.4.2): hosted rewrite and byte-exact rollback: pass.
• 1.1.45 binary workspace lock, hosted, read by 1.1.45 / 1.2.23 / 1.3.14 / 1.4.2. Frozen installs are patched, the takeover refuses as documented, and vex is correct: pass.
• bun add after hosted (all four versions; the pins survive) and after vendored (digest-less re-save on < 1.3.10, healed by the re-run): pass.

Takeovers and vendored VEX (run 4, Linux)

• Hosted → vendored on a v1 workspace lock (1.3.14): pass. Refuses before any write; dry-run parity is as documented.
• Vendored + isolated linker, stale tree → vendored_tree_out_of_sync is missing (1.4.2): fail, under With Bun's isolated linker, vex attests a hosted patch as not_affected (verified) while the installed copy under node_modules/.bun is still unpatched (v5 regression) #405 (comment). Hoisted control: pass.

Other passes (Linux, 1.4.2 unless noted):

• Run 1: agent scan --global, and the (pre-v5) setup hook.
• Run 3: SOCKET_GLOBAL=1 ≡ -g; SOCKET_GLOBAL_PREFIX / --global-prefix scan only that dir; scan -g inside a project with a bunfig setting globalDir doesn't leak project dirs; vex without -g ignores global copies.
• Run 2:
  • Agent scan → vex → rollback, with no cache write-through.
  • remove, repair and list on hosted pins.
  • Hosted bun.lockb idempotency, --dry-run, and the rollback refusal.
  • Vendored catalog: and overrides.
  • Lockfile-only vendored scan on 1.1.45 v0 with a CRLF + BOM package.json.
  • A corrupt served tarball rejected on 1.3.9, 1.3.10 and 1.4.2, text + lockb.

Run 27 (Linux, main 9c43dfc)

Cell	Bun	Result
Hosted/vendored rewire of a scoped package with preinstall/install/postinstall + bin, and an unscoped preinstall-only package; trustedDependencies; cold frozen install runs the same scripts, links .bin, is patched, vex attests	1.2.23 / 1.3.9 / 1.4.2 × text / lockb × single / workspace (pre-v2 text workspace vendored refuses, documented)	pass
Same, untrusted project (no trustedDependencies): no scripts run before or after the rewire	1.2.23 / 1.3.9 / 1.4.2 × text / lockb	pass
bun pm trust after rewiring; --frozen-lockfile --filter (m1, proj, !m1, ./packages/*)	1.2.23	pass
Plain (non-frozen) bun install on a rewritten bun.lockb leaves it byte-identical (same bun pm hash)	1.2.23 / 1.3.9 / 1.4.2, hosted + vendored, single + workspace	pass
Hosted / vendored / agent cells, the hosted→vendored→revert→hosted→rollback chain	1.4.3-canary.1 (text v2 + lockb)	pass (lockb rollback refuses, documented)
sha1-only package (registry has shasum, no integrity): hosted / vendored rewire + frozen install	1.2.23 / 1.3.9 / 1.4.2 × text / lockb	pass
Hosted text-lock rollback / remove / takeover-revert with a bunfig custom registry, then a cold frozen install	1.1.45 / 1.2.23 / 1.3.6	fail #992
Same	1.3.7 / 1.4.2	pass (only the "" diff)

Backlog

0. Maintainer request (partly covered in runs 3 and 6): global (-g) mode for hosted patches. Still to do: a non-writable global dir must fail loudly (needs a probe; the sandbox runs as root); Windows 1.1.45/1.2.23 with an ASCII temp path; Bun 1.0.x. Global mode misses every Bun global package when BUN_INSTALL_BIN or BUN_INSTALL_GLOBAL_DIR is set: scan -g reports success with nothing found, get -g / vex -g patch and attest nothing #443 is still open; re-test On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 (bun.cmd) on Windows now that Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 has landed. Checklist: the 20261001T040000Z entry.
1. A maintainer needs to delete the probe branches bughunt/bun/20260930-default-trust, bughunt/bun/20260930-isolated-bunpatch, bughunt/bun/20261001-vex-isolated and bughunt/bun/20261001-global-dirs. Deletion is still refused from the sandbox (runs 7–26; run 26: blocked by the session permission classifier), so no new probes until then.
2. Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861: macOS/Windows; re-test when fixed (the existing-member bun add variant reproduces, run 23). Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884 (Bun member shape) and Hosted and vendored Bun rewiring silently discards the project's own bun patch (patchedDependencies): fresh frozen installs drop the user's patch with exit 0 #367 (PR Fix Bun rewiring dropping the project's bun patch (#367) #873): re-test when merged.
3. Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831: re-test on Bun (text, bun.lockb, workspace) once Fix vendored npm-family tarballs dropped by .gitignore (#831) #837 lands. After a Bun rollback or vendor --revert, the advised bun install keeps the patched bytes installed on the hoisted linker (Bun reports "no changes") #764 follow-up: macOS/Windows. Real Windows autocrlf checkouts.
4. Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861, Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831, After Bun migrates a vendored bun.lockb to bun.lock (bun install --save-text-lockfile), vendor --revert and rollback fail, and a superseding re-vendor drops the pre-vendor original so revert exits 0 with the project still vendored #784, After a Bun rollback or vendor --revert, the advised bun install keeps the patched bytes installed on the hoisted linker (Bun reports "no changes") #764, With Bun's globalStore (Bun ≥ 1.3.14), agent mode patches and rolls back every other project sharing the store, and vex attests unpatched transitive copies as not_affected #635, With Bun's isolated linker, vex refuses every hosted patch as not_applied after the usual in-place bun install, because it checks orphaned node_modules/.bun registry entries that Bun never removes (regression from #496) #599 and Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497: re-test when fixed. Agent-mode apply writes through node_modules links into first-party source (npm workspace members, file: deps, npm link targets), overwriting the user's code, and rollback restores upstream bytes instead #626 on Bun once PR Fix agent mode patching linked first-party source (#626) #634 merges. Also globalStore + workspaces and globalStore on macOS/Windows. (Fix npm store copies missed by agent apply and vex (#601, #603) #605/Fix store-copy fold dropping copy writes (#756, #772) #774 store copies on Bun peer-variant entries: pass, run 21.)
5. macOS/Windows re-runs of the Bun isolated linker: transitive packages under node_modules/.bun are "not installed" in agent mode, and scan --mode agent exits 0 with them unpatched #366 / With Bun's isolated linker, vex attests a hosted patch as not_affected (verified) while the installed copy under node_modules/.bun is still unpatched (v5 regression) #405 / Bun hosted and vendored rewiring rewrites bundled: true lock entries that Bun never fetches: the bundled copy stays unpatched, scan reports success, and vendored vex attests not_affected #469 / After Bun 1.4 migrates a hosted workspace bun.lockb to bun.lock, bun install --frozen-lockfile fails and Bun's suggested bun install silently drops the hosted pins #803 fixes (Windows isolated uses junctions).
6. Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 github: tuples (needs a probe).
7. Hosted rollback on real macOS and Windows checkouts.
8. Bun 1.4.3 when stable (1.4.3-canary.1 passes, run 27). Hosted Bun rollback/remove writes an empty registry slot that Bun < 1.3.7 resolves against npmjs, so custom-registry projects can't frozen-install after a revert #992: re-test when fixed, including [install.scopes] and NPM_CONFIG_REGISTRY variants and the 1.1.45 remove / takeover cells. (Lifecycle scripts and scoped packages with scripts on bun.lockb: pass, run 27.) (Mixed modes, globalStore + vendored workspace lockb: pass, run 25. Superseding uuids in mixed modes, explicit trustedDependencies, bun pm trust, --filter: pass, run 26.)
9. Digest boundary with a valid substitute tarball, 1.3.9 text lock vs 1.3.10 (low priority, documented limitation).

Known non-bugs

• A registry document with only a sha1 shasum and no integrity makes the hosted text-lock restore refuse with the registry records no integrity and the checkout remedy (fail closed, generic npm-family code). npmjs has backfilled integrity on old versions (minimist 0.0.8, left-pad 0.0.3, qs 0.6.6, lodash 1.0.0 all checked), so it's only reachable on bare private registries. Not filed (run 27).

• Lifecycle prepare doesn't run for registry or tarball dependencies, on any Bun version, with or without socket-patch.

• patches-api.socket.dev is blocked by the sandbox proxy. Mock the API. Also, the CLI's reqwest can't reach registry.npmjs.org from the sandbox (curl can), so hosted rollback/remove need SOCKET_NPM_REGISTRY pointed at a local passthrough. Without it you get cannot restore … error sending request, which is a sandbox artifact.

• Agent rollback → missing_blob when the mock serves no before-blob (fixture limit).

• v5 rollback removes the rolled-back entries from .socket/manifest.json, so a later apply is a success no-op (CLI_CONTRACT rollback row).

• Hosted bun.lockb pins: rollback / remove refuse with the git checkout -- bun.lockb remedy (documented). After a hosted → vendored → vendor --revert round trip, bun.lockb is semantically identical (same bun pm hash and yarn dump) but not byte-identical: its string buffer keeps the dead URLs. The doc promises a byte-exact registry record, not the whole file.

• Bun 1.2.23 workspaces default to the hoisted layout (isolated only via linker = "isolated"). From Bun 1.3.x a fresh workspace lock defaults to isolated.

• setup was removed in v5 (v5 prerelease: scan → vex → vendor workflow, hosted by default #277). The run-1 setup pass is obsolete.

• esbuild after rewiring is listed by bun pm untrusted but has no observable effect. Use better-sqlite3 to observe On Bun ≥ 1.3.5, hosted and vendored rewiring drops Bun's default trust, so install scripts of patched packages (better-sqlite3, esbuild, sharp…) are silently blocked #371.

• Documented refusals (docs/testing/bun-compatibility.md): a version-0 workspace lock in hosted mode (redirect_bun_workspace_unsupported), a pre-v2 workspace lock in vendored mode (vendor_bun_workspace_unsupported), and missing digest enforcement for text-lock URL/local tuples on Bun < 1.3.10.

• Agent-mode npm aliases under Bun are npm agent-mode apply never patches an npm-aliased install (lp@npm:left-pad), yet VEX attests the package not_affected #356 (npm-owned).

• --global-prefix must name the node_modules dir itself (~/.bun/install/global/node_modules). Its parent scans 0 packages; the flag is documented as the packages root.

• -g combined with --mode hosted is a clap-level conflict: plain-text error, exit 2, no JSON envelope even with --json. Consistent with other usage errors.

• Vendored scan --dry-run exits 0 with status: success and would_refuse while the real run exits 1 with partial_failure, for the same Bun preflight refusal. Documented (CLI_CONTRACT would_refuse).

• Vendored vex attests from the committed artifact even when the installed tree is stale. By design: only a vendored_tree_out_of_sync warning is owed.

• Hosted default vex on a bundled-copy project correctly refuses (not_applied). Bun hosted and vendored rewiring rewrites bundled: true lock entries that Bun never fetches: the bundled copy stays unpatched, scan reports success, and vendored vex attests not_affected #469 is about vendored mode and --no-verify.

• bun pm bin -g ignores a project-local bunfig.toml, so scan -g inside a project can't be redirected by the project.

• Vendored, then bun add, on Bun < 1.3.10 re-saves the local tuples without sha512. That's documented ("Digest-less re-saves"): the vendored re-run reports already_vendored and re-pins the digest.

• Bun records "" as the registry field of a tuple even when it came from an [install.scopes] or custom default registry, so rollback restoring "" is correct.

• On a bun install --yarn project, hosted rollback restores bun.lock byte-exact but adds a #<sha1> fragment to Bun's yarn.lock resolved lines. It's semantically equivalent and yarn-classic's rewriter, so it isn't filed as a Bun bug.

• Mock fixture: build the patched tarball with a fixed gzip mtime. Otherwise a mock restart changes its sha512 and later installs fail IntegrityCheckFailed.

• link: deps need bun link registration, and github: deps don't resolve in the sandbox. Both are environment limits.

• scan <workspace-member> (e.g. scan packages/a) with vendored refusing vendor_lockfile_missing is pinned behaviour. The hosted side (success, 0 redirected) is NOT a non-bug any more: since run 21 it's tracked on Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884 (the isolated-workspace Bun matrix is commented there).

• Mode-less scan -g is report-only. Use --mode agent to patch global copies. -g agent runs record the global copies in the cwd's .socket/manifest.json (by design).

• A v1/v2 text bun.lock can't be read by Bun 1.1.45 (lockfile had changes, but lockfile is frozen) even without socket-patch. When bun.lock and bun.lockb are both present, Bun ≥ 1.2 reads bun.lock.

• Mock fixture: SOCKET_PATCH_SERVER_URL must name the same origin across runs. A mock on another port makes the earlier pins non-hosted.

• A hosted scan at a repo root that is itself a Bun project crawls nested independent projects' node_modules and warns redirect_bun_entry_not_found for their packages (exit 0). They have their own locks: scan them by PATH (scan '*/*' --mode hosted).

• Mock fixture: agent mode needs a blob/<hash> route. Without it the result is partial_failure.

• Vendored scan on a Bun 1.3.x workspace (lockfileVersion 1) refuses vendor_bun_workspace_unsupported. That's the documented pre-v2 workspace limitation, and the lock is untouched.

• vex exit 2 product_undetected in a fixture without a package version or git origin: pass --product (fixture limit).

• Bun never prunes node_modules/.bun entries: after a dependency is removed, its store dir (and, on 1.4.2, the member link) stays. That's Bun behaviour. It only matters to socket-patch through With Bun's isolated linker, vex refuses every hosted patch as not_applied after the usual in-place bun install, because it checks orphaned node_modules/.bun registry entries that Bun never removes (regression from #496) #599.

• Agent apply on a workspace whose member links into an isolated store reports a duplicate already_patched skip per member-linked package (counts only, the bytes are right). pnpm behaves the same, so it's handed to pnpm (entries/pnpm/20261002T193154Z-from-bun.md).

• scan -g with BUN_INSTALL_GLOBAL_DIR set reports the Node global prefix's packages, not Bun's. That's Global mode misses every Bun global package when BUN_INSTALL_BIN or BUN_INSTALL_GLOBAL_DIR is set: scan -g reports success with nothing found, get -g / vex -g patch and attest nothing #443, not a new bug.

• Hosted vex attests darwin-only packages (fsevents, @esbuild/darwin-*) on a Linux checkout where they're not installed: the lock pins patched bytes for every platform, so that's correct.

• Mock fixture: in proxy mode set both SOCKET_PROXY_URL and SOCKET_PATCH_SERVER_URL. Without the latter, hosted pins aren't recognized and vex reports manifest_not_found.

• Bun's auto-migration of a hosted package-lock.json writes bun.lock registry 4-tuples with the hosted URL in the registry slot (["left-pad@1.3.0", "http://…/tok/<uuid>/left-pad-1.3.0.tgz", {}, "sha512-…"]). Bun installs the patched bytes from them. socket-patch fails closed on that shape (vex → patched_ref_unattributable / manifest_not_found, list / rollback → hosted_wiring_contested, no writes), and a re-run of scan --mode hosted heals it into the canonical URL tuple. No false attestation, so not filed (run 11). The vex detail wording ("from elsewhere (not a Socket patch)") is inaccurate for this shape.

• bun update re-resolves hosted pins back to the registry. That's Bun behaviour, and vex correctly stops attesting.

• A 1.4.2-written bun.lockb can't be read by Bun 1.1.45 even without socket-patch.

• Bun's auto-migration of a hosted yarn.lock writes the same registry-slot 4-tuples as the package-lock.json case, plus a #<sha1> fragment. socket-patch fails closed, and a re-run of scan --mode hosted heals it (run 12).

• Bun's auto-migration of a hosted pnpm-lock.yaml (1.3.14, 1.4.2) ignores resolution.tarball, downloads the registry tarball and fails IntegrityCheckFailed against the patched sha512, writing no bun.lock. That's a Bun migration limitation and fails closed. Remedy: migrate first, then run scan --mode hosted.

• get <pkg> --mode hosted from inside a workspace member dir is a success no-op with redirect_npm_no_lockfile, the same as scan <member>: tracked on Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884 since run 21. Run it from the root.

• A SIGKILLed vendor --revert can leave a 0-byte .socket/vendor/.socket-stage-state.json-<uuid> temp file. It's harmless; the next run heals the state.

• Plain (human) scan --mode agent doesn't re-apply patches the manifest already records ([skip] … already recorded, "run socket-patch apply"), while --json re-applies. It's generic, not Bun-specific: handed to npm (entries/npm/20261003T193043Z-from-bun.md). After an interrupted agent apply, use socket-patch apply.

• scan --json apply.patches[].action (added / skipped) is the manifest record's state, not whether files were written.

• repair doesn't recreate a deleted socket-patch.vendor.json sidecar. It's informational only (CLI_CONTRACT). A deleted .socket/vendor/state.json → repair vendor_ledger_missing (documented v5: restore it from VCS).

• An interrupted vendored → hosted takeover can leave registry tuples (unpatched install) until the re-run. vex doesn't attest them, and the re-run heals.

• Hosted rollback on a lock whose registry slot holds a full custom-registry tarball URL (Bun writes one for a non-default [install] registry) restores "". It's pinned by the custom-registry shape in backtest-bun.py, and the restored lock frozen-installs from the configured registry (run 14). The same holds after a vendored → hosted → vendored chain: vendor --revert restores "" for any entry that passed through hosted mode, and full URLs for entries that were only ever vendored (run 26). Correction (run 27): that's only true on Bun ≥ 1.3.7. Bun 1.1.39–1.3.6 resolve "" against npmjs, which is Hosted Bun rollback/remove writes an empty registry slot that Bun < 1.3.7 resolves against npmjs, so custom-registry projects can't frozen-install after a revert #992.

• Bun resolves a dependency on X@2.0.0+build.6 to an installed X@2.0.0+build.5, because semver ignores build metadata. That's Bun behaviour.

• Bun copies file: directory deps into node_modules, so agent mode patches the copy, not the source. That's safe and not part of Agent-mode apply writes through node_modules links into first-party source (npm workspace members, file: deps, npm link targets), overwriting the user's code, and rollback restores upstream bytes instead #626.

• Mock fixture: serve the npm registry from a different origin than SOCKET_PATCH_SERVER_URL. Otherwise the registry URLs Bun writes into bun.lockb look like hosted pins, and vendored rollback fails hosted_wiring_contested (run 15; with split origins it's success).

• The bun.lockb legacy (link://) meta-hash dialect isn't produced by any writer in range (≥ 1.1.39); numeric prerelease ordering in the current dialect matches Bun (run 15).

• A plain bun install with only a bun.lockb keeps the binary lock on 1.2.23 / 1.3.14 / 1.4.2. Only --save-text-lockfile migrates it (run 16).

• Release 4.0.0 refuses scan --mode vendored on a bun.lockb (exit 1), so it isn't a baseline for vendored-lockb cells (run 16).

• A path literal ("m1": "packages/m1") in a text bun.lock with only registry tuples frozen-installs on 1.3.14 and 1.4.2. Only together with URL/local pins does 1.4.2 re-resolve, which is After Bun 1.4 migrates a hosted workspace bun.lockb to bun.lock, bun install --frozen-lockfile fails and Bun's suggested bun install silently drops the hosted pins #803 (run 17).

• bun add <pkg> run inside a workspace member re-resolves that member's dependencies and drops its hosted pins back to registry tuples, on text v1/v2 and bun.lockb (1.2.23 / 1.3.14 / 1.4.2). A root-level bun add keeps them. That's Bun behaviour, like bun update: a re-run of scan --mode hosted heals it, and vex doesn't attest the dropped pin (run 18).

• A lockfile-only hosted re-run can't see existing pins (Bun lockfile-only checkouts can't see hosted pins: hosted re-runs never pick up a superseding patch and scan --mode vendored skips the takeover, both reporting success with 0 packages #720), so maxNewPatches neither counts nor defers them, and nothing is unwired (run 18).

• After vendor --revert in a core.autocrlf=true clone, the restored registry line in bun.lock is LF inside an otherwise CRLF working copy. Git normalizes it on commit (byte-exact to the pre-vendor commit) and Bun reads it, so it's cosmetic. Hosted rollback keeps CRLF on every line (run 19).

• Mock fixture: pkill -f mock.py also matches the calling shell, whose command line contains the heredoc. Kill the mock by pidfile.

• Vendored bun.lockb workspaces commit an identical tarball under every member's .socket/vendor, even members that don't use the package. That's deliberate (Bun 0.5.9–1.3 resolves workspace local tarballs relative to the declaring member, bun_binary.rs:142). A missing member copy fails closed (vendor_workspace_artifact_missing), and repair restores it (run 20).

• Bun refuses a workspace member that depends on the root package via workspace:* (root@workspace:* failed to resolve), so that After Bun 1.4 migrates a hosted workspace bun.lockb to bun.lock, bun install --frozen-lockfile fails and Bun's suggested bun install silently drops the hosted pins #803-heal shape can't occur (run 20).

• Bun 1.3.9 can't frozen-install a text bun.lock written by 1.4.2 (lockfile had changes). That's cross-version Bun behaviour.

• get <name> --mode hosted with several installed versions (e.g. ms@2.0.0 nested + ms@2.1.3 direct) acts on only one: the package-name path searches just the best fuzzy match among installed purls, by design (get.rs:2844), and names it on stderr. It isn't Bun-specific. Use scan or a purl (run 22).

• Fixture: git-ignore node_modules before committing, or "fresh" clones aren't empty (run 22).

• bun install --save-text-lockfile on 1.4.2 deletes bun.lockb; bun bun.lockb prints the ACTIVE lock (the text one when both exist). Inspect a stale binary with strings (run 21).

• vex exit 2 manifest_not_found ("nothing to attest") after every patch is rolled back or reverted is correct (run 25).

• get --mode agent on an already-vendored package doesn't take it over: the manifest and the vendored ledger coexist, and a scoped rollback unwinds both (run 25).

[github-actions[bot]]

[agent] 2026-09-30: Bun bug-hunt run

Tested: main f6b7fb9 (CLI 4.0.0 workspace version). Latest release 4.0.0 and previous release 3.3.0, both from npm @socketsecurity/socket-patch, for regression checks. Bun 1.1.38, 1.1.45, 1.2.23, 1.3.0, 1.3.2, 1.3.4, 1.3.5, 1.3.6, 1.3.9, 1.3.10, 1.3.14, 1.4.0 and 1.4.2 (the current latest) from GitHub releases, on Node 22 in the sandbox. Probes ran on ubuntu, macOS and Windows.

Method: the patch API is unreachable from the sandbox (patches-api.socket.dev is proxy-denied), so I used a ~70-line Python mock with these routes: batch, by-package, the patches/package grant, patches/view with blobContent, and the hosted tarball route. Patched tarballs are built from the real registry tarball with a marker prepended to the main file, gzipped with mtime 0 so the sha512 is stable. The oracle is the marker in the installed file after a fresh-checkout bun install --frozen-lockfile with an empty cache, plus node require for the native-module case.

This is the first run: there was no earlier ledger and no pm:bun issues to re-triage.

Cells

• fail Bun isolated linker: transitive packages under node_modules/.bun are "not installed" in agent mode, and scan --mode agent exits 0 with them unpatched #366: agent mode with Bun's isolated linker. Transitive packages under node_modules/.bun/ are treated as lockfile-only: scan --mode agent exits 0 with success and doesn't patch or record them. This happens by default in fresh workspaces on Bun 1.3.14 and 1.4.2, and with linker = "isolated" on 1.2.23+. Reproduced on Linux, macOS and Windows. Releases 3.3.0 and 4.0.0 behave the same.
• fail Hosted and vendored Bun rewiring silently discards the project's own bun patch (patchedDependencies): fresh frozen installs drop the user's patch with exit 0 #367: hosted and vendored mode silently discard the project's own bun patch (patchedDependencies). The fresh frozen install exits 0 with Socket's patch but without the user's. Reproduced on Bun 1.2.23, 1.3.9, 1.3.14 and 1.4.2, text lock and bun.lockb, on all 3 OSes. 3.3.0 and 4.0.0 behave the same. rollback restores it (pass).
• fail On Bun ≥ 1.3.5, hosted and vendored rewiring drops Bun's default trust, so install scripts of patched packages (better-sqlite3, esbuild, sharp…) are silently blocked #371: hosted and vendored rewiring loses Bun's default trust, so better-sqlite3's install script is blocked and require fails after a fresh frozen install. The first bad Bun release is 1.3.5 (1.3.4 passes). Confirmed on all 3 OSes. trustedDependencies works around it.
• commented on npm agent-mode apply never patches an npm-aliased install (lp@npm:left-pad), yet VEX attests the package not_affected #356 (npm-owned): agent-mode npm aliases under Bun 1.4.2. The mixed project patches only left-pad, not lp, and VEX attests not_affected.
• pass: agent mode with the hoisted linker (direct and transitive), on Bun 1.2.23 / 1.3.14 / 1.4.2 × 3 OS.
• pass: hosted + bun update unwires the redirect, and vex then reports redirect_unwired (Bun 1.4.2).
• pass: agent scan --global on bun add -g packages (~/.bun/install/global/node_modules, Bun 1.4.2).
• pass: the setup hook (npx …) in a Bun-only PATH with no node/npx. Bun maps npx itself, and bun install exits 0 (1.4.2).
• pass: agent writes break Bun's cache hardlinks (rename-over write, code-verified; the cache is not written through).

Issues

• Filed Bun isolated linker: transitive packages under node_modules/.bun are "not installed" in agent mode, and scan --mode agent exits 0 with them unpatched #366: Bun isolated linker: transitive packages under node_modules/.bun are "not installed" in agent mode, and scan --mode agent exits 0 with them unpatched #366
• Filed Hosted and vendored Bun rewiring silently discards the project's own bun patch (patchedDependencies): fresh frozen installs drop the user's patch with exit 0 #367: Hosted and vendored Bun rewiring silently discards the project's own bun patch (patchedDependencies): fresh frozen installs drop the user's patch with exit 0 #367
• Filed On Bun ≥ 1.3.5, hosted and vendored rewiring drops Bun's default trust, so install scripts of patched packages (better-sqlite3, esbuild, sharp…) are silently blocked #371: On Bun ≥ 1.3.5, hosted and vendored rewiring drops Bun's default trust, so install scripts of patched packages (better-sqlite3, esbuild, sharp…) are silently blocked #371
• Commented on npm agent-mode apply never patches an npm-aliased install (lp@npm:left-pad), yet VEX attests the package not_affected #356: npm agent-mode apply never patches an npm-aliased install (lp@npm:left-pad), yet VEX attests the package not_affected #356 (comment)

False positives ruled out

• Agent rollback failing with missing_blob came from my mock, which serves no before-blob. It's a fixture limit, not a bug.
• The esbuild postinstall that became "untrusted" after rewiring has no observable effect (its binary comes via optionalDependencies), so I used better-sqlite3 to prove the On Bun ≥ 1.3.5, hosted and vendored rewiring drops Bun's default trust, so install scripts of patched packages (better-sqlite3, esbuild, sharp…) are silently blocked #371 impact.
• On Windows, the default-linker workspace cell had bun install exit 1 on the runner. That cell is inconclusive there; the explicit linker = "isolated" cell reproduces Bun isolated linker: transitive packages under node_modules/.bun are "not installed" in agent mode, and scan --mode agent exits 0 with them unpatched #366.
• On Bun 1.2.23, a new workspace defaults to the hoisted layout, so agent mode passes there. That's expected, not a fix.

Probe

• bughunt/bun/20260930-isolated-bunpatch, run https://github.com/SocketDev/socket-patch/actions/runs/36765789215 (3 OS × Bun 1.2.23 / 1.3.14 / 1.4.2)
• bughunt/bun/20260930-default-trust, run https://github.com/SocketDev/socket-patch/actions/runs/36766578001 (3 OS × Bun 1.3.4 / 1.3.5 / 1.4.2)
• Neither branch could be deleted. git push --delete failed through the git proxy ("remote end hung up", three tries each), so a maintainer needs to delete both.

Next

1. Agent mode on Windows with the isolated linker (junction layout) once Bun isolated linker: transitive packages under node_modules/.bun are "not installed" in agent mode, and scan --mode agent exits 0 with them unpatched #366 is fixed. Also re-test the Windows default-workspace bun install exit 1.
2. The hosted ⇄ vendored takeover and scoped rollback / remove on bun.lockb with two patched packages, one of them workspace-only (1.2.23 vs 1.4.2).
3. bun install --frozen-lockfile after a hosted run on Bun 1.3.9 vs 1.3.10 with a tampered hosted tarball in a lockb project (digest enforcement for binary locks).
4. overrides / resolutions targeting the patched package (text and lockb), and catalog: specs in workspaces (Bun 1.3+).
5. Lockfile-only checkout + vendored scan on Bun 1.1.45 (lockfileVersion 0, no workspaces) with CRLF + BOM package.json.

[github-actions[bot]]

[agent] 2026-10-01: Bun bug-hunt run

Tested: main 2463257 ("feat!: consolidate the v5 patching workflow", #277). It's a big rewrite: scan is now hosted by default, setup is gone, hosted mode keeps no ledger, and VEX works without a manifest. Latest release 4.0.0 (npm @socketsecurity/socket-patch-linux-x64-gnu) for regression checks. Bun 1.1.45, 1.2.23, 1.3.9, 1.3.10, 1.3.14 and 1.4.2 (still the current latest), from npm @oven/bun-linux-x64, on Linux. Probes ran on ubuntu, macOS and Windows.

Method: same as run 1, with the mock rebuilt (mkpatch.py + mock.py). I added a /registry/<name>/<ver> passthrough and set SOCKET_NPM_REGISTRY to it, because the CLI's reqwest can't reach registry.npmjs.org from this sandbox even though curl can. Hosted rollback needs that registry lookup. I also set SOCKET_PATCH_SERVER_URL to the mock, so its URLs count as hosted pins. The oracle: marker bytes after a fresh-checkout bun install --frozen-lockfile with an empty cache, plus byte comparison of the lockfiles.

Re-triage (on 2463257)

• Bun isolated linker: transitive packages under node_modules/.bun are "not installed" in agent mode, and scan --mode agent exits 0 with them unpatched #366: still reproduces. With the isolated linker and Bun 1.4.2, scan --mode agent gives package_not_installed for is-number under .bun/, exit 0. No comment, since nothing is new.
• Hosted and vendored Bun rewiring silently discards the project's own bun patch (patchedDependencies): fresh frozen installs drop the user's patch with exit 0 #367 / On Bun ≥ 1.3.5, hosted and vendored rewiring drops Bun's default trust, so install scripts of patched packages (better-sqlite3, esbuild, sharp…) are silently blocked #371: v5 still has no handling for patchedDependencies or trustedDependencies (grep over crates/ and docs/ finds nothing). I didn't re-run the runtime repro this time (see Blocked). No change, no comment.

Cells

• fail With Bun's isolated linker, vex attests a hosted patch as not_affected (verified) while the installed copy under node_modules/.bun is still unpatched (v5 regression) #405 (new): hosted scan (now the default) → vex with Bun's isolated linker. vex attests a transitive package under node_modules/.bun/ as verified / not_affected while the installed copy is unpatched (a stale tree before reinstall) or tampered (after a fresh install). The same project with the hoisted linker gives not_applied. Reproduced on Linux, macOS and Windows × Bun 1.2.23 (linker=isolated), 1.3.14 and 1.4.2, both with the bunfig setting and as a default workspace. Regression: 4.0.0 omits the purl (package_not_found).
• pass: hosted rollback <purl> and unscoped rollback, with two packages, on text locks version 0 (1.1.45), 1 (1.3.14) and 2 (1.4.2). The lock comes back byte-identical and the frozen install is OK.
• pass: hosted rollback byte-exact for an npm alias (lp@npm:left-pad), a v1 workspace (1.3.14), catalog: (1.3.14), and overrides forcing the patched transitive (1.4.2). Vendored catalog: and overrides on 1.4.2 also pass, rollback included.
• pass: remove <purl> × 2 restores the hosted text lock byte-exact. repair and list on a hosted project work.
• pass: bun.lockb hosted → vendored takeover → vendor --revert with two packages (1.4.2). Every fresh frozen install is correct, and bun pm hash and the bun ./bun.lockb dump match the original. The file isn't byte-identical: it's 1997 → 2301 bytes, because its string buffer keeps the dead hosted and vendored URLs. That isn't a bug: semantics are preserved, and the doc only promises a byte-exact registry record. Logged under Known non-bugs.
• pass: hosted bun.lockb idempotency (a second scan leaves it unchanged, --dry-run writes nothing), and rollback refuses with the documented git checkout -- bun.lockb remedy.
• pass: lockfile-only vendored scan on Bun 1.1.45 (lockfileVersion 0) with a CRLF + BOM package.json. The manifest isn't touched, the frozen install is patched, and rollback is byte-exact.
• pass: a corrupt served tarball is rejected on 1.3.9, 1.3.10 and 1.4.2, text and bun.lockb. Note that bun.lockb enforces the sha512 already on 1.3.9 ("Integrity check failed"). My tamper corrupted the gzip, so a 1.3.9 text lock failed with ZlibError instead. That isn't a digest-boundary test; it's still in the backlog.
• pass: agent scan → vex → rollback with the mock serving before-blobs (1.4.2). A warm-cache reinstall after apply gives pristine bytes, so the Bun cache isn't written through.
• pass, Windows: a default-workspace bun install on 1.3.14 and 1.4.2 exited 0 on windows-latest this time (inconclusive in run 1).

Issues

• Filed With Bun's isolated linker, vex attests a hosted patch as not_affected (verified) while the installed copy under node_modules/.bun is still unpatched (v5 regression) #405: With Bun's isolated linker, vex attests a hosted patch as not_affected (verified) while the installed copy under node_modules/.bun is still unpatched (v5 regression) #405

False positives ruled out

• Hosted rollback → partial_failure "error sending request for url (https://registry.npmjs.org/…)" was a sandbox artifact: reqwest can't connect to npmjs here. With SOCKET_NPM_REGISTRY pointed at a passthrough, the restore succeeds.
• apply after agent rollback is a success no-op. v5 rollback deliberately removes manifest entries (CLI_CONTRACT rollback row), so this is expected.

Probe

• bughunt/bun/20261001-vex-isolated: runs https://github.com/SocketDev/socket-patch/actions/runs/36800886824 (failed on pipefail in my script) and https://github.com/SocketDev/socket-patch/actions/runs/36801259018 (9/9 jobs, all results reported in With Bun's isolated linker, vex attests a hosted patch as not_affected (verified) while the installed copy under node_modules/.bun is still unpatched (v5 regression) #405).

Blocked

• Deleting branches is still impossible from this sandbox. In run 1, git push --delete went through the git proxy and got "remote end hung up". This run the first attempt failed the same way, and a later command was refused by the session's permission classifier ("Git Destructive"), so I didn't retry. A maintainer needs to delete three branches: bughunt/bun/20260930-default-trust, bughunt/bun/20260930-isolated-bunpatch and bughunt/bun/20261001-vex-isolated.
• I didn't re-run the Hosted and vendored Bun rewiring silently discards the project's own bun patch (patchedDependencies): fresh frozen installs drop the user's patch with exit 0 #367 runtime repro (bun patch --commit) because that command was refused by the same classifier. I re-triaged it by code inspection only.

Next

1. Digest boundary with a valid substitute tarball (a different but well-formed tgz) on a 1.3.9 text lock vs 1.3.10, in hosted and vendored mode. Confirm bun.lockb enforces on 1.3.9.
2. vex with a vendored project under the isolated linker: does the vendored_tree_out_of_sync warning fire when the .bun/ copy is stale?
3. A Windows agent run with the isolated linker (junction layout) once Bun isolated linker: transitive packages under node_modules/.bun are "not installed" in agent mode, and scan --mode agent exits 0 with them unpatched #366 is fixed. Also VEX on Windows after a real frozen hosted install.
4. A hosted → vendored takeover on a v1 workspace lock (1.3.14). It must refuse vendor_bun_workspace_unsupported and leave the hosted pin byte-untouched. Check --dry-run parity too.
5. v5 socket.yml policy and per-run limits in a Bun workspace with two patched packages (Bun 1.4.2).

[github-actions[bot]]

[agent] 2026-10-01: maintainer note: test global (-g) mode for hosted patches

This is a maintainer request, not a run report. Add it to the top of the backlog and keep it there until the cells below are covered.

Ask: make sure we correctly scan global installs when -g / --global is passed, on every major Bun version and on Linux, macOS and Windows.

Where Bun puts global installs: bun add -g; discovery via bun pm bin -g (~/.bun/install/global/node_modules, BUN_INSTALL). Cover Bun 1.0 through latest, and Windows %USERPROFILE%\.bun.

What to check (prove each with a real global install, not by reading source):

1. socket-patch scan -g (no --mode) is report-only. It must find every globally installed Bun package that has a hosted patch: none missing, no project packages leaking in, correct versions. Also check --json.
2. scan -g run from inside a Bun project versus outside one: -g must scan only the global location, and a scan without -g must never touch it.
3. scan -g --mode hosted and scan --global-prefix <dir> --mode hosted must refuse loudly, as designed ("global installs have no project lockfile to redirect"). They must exit non-zero and write nothing.
4. get -g defaults to agent mode. Check scan -g --apply, apply -g, rollback -g and vex -g: the globally installed copy is actually patched (run the installed tool or import it), rollback restores it byte for byte, and vex only attests what's applied.
5. --global-prefix <dir> and SOCKET_GLOBAL=1 behave the same as -g. That covers custom prefixes, version managers, paths with spaces or unicode, and a non-root user's prefix.
6. A global directory you can't write to (root-owned prefix, Windows Program Files) must fail loudly with a clear error, never exit 0 unpatched.

Add OS × Bun version cells for -g (scan report / apply / rollback) to the coverage matrix, and use probe branches for macOS and Windows.

[github-actions[bot]]

[agent] 2026-10-01: Bun bug-hunt run

Tested: main 2463257 (unchanged since run 2) and latest release 4.0.0 (npm @socketsecurity/socket-patch-linux-x64-gnu) for regression checks. Bun 1.1.45, 1.2.23, 1.3.14 and 1.4.2, from npm @oven/bun-*, on Linux, plus a probe on ubuntu, macOS and Windows. This run focused on the maintainer request: global (-g) mode.

Method: real bun add -g semver@7.6.0 is-number@7.0.0 into an isolated BUN_INSTALL, with a Python mock of the public proxy (SOCKET_PROXY_URL: /patch/batch, view, by-package, blob) serving free patches for both packages. The oracle: marker bytes in the real global copy, node require() of the global package, VEX statements, and sha256 of the original files after rollback. Paths in the probe contain a space and ü.

Re-triage (on 2463257)

• Bun isolated linker: transitive packages under node_modules/.bun are "not installed" in agent mode, and scan --mode agent exits 0 with them unpatched #366: still reproduces. With the isolated linker and Bun 1.4.2, to-regex-range → transitive is-number gives scan --mode agent → [skip] … not installed, exit 0, unpatched. Direct deps under .bun/ do patch. Nothing new, no comment.
• With Bun's isolated linker, vex attests a hosted patch as not_affected (verified) while the installed copy under node_modules/.bun is still unpatched (v5 regression) #405, Hosted and vendored Bun rewiring silently discards the project's own bun patch (patchedDependencies): fresh frozen installs drop the user's patch with exit 0 #367, On Bun ≥ 1.3.5, hosted and vendored rewiring drops Bun's default trust, so install scripts of patched packages (better-sqlite3, esbuild, sharp…) are silently blocked #371: main is unchanged since run 2, so I didn't re-check them.

Global-mode cells (scan -g report / hosted refusal / scan -g --mode agent / runtime import / vex -g / vex -g omits an unapplied patch / apply -g / rollback -g byte-exact / get -g)

• pass, default layout ($BUN_INSTALL/bin + $BUN_INSTALL/install/global): Linux, macOS and Windows × 1.1.45, 1.2.23, 1.3.14 and 1.4.2. The exception is Windows 1.1.45/1.2.23, where bun add -g itself failed in the space + unicode temp dir (blocked, not ours).
• pass: scan -g --mode hosted, --global-prefix … --mode hosted, SOCKET_GLOBAL=1 --mode hosted and SOCKET_GLOBAL_PREFIX … --mode hosted all exit 2 with "global installs have no project lockfile to redirect" and write nothing.
• pass: SOCKET_GLOBAL=1 matches -g, and SOCKET_GLOBAL_PREFIX / --global-prefix <bun global node_modules> scan only that directory.
• pass: scan -g from inside a Bun project, even one with a project bunfig.toml setting globalDir / globalBinDir, scans only the real global dir. bun pm bin -g ignores the project bunfig, so nothing leaks from the project.
• pass: vex -g attests applied global patches and omits a reverted one with not_applied. Without -g, vex doesn't touch the global copy (package_not_found).
• fail Global mode misses every Bun global package when BUN_INSTALL_BIN or BUN_INSTALL_GLOBAL_DIR is set: scan -g reports success with nothing found, get -g / vex -g patch and attest nothing #443 (new): with BUN_INSTALL_BIN or BUN_INSTALL_GLOBAL_DIR set, scan -g finds no Bun globals (exit 0, success). scan -g --mode agent exits 0 unpatched, get -g exits 1, and vex -g has nothing to attest. This holds on every OS × version tested and on release 4.0.0 (not a regression). The cause is parse_bun_bin_output guessing <bin>/../install/global/node_modules.
• fail On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 (commented): on Windows, an npm-installed Bun (only bun.cmd on PATH) gives scan -g empty, on 1.3.14 and 1.4.2. It's the bare-bun spawn already covered by On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 / PR Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442. macOS and Linux pass the same layout.

Issues

• Filed Global mode misses every Bun global package when BUN_INSTALL_BIN or BUN_INSTALL_GLOBAL_DIR is set: scan -g reports success with nothing found, get -g / vex -g patch and attest nothing #443: Global mode misses every Bun global package when BUN_INSTALL_BIN or BUN_INSTALL_GLOBAL_DIR is set: scan -g reports success with nothing found, get -g / vex -g patch and attest nothing #443
• Commented on On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 (npm-owned, bughunt) with the Bun evidence: On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 (comment)

False positives ruled out

• --global-prefix ~/.bun/install/global (the parent, not node_modules) scans 0 packages. The flag is documented as the packages root, so that's user error.
• scan -g --mode hosted --json prints plain text on stderr with exit 2 and no JSON envelope. That's a clap-level argument conflict, consistent with other usage errors.
• A bunfig globalDir in ~/.bunfig.toml wasn't honoured by bun add -g in my sandbox setup. Bun ignored it, so it isn't socket-patch's problem. The env vars are the reproducible trigger.
• scan -g also scans npm's own global root (/opt/node22/lib/node_modules). That's by design: global mode covers every package manager's globals.

Probe

• bughunt/bun/20261001-global-dirs: https://github.com/SocketDev/socket-patch/actions/runs/36830650075 (3 builds + 12 probe jobs; Windows 1.1.45/1.2.23 failed in the probe's own bun add -g).

Blocked

• git push --delete still fails ("remote end hung up"). A maintainer needs to delete four branches: bughunt/bun/20260930-default-trust, bughunt/bun/20260930-isolated-bunpatch, bughunt/bun/20261001-vex-isolated and bughunt/bun/20261001-global-dirs.

Next

1. Global mode, remaining checklist items: a non-writable global dir (root-owned prefix, or a read-only BUN_INSTALL on Windows) must fail loudly; -g with a symlinked BUN_INSTALL; Windows 1.1.45/1.2.23 with an ASCII temp path.
2. Re-test Global mode misses every Bun global package when BUN_INSTALL_BIN or BUN_INSTALL_GLOBAL_DIR is set: scan -g reports success with nothing found, get -g / vex -g patch and attest nothing #443 and the bun.cmd case once PR Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 lands.
3. A hosted → vendored takeover on a v1 workspace lock (1.3.14). It must refuse before writes; check --dry-run parity.
4. vex on a vendored project with the isolated linker (stale .bun/ copy → vendored_tree_out_of_sync?).
5. Hosted rollback on macOS and Windows (CRLF lock with core.autocrlf).

[github-actions[bot]]

[agent] 2026-10-01: Bun bug-hunt run

Tested: main d984832 (new since run 3: #337 npm bundled-copy VEX fix, #322 Maven docs) and release 4.0.0 (npm @socketsecurity/socket-patch-linux-x64-gnu) for the regression check. Bun 1.1.45, 1.2.23, 1.3.14 and 1.4.2 from npm @oven/bun-linux-x64, on Linux only. No probe branch this run: the new bug is in lockfile parsing and rewriting, not OS-specific code, and old probe branches still can't be deleted from the sandbox.

Method: a Python mock of the authenticated patch API (batch, by-package, patches/package, view/<uuid>, blob, the hosted tarball, a /registry/ passthrough) plus a local @bh scope registry serving @bh/bund@1.0.0 with bundleDependencies: ["is-number"]. The patch prepends /* SOCKET-PATCHED */ to is-number@7.0.0/index.js. Oracle: a fresh checkout with a cold cache and bun install --frozen-lockfile, marker bytes in every installed copy, and require.resolve from the parent.

Re-triage

• Global mode misses every Bun global package when BUN_INSTALL_BIN or BUN_INSTALL_GLOBAL_DIR is set: scan -g reports success with nothing found, get -g / vex -g patch and attest nothing #443: still reproduces on d984832. With BUN_INSTALL_BIN set, scan -g scans 551 packages vs 552 without it, so the Bun global is-number is missed. PR Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 hasn't landed. No comment.
• With Bun's isolated linker, vex attests a hosted patch as not_affected (verified) while the installed copy under node_modules/.bun is still unpatched (v5 regression) #405: still reproduces. Commented with a vendored variant (below).

Cells

• fail Bun hosted and vendored rewiring rewrites bundled: true lock entries that Bun never fetches: the bundled copy stays unpatched, scan reports success, and vendored vex attests not_affected #469 (new): Bun bundled: true lock entries ("@bh/bund/is-number": ["is-number@7.0.0", "", {"bundled": true}, …]). Hosted and vendored rewire them silently (success, no warning; npm warns *_bundled_instance_skipped). Bun unpacks bundled copies from the parent tarball, so the copy the parent loads stays unpatched after a frozen install. On text locks with Bun ≥ 1.2 there's also an extra patched hoisted copy that nothing loads. Vendored default vex attests not_affected and hosted vex --no-verify attests too. Hosted default vex → not_applied (ok). Affected: 1.1.45 (text v0 + lockb), 1.2.23, 1.3.14 and 1.4.2 (text + lockb), in both the "bundled only" and "bundled + direct" shapes. Release 4.0.0 behaves the same and also attests in hosted default vex: not a regression.
• pass: hosted → vendored takeover on a v1 workspace lock (1.3.14, hoisted). Refuses with vendor_bun_workspace_unsupported before any write: bun.lock, the package.json files and the file list are unchanged, and the hosted pin is kept. --dry-run gives would_refuse with exit 0, the real run partial_failure with exit 1. That asymmetry is documented (CLI_CONTRACT would_refuse row).
• fail → With Bun's isolated linker, vex attests a hosted patch as not_affected (verified) while the installed copy under node_modules/.bun is still unpatched (v5 regression) #405 (commented): vendored + isolated linker, stale tree (not reinstalled). vex attests from the artifact (by design) but omits the vendored_tree_out_of_sync warning. Hoisted emits it. 2/2 runs each, Bun 1.4.2. After a frozen reinstall the .bun/ copy is patched and vex is correct. With Bun's isolated linker, vex attests a hosted patch as not_affected (verified) while the installed copy under node_modules/.bun is still unpatched (v5 regression) #405 (comment)

Issues

• Filed Bun hosted and vendored rewiring rewrites bundled: true lock entries that Bun never fetches: the bundled copy stays unpatched, scan reports success, and vendored vex attests not_affected #469: Bun hosted and vendored rewiring rewrites bundled: true lock entries that Bun never fetches: the bundled copy stays unpatched, scan reports success, and vendored vex attests not_affected #469
• Commented on With Bun's isolated linker, vex attests a hosted patch as not_affected (verified) while the installed copy under node_modules/.bun is still unpatched (v5 regression) #405: see above.

False positives ruled out

• Hosted default vex on the bundled shape correctly refuses (not_applied): its installed-tree check sees the bundled copy. Only vendored, and --no-verify, attest.
• Vendored --dry-run exits 0 with success while the real run exits 1 with partial_failure, for the same refusal. That's documented.
• Vendored vex attesting while the installed tree is stale is by design: the artifact is the evidence. Only the missing warning is a bug.

Blocked

• Still can't delete probe branches (no new ones this run). A maintainer needs to delete bughunt/bun/20260930-default-trust, bughunt/bun/20260930-isolated-bunpatch, bughunt/bun/20261001-vex-isolated and bughunt/bun/20261001-global-dirs.

Next

1. Global-mode leftovers: a non-writable global dir must fail loudly; a symlinked BUN_INSTALL; Windows 1.1.45/1.2.23 with an ASCII temp path.
2. Bun hosted and vendored rewiring rewrites bundled: true lock entries that Bun never fetches: the bundled copy stays unpatched, scan reports success, and vendored vex attests not_affected #469 on macOS and Windows (a cheap probe, if branch deletion works again), plus bundled inside a workspace member, and rollback/remove of a rewired bundled entry.
3. Hosted rollback on macOS and Windows (CRLF lock with core.autocrlf).
4. v5 socket.yml policy and per-run limits in a Bun workspace.
5. Re-test Global mode misses every Bun global package when BUN_INSTALL_BIN or BUN_INSTALL_GLOBAL_DIR is set: scan -g reports success with nothing found, get -g / vex -g patch and attest nothing #443 and the bun.cmd case once PR Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 lands.

[github-actions[bot]]

[agent] 2026-10-01: Bun bug-hunt run

Tested: main 61cfb9b (new since run 4: #365 npm .store / pnpm virtualStoreDir crawler walks, #446 -g cwd-state fix, gem/pip fixes) and release 4.0.0 (npm @socketsecurity/socket-patch-linux-x64-gnu) for the regression check. Bun 1.1.45, 1.2.23, 1.3.14 and 1.4.2 (1.4.2 is still the latest stable) from npm @oven/bun-linux-x64, on Linux only.

No probe branch this run: git push --delete is still denied in the sandbox, so a new probe branch couldn't be cleaned up.

Method: a Python mock of the patch API (batch, by-package, patches/package, view with blob contents, blob/<hash>, the hosted tarball, and a /registry/ passthrough). Patches prepend /* SOCKET-PATCHED */ to is-number@6.0.0/index.js, is-odd@3.0.1/index.js and @sindresorhus/is@4.6.0/dist/index.js. Gzip the patched tarball with mtime=0: otherwise a mock restart changes its sha512 and every later install fails IntegrityCheckFailed, which is a fixture artifact. Oracle: a fresh checkout, a cold cache, bun install --frozen-lockfile, the marker bytes and require.resolve.

Re-triage

• Bun isolated linker: transitive packages under node_modules/.bun are "not installed" in agent mode, and scan --mode agent exits 0 with them unpatched #366: still reproduces on 61cfb9b. Fix npm crawler missing relocated dependency stores (#359, #362) #365 added the .store / pnpm virtual-store walks but not .bun. Commented: Bun isolated linker: transitive packages under node_modules/.bun are "not installed" in agent mode, and scan --mode agent exits 0 with them unpatched #366 (comment)
• Global mode misses every Bun global package when BUN_INSTALL_BIN or BUN_INSTALL_GLOBAL_DIR is set: scan -g reports success with nothing found, get -g / vex -g patch and attest nothing #443: BUN_INSTALL_BIN / BUN_INSTALL_GLOBAL_DIR are still unread on main (PR Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 not landed). No new information, so no comment.

Cells (Linux)

• fail Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 (new): a URL or file: tarball dependency on the patched name@version, beside a nested registry copy of the same version.
  • Hosted and vendored rewire only the registry tuple, with no warning (success, warnings: []).
  • After a frozen install the root copy the app requires is unpatched.
  • Vendored vex (default and --no-verify) attests not_affected, and so does hosted vex --no-verify. Hosted default vex → not_applied (correct).
  • Affected: 1.1.45 v0, 1.2.23 v1, 1.3.14 v1 and 1.4.2 v2 (URL), plus 1.4.2 file: tgz. 2/2 runs on 1.3.14 and 1.4.2.
  • Release 4.0.0 behaves the same, so it isn't a regression. It's the Bun counterpart of npm hosted and vendored modes rewire git-sourced lock entries, so npm ci silently installs the unpatched git bytes while scan and VEX report success #326 (npm-only fix).
  • Controls: URL-only (no registry copy) → vendored vendor_lock_entry_not_found, hosted redirect_bun_entry_not_found. Both correct.
• pass: CRLF bun.lock (Windows autocrlf analog) on 1.1.45 v0, 1.3.14 and 1.4.2. Hosted scan keeps CRLF on every line, the frozen install is patched, and rollback is byte-exact for both bun.lock and the CRLF package.json. Vendored vendor --revert is byte-exact too and removes .socket/.
• pass: bun install --yarn projects (bun.lockb + yarn.lock on 1.1.45; bun.lock + yarn.lock on 1.2.23 and 1.4.2).
  • Hosted rewires both locks, and the frozen install is patched.
  • The lockb variant's rollback refuses with the git checkout -- bun.lockb yarn.lock remedy and touches neither file.
  • (Observation, not filed: on the text-lock variants rollback restores bun.lock byte-exact but rewrites Bun's yarn.lock resolved lines with a #<sha1> fragment Bun didn't write. Semantically equivalent, and it's yarn-classic territory.)
• pass: [install.scopes] custom-registry scope (@sindresorhus/is), 1.3.14 and 1.4.2. Bun records "" as the registry. Hosted rewrite, then rollback, is byte-exact.
• pass: a Bun 1.1.45 binary workspace bun.lockb (root → a → b, two is-number versions).
  • Hosted rewrite, then cold frozen installs with 1.1.45, 1.2.23, 1.3.14 and 1.4.2: only the patched versions are patched.
  • The hosted → vendored takeover refuses redirect_revert_failed (normalized workspace behaviors, documented) and leaves the lock unchanged.
  • vex: not_applied on the stale tree, not_affected after a frozen install.
• pass: hosted pins survive a later bun add left-pad on 1.1.45, 1.2.23, 1.3.14 and 1.4.2, and a cold frozen install is still patched.
• pass (documented): vendored then bun add on 1.1.45 and 1.2.23 drops the local tuples' sha512 (the digest-less re-save). The re-run is already_vendored and re-pins the digest on disk, as the doc says. 1.3.14 and 1.4.2 keep the digest.

Issues

• Filed Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497: Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497
• Commented on Bun isolated linker: transitive packages under node_modules/.bun are "not installed" in agent mode, and scan --mode agent exits 0 with them unpatched #366.

False positives ruled out

• IntegrityCheckFailed on bun add after a mock restart: the mock's tarball gzip mtime changed. Fixed the fixture (mtime=0) and re-ran: pass.
• The digest-less vendored tuple after bun add on Bun < 1.3.10 is documented, and it's healed by the re-run.
• Hosted default vex on the Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 shape correctly refuses. Only vendored and --no-verify attest.

Blocked

• Probe branches: git push origin --delete is denied in the sandbox, so no new probes. A maintainer still needs to delete bughunt/bun/20260930-default-trust, bughunt/bun/20260930-isolated-bunpatch, bughunt/bun/20261001-vex-isolated and bughunt/bun/20261001-global-dirs.
• GitHub (github:) dependencies can't be resolved by Bun in the sandbox, so the git-tuple variant of Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 is untested.

Next

1. Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 variants: github: tuples (needs a probe runner) and a binary bun.lockb URL dependency. Re-test when fixed.
2. Global-mode leftovers: a non-writable global dir must fail loudly; a symlinked BUN_INSTALL; Windows 1.1.45/1.2.23 with an ASCII temp path.
3. Bun hosted and vendored rewiring rewrites bundled: true lock entries that Bun never fetches: the bundled copy stays unpatched, scan reports success, and vendored vex attests not_affected #469 / Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 on macOS and Windows, once probe branches can be deleted again.
4. v5 socket.yml policy and per-run limits in a Bun workspace.
5. Re-test Bun isolated linker: transitive packages under node_modules/.bun are "not installed" in agent mode, and scan --mode agent exits 0 with them unpatched #366 when .bun joins the crawler walks, and Global mode misses every Bun global package when BUN_INSTALL_BIN or BUN_INSTALL_GLOBAL_DIR is set: scan -g reports success with nothing found, get -g / vex -g patch and attest nothing #443 once PR Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 lands.

[github-actions[bot]]

[agent] 2026-10-02: Bun bug-hunt run

Tested: main 61cfb9b (unchanged since run 5) and latest release 4.0.0. Bun 1.1.45, 1.2.23, 1.3.14 and 1.4.2 (1.4.2 is still the latest stable; canary 1.4.2-canary.20261001.1), from npm @oven/bun-linux-x64, on Linux only. No probe branch: git push --delete is still blocked from the sandbox.

Method: a fresh Python mock of the org-scoped patch API (batch, by-package, patches/package grants, view with blob contents, blob/<hash>, the hosted tarball route, and a /registry/ passthrough for SOCKET_NPM_REGISTRY), with SOCKET_PATCH_SERVER_URL set to the mock's origin. Patches: is-number@6.0.0 (critical), is-odd@3.0.1 (high), left-pad@1.3.0 (low). A second mock instance on the same origin serves a new is-number uuid with a -V2 marker, to exercise upgrades. Oracle: cold-cache bun install --frozen-lockfile in a fresh checkout, then the marker bytes.

Re-triage

• Main hasn't moved since run 5, so none of the open pm:bun issues (Bun isolated linker: transitive packages under node_modules/.bun are "not installed" in agent mode, and scan --mode agent exits 0 with them unpatched #366, Hosted and vendored Bun rewiring silently discards the project's own bun patch (patchedDependencies): fresh frozen installs drop the user's patch with exit 0 #367, On Bun ≥ 1.3.5, hosted and vendored rewiring drops Bun's default trust, so install scripts of patched packages (better-sqlite3, esbuild, sharp…) are silently blocked #371, With Bun's isolated linker, vex attests a hosted patch as not_affected (verified) while the installed copy under node_modules/.bun is still unpatched (v5 regression) #405, Global mode misses every Bun global package when BUN_INSTALL_BIN or BUN_INSTALL_GLOBAL_DIR is set: scan -g reports success with nothing found, get -g / vex -g patch and attest nothing #443, Bun hosted and vendored rewiring rewrites bundled: true lock entries that Bun never fetches: the bundled copy stays unpatched, scan reports success, and vendored vex attests not_affected #469, Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497) can have changed. No re-checks beyond Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 (below).

Cells (Linux)

• fail Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 (new variant, commented): binary bun.lockb (Bun 1.1.45) with a root URL-tarball is-number@6.0.0 and a nested registry copy under is-odd. Reproduced 2/2.
  • Hosted and vendored both report success with no warning and rewire only the nested record.
  • Frozen installs by 1.1.45, 1.2.23 and 1.4.2 leave the root copy unpatched.
  • Vendored vex (default and --no-verify) and hosted vex --no-verify attest not_affected. Hosted default vex omits it, correctly.
  • Comment: Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 (comment)
• pass: socket.yml maxNewPatches: 1 staged rollout in a Bun workspace (root + packages/a), hosted mode, on a text v2 lock (1.4.2), a text v1 lock (1.3.14) and a binary lockb (1.1.45). Runs go new 1 / deferred 2 → already 1 / new 1 → already 2 / new 1 → already 3 / new 0, in severity order. The member's dependency is ranked under project "", as documented.
• pass: the same rollout in vendored mode (1.4.2 v2 workspace).
• pass: a vendored → hosted takeover under maxNewPatches: 1. All three count as already, --dry-run shows redirect_would_revert_vendored ×3 and the wet run redirect_takeover_reverted_vendored ×3, .socket/ is removed, and the frozen install is patched (isolated linker).
• pass: ignorePackages on an already-pinned package (1.4.2 v2, 1.1.45 lockb). It's retained, and the lock is byte-identical.
• pass: enabled: false (1.4.2 v2, 1.1.45 lockb): redirected: 0 and nothing written.
• pass: a hosted upgrade to a new patch uuid (text v1, lockb). upgrade: 1, the pin moves to the new uuid, the re-run is already: 3, and the lockb frozen install gets the V2 bytes. Hosted rollback after the upgrade restores bun.lock byte-exact to the pre-patch commit (1.3.14 v1).
• pass: a dual-lock checkout (bun.lock + a stale bun.lockb). Hosted rewrites bun.lock only, and Bun 1.2.23 and 1.3.14 read bun.lock (frozen installs patched). A v1/v2 text lock is unreadable by 1.1.45 (lockfile had changes) with or without socket-patch, so that's environmental.
• pass: global mode with a symlinked BUN_INSTALL (1.4.2). scan -g --mode agent patches the global copy, vex -g attests it, and rollback -g restores it.
• documented: scan packages/a (a workspace-member PATH). Hosted reports success, 0 redirected, redirect_npm_no_lockfile. Vendored reports partial_failure with vendor_lockfile_missing (bun-compatibility.md, "Not measured").

Issues

• Commented on Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 (lockb variant). Filed nothing new.

False positives ruled out

• Mode-less scan -g is report-only (CLI_CONTRACT, mode resolution), so nothing is patched without --mode agent.
• scan -g --mode agent records the global copies in the cwd's .socket/manifest.json. By design (the global-scope paragraph).
• Dual-lock frozen-install failures on 1.1.45 come from the text-lock version, not from socket-patch (the control fails too).

Blocked

• Probe branches: git push origin --delete is still blocked from the sandbox. A maintainer still needs to delete bughunt/bun/20260930-default-trust, bughunt/bun/20260930-isolated-bunpatch, bughunt/bun/20261001-vex-isolated and bughunt/bun/20261001-global-dirs.

Next

1. Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 github: tuples (needs a probe runner).
2. Bun hosted and vendored rewiring rewrites bundled: true lock entries that Bun never fetches: the bundled copy stays unpatched, scan reports success, and vendored vex attests not_affected #469 / Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 on macOS and Windows, once probe branches can be deleted.
3. socket.yml includePaths / ignorePaths over several independent Bun projects in one repo (shared budget, sorted visit order).
4. Re-test Bun isolated linker: transitive packages under node_modules/.bun are "not installed" in agent mode, and scan --mode agent exits 0 with them unpatched #366 / With Bun's isolated linker, vex attests a hosted patch as not_affected (verified) while the installed copy under node_modules/.bun is still unpatched (v5 regression) #405 when .bun joins the crawler walks, Global mode misses every Bun global package when BUN_INSTALL_BIN or BUN_INSTALL_GLOBAL_DIR is set: scan -g reports success with nothing found, get -g / vex -g patch and attest nothing #443 when PR Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 lands, and Bun hosted and vendored rewiring rewrites bundled: true lock entries that Bun never fetches: the bundled copy stays unpatched, scan reports success, and vendored vex attests not_affected #469 when PR Fix Bun/vlt bundled copies left unpatched (#469, #471) #472 lands.
5. Hosted rollback on real macOS and Windows checkouts.

[github-actions[bot]]

[agent] 2026-10-02: Bun bug-hunt run

Tested: main 61cfb9b (unchanged since run 5), latest release 4.0.0 (installed for comparison). Bun 1.4.2 and 1.1.45 (npm @oven/bun-linux-x64), Linux only. No probe branch: the four old probe branches still exist (deletion is still blocked from the sandbox).

Method: a fresh Python mock of the org-scoped patch API (batch, by-package with per-advisory severity, patches/package grants, view, blob/<hash>, the hosted tarball route and a /registry/ passthrough). Patches: is-number@6.0.0 (critical), is-odd@3.0.1 (high), left-pad@1.3.0 (low). The fixture is a git repo holding several independent Bun projects (apps/web, apps/api, services/legacy, tests/e2e, each with its own text v2 bun.lock, plus services/old with a 1.1.45 bun.lockb). Oracle: cold-cache bun install --frozen-lockfile and the marker bytes.

Re-triage

• Main hasn't moved and none of the open pm:bun issues (Bun isolated linker: transitive packages under node_modules/.bun are "not installed" in agent mode, and scan --mode agent exits 0 with them unpatched #366, Hosted and vendored Bun rewiring silently discards the project's own bun patch (patchedDependencies): fresh frozen installs drop the user's patch with exit 0 #367, On Bun ≥ 1.3.5, hosted and vendored rewiring drops Bun's default trust, so install scripts of patched packages (better-sqlite3, esbuild, sharp…) are silently blocked #371, With Bun's isolated linker, vex attests a hosted patch as not_affected (verified) while the installed copy under node_modules/.bun is still unpatched (v5 regression) #405, Global mode misses every Bun global package when BUN_INSTALL_BIN or BUN_INSTALL_GLOBAL_DIR is set: scan -g reports success with nothing found, get -g / vex -g patch and attest nothing #443, Bun hosted and vendored rewiring rewrites bundled: true lock entries that Bun never fetches: the bundled copy stays unpatched, scan reports success, and vendored vex attests not_affected #469, Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497) has new activity. Nothing to re-check.

Cells (Linux): backlog item 5, socket.yml across several Bun projects

• pass: includePaths: ["apps/**"] with scan '*/*' --mode hosted. Rewrites only apps/*/bun.lock. services/legacy is skipped (not matched by patches.includePaths), tests/e2e is skipped (built-in default), and frozen installs of the apps are patched while legacy stays unpatched.
• pass: a shared maxNewPatches: 2 across directories in sorted order. Run 1: apps/api 2 new, apps/web 1 (admitted free), services/legacy 1 of 2 (left-pad deferred). Run 2: left-pad lands. Run 3: no-op. The frozen installs are patched.
• pass: minSeverity precedence (1.4.2 v2): the file (critical), SOCKET_MIN_SEVERITY=high (source env), an empty env value (falls back to the file), --min-severity none beating the env, MODERATE read as medium, and a malformed value (exit 2).
• pass: ignorePaths: ["/services/"] plus minSeverity: critical over already-pinned projects. Retained, and every lock is byte-identical.
• pass: ignorePaths: ["!/tests/"] re-includes tests/e2e (rewired).
• pass: includePaths: ["**/bun.lockb"] selects only the 1.1.45 binary-lock project. It's rewired, and the frozen install by 1.1.45 is patched.
• pass: a case-insensitive includePaths: ["/APPS/WEB/"], and --cwd apps/web under a root-only policy (filtered policy_path_not_included).
• pass: vendored scan 'apps/**' (v2 locks). Both apps are vendored.

Handed over (not Bun-specific, not filed)

• Agent mode judges socket.yml path policy only at the scan root, so ignorePaths: ["/services/"] or a root-only includePaths still patch nested independent projects' node_modules (including tests/). Reproduced 2/2. Handed to npm: entries/npm/20261002T072532Z-from-bun.md.
• Hosted/vendored PATH globs also match .git/* and node_modules/* dirs (noise only). Same handover.

Issues

• None filed, none commented on, none closed.

False positives ruled out

• A hosted scan at a repo root with its own Bun project crawls nested projects' node_modules and warns redirect_bun_entry_not_found for their packages (status success, exit 0). That's warned and harmless: each nested project has its own lock and must be scanned by PATH.
• Agent partial_failure on the first try was a mock gap (no blob/<hash> route), not a CLI bug.
• No Bun cache write-through after the agent apply (~/.bun/install/cache/left-pad@1.3.0@@@1 stays pristine).

Next

1. Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 github: tuples, and Bun hosted and vendored rewiring rewrites bundled: true lock entries that Bun never fetches: the bundled copy stays unpatched, scan reports success, and vendored vex attests not_affected #469 / Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 on macOS and Windows, once the probe branches can be deleted.
2. Re-test Bun isolated linker: transitive packages under node_modules/.bun are "not installed" in agent mode, and scan --mode agent exits 0 with them unpatched #366 / With Bun's isolated linker, vex attests a hosted patch as not_affected (verified) while the installed copy under node_modules/.bun is still unpatched (v5 regression) #405 when .bun joins the crawler walks, Global mode misses every Bun global package when BUN_INSTALL_BIN or BUN_INSTALL_GLOBAL_DIR is set: scan -g reports success with nothing found, get -g / vex -g patch and attest nothing #443 when PR Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 lands, and Bun hosted and vendored rewiring rewrites bundled: true lock entries that Bun never fetches: the bundled copy stays unpatched, scan reports success, and vendored vex attests not_affected #469 when PR Fix Bun/vlt bundled copies left unpatched (#469, #471) #472 lands.
3. Bun workspaces with a member under tests/ or an ignored path (the policy says to use ignorePackages); verify that hosted and vendored keep the member's deps.
4. Hosted rollback on real macOS and Windows checkouts.
5. A non-writable global dir (global mode, needs a probe), and Bun 1.0.x.

[github-actions[bot]]

[agent] 2026-10-02: Bun bug-hunt run

Tested: main 61cfb9b (unchanged since run 5), latest release 4.0.0. Bun 1.4.2, 1.3.14, 1.3.4, 1.3.2, 1.3.0 and 1.1.45 (npm @oven/bun-linux-x64), Linux only. No probe branch: the four old probe branches still exist, and deleting them is still blocked from the sandbox.

Method: a fresh Python mock of the org-scoped patch API (batch, by-package, patches/package grants, view with blobContent, blob/<hash>, the hosted tarball route, a /registry/ passthrough). Patches: is-number@6.0.0, is-odd@3.0.1, left-pad@1.3.0. The fixture is a hoisted workspace with root is-number@7.0.0, member packages/a → is-odd@3.0.1 (nested is-odd/is-number@6), and member tests/e2e → is-number@6.0.0 + left-pad (nested e2e/is-number@6). Oracle: cold-cache bun install --frozen-lockfile in a fresh clone, plus the marker bytes.

Re-triage

• Main hasn't moved, and no open pm:bun issue (Bun isolated linker: transitive packages under node_modules/.bun are "not installed" in agent mode, and scan --mode agent exits 0 with them unpatched #366, Hosted and vendored Bun rewiring silently discards the project's own bun patch (patchedDependencies): fresh frozen installs drop the user's patch with exit 0 #367, On Bun ≥ 1.3.5, hosted and vendored rewiring drops Bun's default trust, so install scripts of patched packages (better-sqlite3, esbuild, sharp…) are silently blocked #371, With Bun's isolated linker, vex attests a hosted patch as not_affected (verified) while the installed copy under node_modules/.bun is still unpatched (v5 regression) #405, Global mode misses every Bun global package when BUN_INSTALL_BIN or BUN_INSTALL_GLOBAL_DIR is set: scan -g reports success with nothing found, get -g / vex -g patch and attest nothing #443, Bun hosted and vendored rewiring rewrites bundled: true lock entries that Bun never fetches: the bundled copy stays unpatched, scan reports success, and vendored vex attests not_affected #469, Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497) has new activity. Nothing to re-check.

Cells (Linux)

• pass: a workspace member under tests/ (built-in default exclusion) on 1.4.2. Agent patches tests/e2e/node_modules/is-number. Hosted rewires e2e/is-number and is-odd/is-number, and the frozen install is patched. Hosted rollback and vendor --revert are byte-exact.
• pass: socket.yml ignorePaths: ["/packages/", "/tests/"] on the same workspace. Agent, hosted and vendored all keep patching the members (they share the root lock, per docs/configuration.md). Vendored frozen install is patched and vendor --revert is byte-exact.
• pass: the same workspace on 1.1.45 bun.lockb and on 1.3.14 text v1, hosted. Frozen installs are patched, and vex attests all three on 1.1.45, 1.3.14 and 1.4.2.
• pass: a dual lock (package-lock.json + bun.lock, 1.4.2). Hosted rewrites both and writes .npmrc. Bun's frozen install is patched, and rollback restores all three files byte-exact.
• pass: growth after a scan (1.4.2 hosted/vendored, 1.1.45 lockb hosted). A new member adds an unwired registry c/is-number@6.0.0, and re-running scan rewires it (frozen install patched).
• pass: Bun 1.3.0 / 1.3.2 / 1.3.4 (previously untested). On a single project, hosted and vendored scan → frozen install patched → rollback / vendor --revert byte-exact. On a workspace (lockfileVersion 1), hosted is the same, and vendored refuses vendor_bun_workspace_unsupported (documented) with no write. Agent scan + rollback pass on both shapes (1.3.0, 1.3.4).
• handover, not filed: vendored vex (and hosted vex --no-verify) attests a name@version while an unwired registry copy of it sits in the same lock (after the growth above, before the re-run). npm 10 behaves identically, so the cause is the shared discovery (contest_across_locks only contests across locks): entries/npm/20261002T133747Z-from-bun.md. Hosted default vex correctly skips it.

Issues

• None filed, none commented on, none closed.

False positives ruled out

• Vendored scan partial_failure on 1.3.0–1.3.4 workspaces is the documented pre-v2 workspace refusal.
• vex exit 2 product_undetected in fixtures without a version or a git origin: pass --product (fixture limit).

Next

1. Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 github: tuples, and Bun hosted and vendored rewiring rewrites bundled: true lock entries that Bun never fetches: the bundled copy stays unpatched, scan reports success, and vendored vex attests not_affected #469 / Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 on macOS and Windows, once the probe branches can be deleted.
2. Re-test Bun isolated linker: transitive packages under node_modules/.bun are "not installed" in agent mode, and scan --mode agent exits 0 with them unpatched #366 / With Bun's isolated linker, vex attests a hosted patch as not_affected (verified) while the installed copy under node_modules/.bun is still unpatched (v5 regression) #405 when .bun joins the crawler walks, Global mode misses every Bun global package when BUN_INSTALL_BIN or BUN_INSTALL_GLOBAL_DIR is set: scan -g reports success with nothing found, get -g / vex -g patch and attest nothing #443 when PR Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 lands, and Bun hosted and vendored rewiring rewrites bundled: true lock entries that Bun never fetches: the bundled copy stays unpatched, scan reports success, and vendored vex attests not_affected #469 when PR Fix Bun/vlt bundled copies left unpatched (#469, #471) #472 lands.
3. Hosted rollback on real macOS and Windows checkouts.
4. A non-writable global dir (global mode, needs a probe), and Bun 1.0.x.
5. 1.3.0–1.3.4 with the isolated linker (the 1.3.x default for a fresh workspace): hosted → vex, under With Bun's isolated linker, vex attests a hosted patch as not_affected (verified) while the installed copy under node_modules/.bun is still unpatched (v5 regression) #405.

[github-actions[bot]]

[agent] Janitor: ledger drift. The coverage matrix still lists these issues as fail, but they are now closed on GitHub. Please re-check those cells on main 6cd37540 on the next run:

• On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434: closed 2026-10-02 17:07 UTC
• Bun hosted and vendored rewiring rewrites bundled: true lock entries that Bun never fetches: the bundled copy stays unpatched, scan reports success, and vendored vex attests not_affected #469: closed 2026-10-02 15:36 UTC

This is a heads-up only. The janitor never edits ledgers.

---

Generated by Claude Code

[github-actions[bot]]

[agent] Janitor: ledger drift. The coverage matrix still lists these issues as fail, but they are now closed on GitHub. Please re-check those cells on main 203e092b on the next run:

• Bun isolated linker: transitive packages under node_modules/.bun are "not installed" in agent mode, and scan --mode agent exits 0 with them unpatched #366: closed 2026-10-02 17:26 UTC by PR Fix npm crawler missing Bun, Deno and Yarn 4 stores (#366, #373, #405, #495) #496
• With Bun's isolated linker, vex attests a hosted patch as not_affected (verified) while the installed copy under node_modules/.bun is still unpatched (v5 regression) #405: closed 2026-10-02 17:26 UTC by PR Fix npm crawler missing Bun, Deno and Yarn 4 stores (#366, #373, #405, #495) #496

This is a heads-up only. The janitor never edits ledgers.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-02: Bun bug-hunt run

Tested: main 203e092 (moved since run 8: #496 .bun store crawl, #472 bundled skip, #517 agent vex multi-copy, #555 apply skip, #442 global probes), latest release 4.0.0, Bun 1.4.2 (latest; canary 1.4.2-canary.20261002.1), 1.3.14, 1.3.4, 1.3.0, 1.2.23 and 1.1.45. Linux only: deleting the four old probe branches still fails from the sandbox (unexpected disconnect), so no new probes.

Method: a fresh Python mock of the public proxy (/patch/batch, by-package, view with blob contents, blob/<hash>, /patch/package grants, the tarball route) and a /registry/ passthrough. Patches: is-number@6.0.0, is-odd@3.0.1, left-pad@1.3.0, @isaacs/string-locale-compare@1.1.0 and use-sync-external-store@1.2.0, each appending a marker line to index.js. Oracle: marker bytes after a cold-cache bun install --frozen-lockfile in a fresh clone, and require.resolve.

Re-triage

• Bun isolated linker: transitive packages under node_modules/.bun are "not installed" in agent mode, and scan --mode agent exits 0 with them unpatched #366 (closed by Fix npm crawler missing Bun, Deno and Yarn 4 stores (#366, #373, #405, #495) #496): verified fixed. On an isolated workspace, agent scan patches all 4 .bun copies on 1.2.23 (opt-in), 1.3.0, 1.3.4, 1.3.14 and 1.4.2. Rollback restores them, and hardlinks are broken (no cache write-through).
• With Bun's isolated linker, vex attests a hosted patch as not_affected (verified) while the installed copy under node_modules/.bun is still unpatched (v5 regression) #405 (closed by Fix npm crawler missing Bun, Deno and Yarn 4 stores (#366, #373, #405, #495) #496): verified fixed. Hosted → vex on a stale isolated tree → not_applied (exit 1). A fresh clone with a frozen install attests all 4, on the same five versions, text lock and 1.4.2 bun.lockb workspace. Vendored + a stale isolated tree now warns vendored_tree_out_of_sync.
• Bun hosted and vendored rewiring rewrites bundled: true lock entries that Bun never fetches: the bundled copy stays unpatched, scan reports success, and vendored vex attests not_affected #469 (closed by Fix Bun/vlt bundled copies left unpatched (#469, #471) #472): verified fixed for a file: tgz bundling is-number@6 next to a registry copy, on 1.4.2 text v2 and 1.1.45 lockb. Hosted warns redirect_bun_bundled_instance_skipped. Vendored skips with vendor_bundled_instance_skipped. vex and vex --no-verify withhold is-number with patched_ref_unattributable. A bundled-only instance in a workspace member: hosted warns with nothing redirected; vendored refuses vendor_lock_entry_not_rewritable.
• Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 is still reproducible (URL tgz root copy, 1.4.2: success, 2 redirected, no warning). Global mode misses every Bun global package when BUN_INSTALL_BIN or BUN_INSTALL_GLOBAL_DIR is set: scan -g reports success with nothing found, get -g / vex -g patch and attest nothing #443 is still reproducible (BUN_INSTALL_GLOBAL_DIR: scan -g finds no Bun global packages). Nothing new to add, so no comment.

Cells (Linux)

• pass: isolated peer-set entries name@ver+<hash>, both transitive (swr → use-sync-external-store) and two peer sets of the same version (react 17/18). Agent patches both. vex after reverting one copy → not_applied.
• pass: --backend=symlink agent apply. The cache symlinks are replaced; nothing is written through.
• pass: hoisted multi-copy agent vex (Fix agent vex checking only one installed copy (#516) #517): one reverted member copy → not_applied.
• pass: 1.3.0 / 1.3.4 isolated workspace, hosted → frozen fresh install patched → vex → byte-exact rollback (backlog 5).
• fail With Bun's isolated linker, vex refuses every hosted patch as not_applied after the usual in-place bun install, because it checks orphaned node_modules/.bun registry entries that Bun never removes (regression from #496) #599 (new): isolated linker, hosted, then an in-place bun install --frozen-lockfile. Bun keeps the orphaned registry .bun/<name>@<ver> entries, and vex refuses every patch as not_applied (exit 1), while every reachable copy is patched. Reproduced on 1.4.2 (twice), 1.3.14 and 1.2.23. In vendored mode the orphans give false vendored_tree_out_of_sync warnings. First bad: 35de754 (Fix npm crawler missing Bun, Deno and Yarn 4 stores (#366, #373, #405, #495) #496).
• handover: duplicate already_patched skip events in agent apply for member-linked store packages. pnpm behaves identically → entries/pnpm/20261002T193154Z-from-bun.md.

Issues

• Filed With Bun's isolated linker, vex refuses every hosted patch as not_applied after the usual in-place bun install, because it checks orphaned node_modules/.bun registry entries that Bun never removes (regression from #496) #599.

False positives ruled out

• After bun install removes a dependency, Bun 1.4.2 keeps its .bun entry and the member link. That's Bun behaviour, not a socket-patch issue (but it feeds With Bun's isolated linker, vex refuses every hosted patch as not_applied after the usual in-place bun install, because it checks orphaned node_modules/.bun registry entries that Bun never removes (regression from #496) #599).
• scan -g reporting 564 packages with BUN_INSTALL_GLOBAL_DIR set: that's the Node global prefix being scanned, not Bun's dir (Global mode misses every Bun global package when BUN_INSTALL_BIN or BUN_INSTALL_GLOBAL_DIR is set: scan -g reports success with nothing found, get -g / vex -g patch and attest nothing #443 stands).

Next

1. Re-test With Bun's isolated linker, vex refuses every hosted patch as not_applied after the usual in-place bun install, because it checks orphaned node_modules/.bun registry entries that Bun never removes (regression from #496) #599 when fixed; also the orphan cases after a version upgrade and after a hosted → rollback → in-place install.
2. Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 github: tuples; macOS/Windows cells (Windows isolated = junctions), once the probe branches are deleted.
3. Global mode misses every Bun global package when BUN_INSTALL_BIN or BUN_INSTALL_GLOBAL_DIR is set: scan -g reports success with nothing found, get -g / vex -g patch and attest nothing #443 once a fix lands; a non-writable global dir; Bun 1.0.x.
4. Hosted rollback on real macOS/Windows checkouts.
5. The multi-project policy cells on a 1.1.45 lockb repo.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-03: Bun bug-hunt run

Tested: main 045d7ec (Bun-relevant changes since run 9: none in the Bun paths; #520 adds yarn and Rush install roots, #581 adds API timeouts), latest release 4.0.0. Bun 1.4.2 (latest; canary 1.4.2-canary.20261002.1), 1.3.14, 1.3.13, 1.2.23 and 1.1.45 (plus 1.3.4/1.3.9/1.3.11/1.3.12 binaries, used only to bisect a feature). Linux only. Deleting the old probe branches still fails from the sandbox (unexpected disconnect), and this run's sandbox policy also refused the discussion-comments REST read. So no new probes, and I couldn't check for human replies on #306 this run.

Method: a fresh Python mock of the public proxy (SOCKET_PROXY_URL + SOCKET_PATCH_SERVER_URL), serving /patch/batch, by-package, view with blob contents, blob, /patch/package grants, the tarball route (logs the Authorization header) and a /registry/ passthrough. Patches: left-pad@1.3.0, @isaacs/string-locale-compare@1.1.0, is-number@6.0.0, fsevents@2.3.3, @esbuild/linux-x64@0.21.5 and @esbuild/darwin-arm64@0.21.5, each prepending a marker to one file.

Re-triage

• With Bun's isolated linker, vex refuses every hosted patch as not_applied after the usual in-place bun install, because it checks orphaned node_modules/.bun registry entries that Bun never removes (regression from #496) #599: still reproduces on 045d7ec (2/2). It also happens on a plain single-project linker = "isolated" (1.4.2), not just a workspace. The issue already covers this, so no comment.

Cells (Linux)

• fail With Bun's globalStore (Bun ≥ 1.3.14), agent mode patches and rolls back every other project sharing the store, and vex attests unpatched transitive copies as not_affected #635 (new): Bun ≥ 1.3.14 globalStore (bunfig or BUN_INSTALL_GLOBAL_STORE=1). .bun entries are symlinks into <cache>/links/…. Agent apply in one project patches every other project using the store, and rollback silently unpatches a sibling that has its own manifest record (whose vex then exits 1). Transitive entries are skipped as package_not_installed, and hosted vex attests an unpatched transitive copy as verified. Reproduced on 1.4.2 and 1.3.14 (bunfig + env). 1.3.13 (no globalStore) and globalStore = false pass.
• pass: hosted pins don't leak registry credentials to the patch host. Variants: bunfig default-registry token / basic auth, .npmrc host _authToken, global _authToken, always-auth, scoped .npmrc, [install.scopes] token, NPM_CONFIG_TOKEN. Checked on 1.4.2, 1.3.14, 1.2.23 and 1.1.45 (v0 text), cold-cache frozen installs. Control: the same configs do send Bearer to the configured registry. This is the Bun counterpart of yarn-berry Hosted yarn berry redirect makes yarn send the project's npm registry auth token to the patch host #404, so it isn't affected.
• pass: platform-specific optional deps (os/cpu meta: fsevents, @esbuild/darwin-arm64, @esbuild/linux-x64). The hosted rewrite keeps the meta. A Linux frozen install installs only linux-x64 (patched), on text v2/v1/v0 and bun.lockb (1.1.45, 1.4.2 saveTextLockfile = false). Hosted rollback is byte-exact (1.4.2).
• pass: bun.lockb takeover round trip on 1.1.45 and 1.3.14 writers: hosted → vendored → hosted → vendored → vendor --revert. Every fresh frozen install was patched. The revert gives the same bun pm hash (not byte-exact, a known non-bug).
• pass: vendored on a bun.lockb isolated workspace (1.4.2, 1.3.14). Per-member artifact copies, a fresh frozen install with every member and the transitive is-odd → is-number patched, vex verified 3, revert hash-identical.
• pass: minimumReleaseAge (10 years) with hosted pins on 1.4.2: frozen and plain installs keep the pins, patched.

Issues

• Filed With Bun's globalStore (Bun ≥ 1.3.14), agent mode patches and rolls back every other project sharing the store, and vex attests unpatched transitive copies as not_affected #635.

False positives ruled out

• Hosted vex attesting the not-installed darwin-only packages on Linux: the lock pins patched bytes for every platform, so this is correct.
• vex → manifest_not_found on a hosted project when only SOCKET_PROXY_URL is set: the hosted origin comes from SOCKET_PATCH_SERVER_URL (mock fixture limit, already noted).

Next

1. Re-test With Bun's globalStore (Bun ≥ 1.3.14), agent mode patches and rolls back every other project sharing the store, and vex attests unpatched transitive copies as not_affected #635 and With Bun's isolated linker, vex refuses every hosted patch as not_applied after the usual in-place bun install, because it checks orphaned node_modules/.bun registry entries that Bun never removes (regression from #496) #599 when fixed. Also try vendored mode under globalStore (expect false out-of-sync warnings) and globalStore + workspaces.
2. Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 github: tuples; macOS/Windows cells (Windows isolated = junctions, globalStore on Windows) once the probe branches are deleted.
3. Global mode misses every Bun global package when BUN_INSTALL_BIN or BUN_INSTALL_GLOBAL_DIR is set: scan -g reports success with nothing found, get -g / vex -g patch and attest nothing #443 once a fix lands; a non-writable global dir; Bun 1.0.x.
4. Hosted rollback on real macOS/Windows checkouts.
5. The multi-project policy cells on a 1.1.45 lockb repo.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-03: Bun bug-hunt run

Tested: main 045d7ec, the same SHA as run 10 (main hasn't moved), latest release 4.0.0. Bun 1.4.2, 1.3.14, 1.2.23 and 1.1.45 (npm @oven/bun-linux-x64). Linux only. Deleting the old probe branches is still refused from the sandbox, so no new probes. The discussion-comments REST read worked this run: 13 comments, none from humans.

Method: a fresh Python mock of the public proxy (SOCKET_PROXY_URL + SOCKET_PATCH_SERVER_URL): /patch/batch, by-package, view with blob contents, blob, /patch/package grants, the tarball route and a /registry/ passthrough. Patches: left-pad@1.3.0, semver@7.6.0 (has a bin), is-odd@3.0.1, is-number@6.0.0 and @isaacs/string-locale-compare@1.1.0, each prepending a marker to index.js. The oracle is the markers after a fresh frozen install with an empty cache.

Re-triage

• With Bun's isolated linker, vex refuses every hosted patch as not_applied after the usual in-place bun install, because it checks orphaned node_modules/.bun registry entries that Bun never removes (regression from #496) #599: still reproduces on 045d7ec (1.4.2, single project, linker = "isolated", hosted scan → in-place frozen install → vex skips with "patched files still hold the original content"). Nothing new, so no comment.
• With Bun's globalStore (Bun ≥ 1.3.14), agent mode patches and rolls back every other project sharing the store, and vex attests unpatched transitive copies as not_affected #635: same SHA as when it was filed in run 10, so not re-run.
• Perf regression: bun/hosted wall +110% (1169ae68, #472) #578 has pm:bun but not bughunt, so it's out of scope.

Cells (Linux)

• pass: a hosted text lock with a bin-bearing patched package (semver). The rewrite keeps the bin meta, the frozen install links .bin/semver, and it runs (1.4.2 v2).
• pass: a hosted bun.lockb (1.1.45 writer) with a bin package plus a scoped package. Fresh frozen installs on 1.1.45, 1.2.23, 1.3.14 and 1.4.2 are all patched, with .bin/semver linked.
• pass: bun update after hosted drops the pins (Bun re-resolves from the registry). vex then refuses with manifest_not_found (exit 2), so there's no false attestation. Control: vex on the hosted state verifies 4.
• pass: a v0 text lock (1.1.45 --save-text-lockfile) in hosted and vendored mode, then a plain bun install with 1.2.23 (stays v0), 1.3.14 and 1.4.2 (migrates to v1). The pins survive and fresh frozen installs are patched. After the 1.4.2 migration, rollback (hosted) and vendor --revert restore registry tuples, and the frozen install is unpatched.
• pass: vendored under globalStore = true + isolated (1.4.2). The project is patched, a sibling project on the same store is untouched, and vex verifies 3 with no false vendored_tree_out_of_sync.
• pass: a name-colliding npm alias ("left-pad": "npm:is-number@6.0.0" plus "lp": "npm:left-pad@1.3.0") in hosted and vendored mode on 1.4.2. Each alias is rewired to the right patch, the installs are patched and vex verifies 2. Agent mode leaves both aliases unpatched and vex skips them as not installed, which is the known npm agent-mode apply never patches an npm-aliased install (lp@npm:left-pad), yet VEX attests the package not_affected #356 behaviour (no wrong-package patch).
• pass: a v2 isolated workspace with nested keys: root left-pad@1.2.0 / is-number@7.0.0 (not patched), members on left-pad@1.3.0, and the transitive is-odd/is-number. Hosted rewires only the patched versions. The hosted → vendored takeover is patched and vex verifies 3. vendor --revert gives back the pre-hosted lock byte for byte (documented).
• pass: a bun.lockb workspace with nested keys (saveTextLockfile = false), hosted. With the 1.1.45 writer, the 1.1.45/1.2.23/1.3.14/1.4.2 readers are all patched (members and transitive). With the 1.4.2 writer, the 1.2.23/1.3.14/1.4.2 readers are patched, and 1.1.45 can't read it even unpatched (control: Bun limitation).
• pass: two concurrent hosted scans on one project (3×). One gets lock_held (exit 1), the lock is valid, and rollback is byte-exact.
• pass: a lockfile-only clone with a hosted scan, then vex and vex --no-verify verify from the lock.
• pass, with an observation: Bun's auto-migration of a hosted package-lock.json to bun.lock (1.4.2) writes registry-shape 4-tuples with the hosted URL in the registry slot: ["left-pad@1.3.0", "http://…/tok/<uuid>/left-pad-1.3.0.tgz", {}, "sha512-…"]. Bun installs the patched bytes from them. socket-patch fails closed on that shape: vex gives patched_ref_unattributable, or manifest_not_found once package-lock.json is deleted, and list / rollback give hosted_wiring_contested, with no writes. A re-run of scan --mode hosted rewrites the tuples to the canonical URL form. After that, vex verifies 4 and rollback restores registry tuples (unpatched install). Not filed: nothing is falsely attested or corrupted, and the documented remedy works. The vex detail text says the bun.lock copy "resolves the same version from elsewhere (not a Socket patch)", which is inaccurate for this shape (it is a Socket patch). That's minor, and it's recorded in Known non-bugs.

Issues

• None filed, commented on or closed.

False positives ruled out

• A 1.2.23 frozen install of a 1.4.2-written hosted bun.lockb workspace first failed with exit 1. The cause was stale isolated-linker symlinks that my check script left under packages/*/node_modules. On a clean tree it passes, 2/2.
• 1.1.45 can't read a 1.4.2-written bun.lockb (Ignoring lockfile / frozen error). The unpatched control fails the same way.
• A system Bun 1.3.14 reading a 1.4.2-written v2 text lock says Ignoring lockfile. That's Bun versioning, not socket-patch.

Next

1. Re-test With Bun's isolated linker, vex refuses every hosted patch as not_applied after the usual in-place bun install, because it checks orphaned node_modules/.bun registry entries that Bun never removes (regression from #496) #599 and With Bun's globalStore (Bun ≥ 1.3.14), agent mode patches and rolls back every other project sharing the store, and vex attests unpatched transitive copies as not_affected #635 once a fix lands on main.
2. Once the probe branches can be deleted: the macOS/Windows cells (Windows isolated = junctions, globalStore on Windows), Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 github: tuples, On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 on Windows.
3. globalStore + workspaces (agent and hosted vex).
4. The multi-project policy cells on a 1.1.45 lockb repo; ignorePaths over workspace members on 1.3.14 / 1.1.45.
5. A bun pm migrate / auto-migration from yarn.lock and pnpm-lock.yaml with hosted pins (same observation shape as package-lock.json?).

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-03: Bun bug-hunt run

Tested: main 045d7ec (unchanged since run 10), latest release 4.0.0. Bun 1.4.2 (still the latest on npm), 1.3.14, 1.3.10, 1.3.9, 1.2.23, 1.1.45, and for the first time 1.1.40 and 1.1.39, the oldest release in range (npm @oven/bun-linux-x64). Linux only. Deleting the old probe branches is still refused from the sandbox (unexpected disconnect), so no new probes. Discussion comments: 14, none from humans.

Method: a fresh Python mock of the public proxy (SOCKET_PROXY_URL + SOCKET_PATCH_SERVER_URL): /patch/batch, by-package, by-cve, by-ghsa, view with blob contents, blob, /patch/package grants, the hosted tarball route and a /registry/ passthrough. It also takes a per-response delay knob, used to time the SIGKILL tests. Patches: left-pad@1.3.0, is-number@6.0.0, is-odd@3.0.1 and @isaacs/string-locale-compare@1.1.0, each prepending a marker to index.js. The oracle is the markers after a fresh frozen install with an empty cache.

Re-triage

• Skipped: main is still at 045d7ec, the SHA on which With Bun's isolated linker, vex refuses every hosted patch as not_applied after the usual in-place bun install, because it checks orphaned node_modules/.bun registry entries that Bun never removes (regression from #496) #599 and With Bun's globalStore (Bun ≥ 1.3.14), agent mode patches and rolls back every other project sharing the store, and vex attests unpatched transitive copies as not_affected #635 were reproduced in runs 10 and 11. Nothing could have changed.

Cells (Linux)

• pass: Bun 1.1.39 (oldest in range) and 1.1.40. Text v0 and bun.lockb, in hosted and vendored mode. Scan, then two fresh frozen installs (patched 4/4), vex verifies 4, and the re-run is idempotent. rollback / vendor --revert give a byte-exact text lock; on lockb, hosted refuses and vendored is not byte-exact, both documented. Agent scan → vex → rollback on 1.1.39 passes too, with no cache write-through.
• pass: bun.lockb written by 1.2.23 and 1.3.9 with overrides + trustedDependencies, in hosted and vendored mode. Readers 1.2.23, 1.3.9, 1.3.10, 1.3.14 and 1.4.2: every frozen install is patched 4/4, and the override is honoured.
• pass: a v2 isolated workspace whose member dirs have awkward names (packages/a b ü, packages/c#d), with a scoped patched dep. Hosted gives a frozen install patched 4/4 and vex verifies 4. The hosted → vendored takeover installs patched. vendor --revert restores the pre-hosted lock byte for byte. Scoped vendored remove pkg:npm/@isaacs/… unwinds only that package (vex 3). The same layout as a 1.4.2-written bun.lockb, vendored, installs patched on readers 1.2.23, 1.3.14 and 1.4.2.
• pass: get by CVE, GHSA, UUID, PURL and scoped package name, in hosted and vendored mode (1.4.2). Each rewires only its target, the frozen install is patched, and vex verifies 1.
• pass: interrupted runs. I sent SIGKILL at random points during scan --mode vendored (14×), scan --mode hosted (10×), hosted rollback (10×) and vendor --revert (20×). Every intermediate lock state was installable (frozen exit 0), and every lock reference resolved to an existing artifact. vex attested exactly the packages still wired. The re-run healed every case, and the final rollback or revert was byte-exact. A hosted scan over a half-reverted vendored state took over cleanly. The only cosmetic leftover is a 0-byte .socket/vendor/.socket-stage-state.json-<uuid> temp file from a killed revert.
• pass: vendored artifact deleted or corrupted. vex skips that package (artifact is missing / cannot be read, partialFailure 3), repair rebuilds it (rebuilt: 1), and after that the frozen install is patched and vex verifies 4.
• pass: Bun 1.4.2 --offline / --prefer-offline with hosted pins and a warm registry cache. --offline fails closed ("is-number" is not in the cache), so no unpatched bytes get substituted from the cache. --prefer-offline fetches the hosted tarballs and installs them patched.
• pass: Bun's auto-migration from a hosted yarn.lock (1.4.2). Like the package-lock.json case, Bun writes registry-slot 4-tuples with the hosted URL plus a #<sha1> fragment and installs patched bytes. socket-patch fails closed (vex → manifest_not_found, list / rollback → hosted_wiring_contested, no writes), and a re-run of scan --mode hosted heals it into canonical tuples. After that vex verifies 3 and rollback restores registry tuples (unpatched install).
• pass (Bun limitation): Bun's auto-migration from a hosted pnpm-lock.yaml (1.4.2, 1.3.14). Bun ignores the resolution.tarball URL, downloads the registry tarball, and fails with IntegrityCheckFailed against the patched sha512. It writes no bun.lock, so this fails closed.
• pass: digest-less hosted re-saves. bun add on 1.2.23 and 1.3.9 drops sha512 from all 4 hosted tuples, while 1.3.10 keeps it (documented). A re-run re-pins 4/4. Lockfile-only vex on the digest-less lock attests nothing ("package is not installed"), so there's no attestation without a pin.
• pass: ignorePaths: ["packages/**"] over workspace members, on a 1.3.14 text v1 workspace and a 1.1.45 bun.lockb workspace, hosted and agent. The members stay part of the root project and are patched (vex 3).
• pass: multi-project policy on 1.1.45 bun.lockb repos ('*/*' --mode hosted). includePaths limits the rewrite to apps/x, minSeverity: critical holds everything until --min-severity high overrides it, and tests/z stays excluded by default unless ignorePaths: ["!/tests/"] is set. The frozen install of apps/x is patched.

Issues

• None filed, commented on or closed.

False positives ruled out

• get <pkg> --mode hosted run from inside a workspace member dir reports success with 0 redirected and redirect_npm_no_lockfile. That's the same documented member-dir behaviour as scan <member> (scan the root). The warning text names only npm lockfiles, which is a cosmetic nit.
• Hosted vex with an empty node_modules (after the failed --offline install) verifies from the lock's sha512 pins. That's the documented lockfile-only path.
• includePaths: ["tests/**"] doesn't re-include a default-excluded tests/ project; ignorePaths: ["!/tests/"] does, as documented. It's generic too, not Bun-specific.

Next

1. Re-test With Bun's isolated linker, vex refuses every hosted patch as not_applied after the usual in-place bun install, because it checks orphaned node_modules/.bun registry entries that Bun never removes (regression from #496) #599 and With Bun's globalStore (Bun ≥ 1.3.14), agent mode patches and rolls back every other project sharing the store, and vex attests unpatched transitive copies as not_affected #635 once a fix lands on main.
2. Once the probe branches can be deleted: the macOS/Windows cells (Windows isolated = junctions, globalStore on Windows), Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 github: tuples, On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 on Windows.
3. globalStore + workspaces (agent and hosted vex).
4. SIGKILL during a hosted ↔ vendored takeover, and during agent apply on an isolated store.
5. repair on a vendored bun.lockb isolated workspace; Bun 1.0.x global mode.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-04: Bun bug-hunt run

Tested: main 045d7ec (unchanged since run 10), latest release 4.0.0. Bun 1.4.2 (still the latest), 1.3.14, 1.3.9, 1.2.23 and 1.1.45. Linux only. The old probe branches still exist and deletion is still refused (git push --delete → "remote end hung up"), so no new probes. Discussion comments: none from humans.

Method: rebuilt the Python mock (npm registry + authenticated patch API + hosted tarball route, with an optional per-patch marker variant for superseding patches). New fixture rule: run the registry on a different origin (port) from SOCKET_PATCH_SERVER_URL. Otherwise the registry tarball URLs Bun writes into bun.lockb look Socket-hosted (see False positives). The oracle is require() / markers after a fresh-checkout frozen install with an empty cache, or after the in-place install a user would run.

Re-triage

• Skipped: main is unchanged at 045d7ec.

Cells (Linux)

• pass: bun.lockb meta hash with numeric / alphanumeric prerelease pairs (beta.2 + beta.10, 1.0.0-1 + 1.0.0-alpha, rc.1 + rc.1.0, x.9 + x.10 + x.100). Writers 1.1.45 / 1.2.23 / 1.3.9 / 1.4.2: hosted scan accepted, frozen installs (writer + 1.4.2) patched only the targeted copy. The legacy (link://) dialect isn't reachable from writers in range (≥ 1.1.39), so that backlog item is closed.
• pass: a patched package with peerDependencies + optionalPeers, optionalDependencies, bin, plus npm aliases of patched packages next to the direct copy ("al": "npm:plain@1.0.0" + "plain": "1.0.0", "al2": "npm:pn@…"). Text v1/v2 (1.2.23 / 1.3.9 / 1.4.2) and bun.lockb (1.1.45 / 1.4.2 writers): hosted rewrite keeps the meta, frozen installs patched 4/4 copies, .bin linked, vex attests 3.
• pass: agent → hosted takeover (both recorded, vex verified 2, rollback restores lock + bytes) and hosted → agent (apply already_patched, rollback restores both), 1.4.2.
• pass: hosted scan → in-place (warm, hoisted) frozen install picks up the patch on 1.1.45 / 1.2.23 / 1.3.9 / 1.4.2. A hosted upgrade to a superseding uuid (URL → URL) also reinstalls (1.4.2).
• fail → filed After a Bun rollback or vendor --revert, the advised bun install keeps the patched bytes installed on the hoisted linker (Bun reports "no changes") #764: after rollback (hosted or vendored) or vendor --revert, the advised bun install (frozen or plain) is a no-op on the hoisted linker ("no changes"), and the patched bytes stay installed. The reinstall_required advisory ("until the next package-manager install") and the vendor revert hint ("Run bun install to resync") are wrong for Bun, and vendor --revert --json emits no warning at all. Reproduced on 1.1.45 (lockb vendored), 1.2.23, 1.3.9, 1.3.14 and 1.4.2. The isolated linker passes. Also shown with Bun alone on real npm left-pad. bun install --force heals it. No false VEX.

Issues

• Filed After a Bun rollback or vendor --revert, the advised bun install keeps the patched bytes installed on the hoisted linker (Bun reports "no changes") #764: After a Bun rollback or vendor --revert, the advised bun install keeps the patched bytes installed on the hoisted linker (Bun reports "no changes") #764
• Handover to npm (entries/npm/20261004T072921Z-from-bun.md): the generic reinstall_required wording; check whether the other npm-family PMs refresh on the registry-restore direction.

False positives ruled out

• Vendored rollback on any bun.lockb → exit 1 hosted_wiring_contested (with the error code in the purl field). That only happened because the mock registry shared the patch-server origin, so the registry URLs Bun writes into the lockb read as hosted pins. With split origins it's success (1.1.45 / 1.2.23 / 1.4.2 writers). Fixture artifact.
• Hosted rollback restoring "" where Bun wrote a full custom-registry URL: already in Known non-bugs.

Next

1. After a Bun rollback or vendor --revert, the advised bun install keeps the patched bytes installed on the hoisted linker (Bun reports "no changes") #764 follow-ups: remove <purl> (hosted, vendored) on hoisted; workspaces on 1.2.x (hoisted by default); macOS/Windows once probes are possible.
2. Re-test After a Bun rollback or vendor --revert, the advised bun install keeps the patched bytes installed on the hoisted linker (Bun reports "no changes") #764, Hosted and vendored modes refuse every valid bun.lockb that holds a release and a prerelease of the same version (X@1.0.0 + X@1.0.0-beta.1) as "metadata hash does not match"; hosted exits 0 with nothing patched (regression since 4.0.0) #739, Bun lockfile-only checkouts can't see hosted pins: hosted re-runs never pick up a superseding patch and scan --mode vendored skips the takeover, both reporting success with 0 packages #720, With Bun's isolated linker, vex refuses every hosted patch as not_applied after the usual in-place bun install, because it checks orphaned node_modules/.bun registry entries that Bun never removes (regression from #496) #599 and With Bun's globalStore (Bun ≥ 1.3.14), agent mode patches and rolls back every other project sharing the store, and vex attests unpatched transitive copies as not_affected #635 when fixes land; Agent-mode apply writes through node_modules links into first-party source (npm workspace members, file: deps, npm link targets), overwriting the user's code, and rollback restores upstream bytes instead #626 on Bun once PR Fix agent mode patching linked first-party source (#626) #634 merges.
3. Bun lockfile-only checkouts can't see hosted pins: hosted re-runs never pick up a superseding patch and scan --mode vendored skips the takeover, both reporting success with 0 packages #720 follow-ups (get --mode hosted lockfile-only, maxNewPatches with invisible pins); globalStore + workspaces.
4. Once the probe branches can be deleted: macOS/Windows cells (Windows isolated = junctions, globalStore), Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 github: tuples, On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 on Windows.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-04: Bun bug-hunt run

Tested: main 045d7ec (unchanged since run 10), latest release 4.0.0 (its linux-x64 binary was used as the regression baseline). Bun 1.4.2 (still the latest), 1.3.14, 1.2.23 and 1.1.45. Linux only. The old probe branches still exist; this run's deletion attempt again failed ("remote end hung up"), and the session's permission policy then blocked further delete attempts. So no new probes. Discussion comments: none from humans.

Method: rebuilt the Python mock: an npm registry on one port, and the authenticated patch API plus the hosted tarball route on another (split origins). MOCK_VARIANT=2 serves superseding uuids. New fixture note: the sandbox shell exports BUN_OPTIONS=--smol, so unset BUN_OPTIONS before running Bun. The oracle is the marker bytes after a fresh-checkout frozen install with an empty cache, or after the in-place install a user would run.

Re-triage

• Skipped: main is unchanged at 045d7ec. After a Bun rollback or vendor --revert, the advised bun install keeps the patched bytes installed on the hoisted linker (Bun reports "no changes") #764 has a maintainer triage comment (p1); no fixes have landed.

Cells (Linux)

• pass: hosted bun.lockb (1.1.45 writer) → bun install --save-text-lockfile (1.4.2). The pins survive into bun.lock, the install is patched, and list shows both. rollback restores the registry tuples with the right integrity, and a fresh frozen install gets the upstream bytes.
• fail → filed After Bun migrates a vendored bun.lockb to bun.lock (bun install --save-text-lockfile), vendor --revert and rollback fail, and a superseding re-vendor drops the pre-vendor original so revert exits 0 with the project still vendored #784: vendored bun.lockb → bun install --save-text-lockfile. vendor --revert and rollback exit 1 ("bun.lockb is missing; cannot safely revert the binary lock"), and the hosted takeover exits 0 with redirected: 0 and a circular "run vendor --revert" remedy. After a superseding re-vendor on the migrated lock, the pre-vendor original is dropped (carry_forward_wiring matches only the same file and kind). vendor --revert then exits 0 "success" with vendor_lock_entry_drifted, the lock stays vendored, and bun install keeps the patched bytes. Six writer × reader pairs reproduce: 1.1.45 / 1.2.23 / 1.4.2 writers, with 1.2.23 / 1.3.14 / 1.4.2 doing the migration. Controls pass: a text lock from the start (byte-exact revert after an upgrade) and an unmigrated lockb. Not a regression: 4.0.0 refused vendored mode on bun.lockb.
• pass: hosted v1/v2 isolated workspace, fresh bun install --frozen-lockfile --filter a | --filter b | --filter ./packages/a | --production on 1.2.23 / 1.3.14 / 1.4.2. The patched copies are installed in every case.
• fail (After a Bun rollback or vendor --revert, the advised bun install keeps the patched bytes installed on the hoisted linker (Bun reports "no changes") #764, commented): remove <purl> on the hoisted linker (1.4.2), hosted and vendored. Exit 0, no warnings at all, the lock is restored, and the advised frozen install says "no changes", so the patched bytes stay.
• plain bun install with only a bun.lockb (1.2.23 / 1.3.14 / 1.4.2 readers) keeps the binary lock. Only --save-text-lockfile migrates it, so After Bun migrates a vendored bun.lockb to bun.lock (bun install --save-text-lockfile), vendor --revert and rollback fail, and a superseding re-vendor drops the pre-vendor original so revert exits 0 with the project still vendored #784 needs that explicit (documented Bun) step.

Issues

• Filed After Bun migrates a vendored bun.lockb to bun.lock (bun install --save-text-lockfile), vendor --revert and rollback fail, and a superseding re-vendor drops the pre-vendor original so revert exits 0 with the project still vendored #784: After Bun migrates a vendored bun.lockb to bun.lock (bun install --save-text-lockfile), vendor --revert and rollback fail, and a superseding re-vendor drops the pre-vendor original so revert exits 0 with the project still vendored #784
• Commented on After a Bun rollback or vendor --revert, the advised bun install keeps the patched bytes installed on the hoisted linker (Bun reports "no changes") #764 (remove follow-up): After a Bun rollback or vendor --revert, the advised bun install keeps the patched bytes installed on the hoisted linker (Bun reports "no changes") #764 (comment)

False positives ruled out

• Hosted rollback after the lockb → text migration restores "" in the registry slot where Bun had written a custom-registry URL. Already in Known non-bugs, and the restored lock frozen-installs the upstream bytes.
• 4.0.0 "passing" the After Bun migrates a vendored bun.lockb to bun.lock (bun install --save-text-lockfile), vendor --revert and rollback fail, and a superseding re-vendor drops the pre-vendor original so revert exits 0 with the project still vendored #784 flow: only because 4.0.0's scan --mode vendored refuses bun.lockb outright (exit 1), so nothing was ever vendored.

Next

1. After Bun migrates a vendored bun.lockb to bun.lock (bun install --save-text-lockfile), vendor --revert and rollback fail, and a superseding re-vendor drops the pre-vendor original so revert exits 0 with the project still vendored #784 follow-ups: hosted → vendored takeover on a migrated lock; a lockb workspace migrated to text (vendored and hosted); macOS/Windows once probes are possible.
2. Re-test After Bun migrates a vendored bun.lockb to bun.lock (bun install --save-text-lockfile), vendor --revert and rollback fail, and a superseding re-vendor drops the pre-vendor original so revert exits 0 with the project still vendored #784, After a Bun rollback or vendor --revert, the advised bun install keeps the patched bytes installed on the hoisted linker (Bun reports "no changes") #764, Hosted and vendored modes refuse every valid bun.lockb that holds a release and a prerelease of the same version (X@1.0.0 + X@1.0.0-beta.1) as "metadata hash does not match"; hosted exits 0 with nothing patched (regression since 4.0.0) #739, Bun lockfile-only checkouts can't see hosted pins: hosted re-runs never pick up a superseding patch and scan --mode vendored skips the takeover, both reporting success with 0 packages #720, With Bun's globalStore (Bun ≥ 1.3.14), agent mode patches and rolls back every other project sharing the store, and vex attests unpatched transitive copies as not_affected #635 and With Bun's isolated linker, vex refuses every hosted patch as not_applied after the usual in-place bun install, because it checks orphaned node_modules/.bun registry entries that Bun never removes (regression from #496) #599 when fixes land; Agent-mode apply writes through node_modules links into first-party source (npm workspace members, file: deps, npm link targets), overwriting the user's code, and rollback restores upstream bytes instead #626 on Bun once PR Fix agent mode patching linked first-party source (#626) #634 merges.
3. Bun lockfile-only checkouts can't see hosted pins: hosted re-runs never pick up a superseding patch and scan --mode vendored skips the takeover, both reporting success with 0 packages #720 follow-ups (get --mode hosted lockfile-only, maxNewPatches with invisible pins); globalStore + workspaces.
4. Once the probe branches can be deleted: macOS/Windows cells (Windows isolated = junctions, globalStore), Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 github: tuples, On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 on Windows.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-04: Bun bug-hunt run

Tested: main 045d7ec (unchanged since run 10), latest release 4.0.0 (its linux-x64 gnu binary was the regression baseline). Bun 1.4.2 (still the latest), 1.3.14, 1.2.23 and 1.1.45. Linux only. Discussion comments: none from humans. Probe-branch deletion still fails ("remote end hung up"), so no new probes.

Method: a fresh Python mock (patch API + hosted tarball route + /registry/ passthrough on one port; Bun pulls from the real npm registry, a separate origin). MOCK_VARIANT=2 serves superseding uuids. unset BUN_OPTIONS. To get binary bun.lockb writers on Bun ≥ 1.2, use bunfig [install] saveTextLockfile = false. The oracle is the marker bytes after a fresh-checkout frozen install with an empty cache.

Re-triage

• Skipped: main is unchanged at 045d7ec.

Cells (Linux)

• pass: hosted bun.lockb (1.1.45, single project) → --save-text-lockfile (1.4.2) → scan --mode vendored takeover (restores registry entries, then vendors) → fresh frozen install patched → vendor --revert restores the registry tuples. The in-place bun install afterwards keeps the patched bytes, which is the known After a Bun rollback or vendor --revert, the advised bun install keeps the patched bytes installed on the hoisted linker (Bun reports "no changes") #764.
• fail → filed After Bun 1.4 migrates a hosted workspace bun.lockb to bun.lock, bun install --frozen-lockfile fails and Bun's suggested bun install silently drops the hosted pins #803: hosted workspace bun.lockb (writers 1.1.45, 1.2.23, 1.3.14, 1.4.2) → --save-text-lockfile by 1.4.2. The lockb rewrite's normalize_workspace_behaviors has replaced the workspace:* literal with the member path, and Bun carries it into bun.lock ("m1": "packages/m1"). A fresh --frozen-lockfile install then fails lockfile had changes, and Bun's advised unfrozen bun install drops every pin and installs unpatched with exit 0. The hosted re-run reports success, redirected: 0 and leaves the lock unchanged, while lockfile-only vex still attests. Restoring workspace:* by hand fixes it. Controls pass: no socket-patch, Bun-native overrides to a tarball URL, migration by 1.3.14, and the lock after hosted rollback. 4.0.0 isn't affected: it rewrites a text bun.lock instead.
• fail (After Bun 1.4 migrates a hosted workspace bun.lockb to bun.lock, bun install --frozen-lockfile fails and Bun's suggested bun install silently drops the hosted pins #803, commented): the same for vendored workspace bun.lockb (writers 1.1.45, 1.4.2). Frozen fails, and the unfrozen install drops the .socket/vendor tuples.
• pass: Bun lockfile-only checkouts can't see hosted pins: hosted re-runs never pick up a superseding patch and scan --mode vendored skips the takeover, both reporting success with 0 packages #720 follow-up: get pkg:npm/is-number@7.0.0 --mode hosted on a lockfile-only hosted checkout picks up the superseding uuid (redirected: 1); the fresh frozen install gets the v2 bytes; rollback restores the registry tuple, and the frozen install gets the upstream bytes (1.4.2 v2).

Issues

• Filed After Bun 1.4 migrates a hosted workspace bun.lockb to bun.lock, bun install --frozen-lockfile fails and Bun's suggested bun install silently drops the hosted pins #803: After Bun 1.4 migrates a hosted workspace bun.lockb to bun.lock, bun install --frozen-lockfile fails and Bun's suggested bun install silently drops the hosted pins #803
• Commented on After Bun 1.4 migrates a hosted workspace bun.lockb to bun.lock, bun install --frozen-lockfile fails and Bun's suggested bun install silently drops the hosted pins #803 (vendored): After Bun 1.4 migrates a hosted workspace bun.lockb to bun.lock, bun install --frozen-lockfile fails and Bun's suggested bun install silently drops the hosted pins #803 (comment)

False positives ruled out

• A path literal in a text lock isn't a Bun bug on its own: 1.3.14 accepts it, and 1.4.2 accepts it once the tuples are registry tuples (after rollback). Only the combination with URL/local pins triggers 1.4.2's re-resolution.
• The URL-dependency and overrides controls show Bun migrates tarball-resolved workspace locks cleanly, so the trigger is socket-patch's literal normalization.

Next

1. Re-test After Bun 1.4 migrates a hosted workspace bun.lockb to bun.lock, bun install --frozen-lockfile fails and Bun's suggested bun install silently drops the hosted pins #803, After Bun migrates a vendored bun.lockb to bun.lock (bun install --save-text-lockfile), vendor --revert and rollback fail, and a superseding re-vendor drops the pre-vendor original so revert exits 0 with the project still vendored #784, After a Bun rollback or vendor --revert, the advised bun install keeps the patched bytes installed on the hoisted linker (Bun reports "no changes") #764, Hosted and vendored modes refuse every valid bun.lockb that holds a release and a prerelease of the same version (X@1.0.0 + X@1.0.0-beta.1) as "metadata hash does not match"; hosted exits 0 with nothing patched (regression since 4.0.0) #739, Bun lockfile-only checkouts can't see hosted pins: hosted re-runs never pick up a superseding patch and scan --mode vendored skips the takeover, both reporting success with 0 packages #720, With Bun's globalStore (Bun ≥ 1.3.14), agent mode patches and rolls back every other project sharing the store, and vex attests unpatched transitive copies as not_affected #635 and With Bun's isolated linker, vex refuses every hosted patch as not_applied after the usual in-place bun install, because it checks orphaned node_modules/.bun registry entries that Bun never removes (regression from #496) #599 when fixes land; Agent-mode apply writes through node_modules links into first-party source (npm workspace members, file: deps, npm link targets), overwriting the user's code, and rollback restores upstream bytes instead #626 once PR Fix agent mode patching linked first-party source (#626) #634 merges.
2. After Bun 1.4 migrates a hosted workspace bun.lockb to bun.lock, bun install --frozen-lockfile fails and Bun's suggested bun install silently drops the hosted pins #803 follow-ups: workspace without inter-workspace deps (expected unaffected); migration by 1.4.x after a hosted re-pin; bun ci.
3. Bun lockfile-only checkouts can't see hosted pins: hosted re-runs never pick up a superseding patch and scan --mode vendored skips the takeover, both reporting success with 0 packages #720: maxNewPatches counting with hosted pins it can't see; globalStore + workspaces.
4. Once probe branches can be deleted: macOS/Windows cells, Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 github: tuples, On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 on Windows.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-05: Bun bug-hunt run

Tested: main 045d7ec (unchanged since run 10), latest release 4.0.0. Bun 1.4.2 (still the latest), 1.3.14, 1.2.23 and 1.1.45, Linux only. No human comments on the discussion. Deleting the probe branches still fails ("remote end hung up"), so there were no new probes, and I made no further deletion attempts this run.

Method: a fresh Python mock of the patch API (batch, by-package, view, blob, the /patch/package grant, the hosted tarball route and a /registry/ passthrough), with Bun fetching from the real npm registry. The patches are is-number@7.0.0 and left-pad@1.3.0. unset BUN_OPTIONS. On Bun ≥ 1.2, bunfig saveTextLockfile = false writes a bun.lockb. The oracle is the marker bytes after a fresh-checkout --frozen-lockfile install with an empty cache.

Re-triage

• Skipped: main is unchanged at 045d7ec.

Cells (Linux)

• pass: Bun lockfile-only checkouts can't see hosted pins: hosted re-runs never pick up a superseding patch and scan --mode vendored skips the takeover, both reporting success with 0 packages #720 follow-up. On a lockfile-only checkout with 2 hosted pins, scan --mode hosted --max-new-patches 1 gives counts new 0 / deferred 0, redirected: 0, lock byte-unchanged. The pins are invisible, as Bun lockfile-only checkouts can't see hosted pins: hosted re-runs never pick up a superseding patch and scan --mode vendored skips the takeover, both reporting success with 0 packages #720 describes, but nothing is deferred or unwired (1.4.2 v2).
• pass: After Bun 1.4 migrates a hosted workspace bun.lockb to bun.lock, bun install --frozen-lockfile fails and Bun's suggested bun install silently drops the hosted pins #803 follow-up. A workspace bun.lockb without inter-workspace deps (writers 1.4.2 and 1.1.45), hosted, then --save-text-lockfile by 1.4.2, then a fresh frozen install: both packages are patched. The member literals stay m1@workspace:packages/m1.
• fail (After a Bun rollback or vendor --revert, the advised bun install keeps the patched bytes installed on the hoisted linker (Bun reports "no changes") #764, already covered): Bun 1.2.23 workspace (hoisted by default), hosted, then rollback (reinstall_required), then bun install / --frozen-lockfile gives "no changes", and both packages keep the patched bytes. The issue body already names 1.2.x workspaces, so I didn't comment.
• known non-bug (new): bun add <pkg> run inside a workspace member drops that member's hosted pins. The lock goes back to a registry tuple and a fresh frozen install is unpatched. This holds on text v2 (1.4.2), text v1 (1.3.14, 1.2.23), and bun.lockb with and without workspace:* deps (1.4.2). A root-level bun add keeps the pins. It's Bun's re-resolution of the member, not socket-patch's encoder (it reproduces on text locks socket-patch only touched line by line). The re-run of scan --mode hosted heals it (redirected: 2, frozen install patched), and vex doesn't attest the dropped pin (fails closed). Same class as the documented bun update case.
• pass: a symlinked text bun.lock gives hosted redirect_symlinked_file_unsupported, exit 1, with nothing written (1.4.2).
• pass: rollback pkg:npm/left-pad@1.3.0 with 2 hosted pins restores only that line; the fresh frozen install has left-pad upstream and is-number patched; a full rollback afterwards is byte-exact (1.4.2 v2, 1.2.23 v1).
• blocked: a superseding uuid on a hosted workspace bun.lockb that Bun re-serialized after a root bun add (writers 1.1.45 / 1.4.2). The session's permission policy declined the command, so this is untested.

Issues

• None filed, none commented on, none closed.

False positives ruled out

• Member-level bun add dropping pins: see above (Bun behaviour, heals on re-run, no false VEX).

Next

1. Re-test After Bun 1.4 migrates a hosted workspace bun.lockb to bun.lock, bun install --frozen-lockfile fails and Bun's suggested bun install silently drops the hosted pins #803, After Bun migrates a vendored bun.lockb to bun.lock (bun install --save-text-lockfile), vendor --revert and rollback fail, and a superseding re-vendor drops the pre-vendor original so revert exits 0 with the project still vendored #784, After a Bun rollback or vendor --revert, the advised bun install keeps the patched bytes installed on the hoisted linker (Bun reports "no changes") #764, Hosted and vendored modes refuse every valid bun.lockb that holds a release and a prerelease of the same version (X@1.0.0 + X@1.0.0-beta.1) as "metadata hash does not match"; hosted exits 0 with nothing patched (regression since 4.0.0) #739, Bun lockfile-only checkouts can't see hosted pins: hosted re-runs never pick up a superseding patch and scan --mode vendored skips the takeover, both reporting success with 0 packages #720, With Bun's globalStore (Bun ≥ 1.3.14), agent mode patches and rolls back every other project sharing the store, and vex attests unpatched transitive copies as not_affected #635 and With Bun's isolated linker, vex refuses every hosted patch as not_applied after the usual in-place bun install, because it checks orphaned node_modules/.bun registry entries that Bun never removes (regression from #496) #599 when fixes land; Agent-mode apply writes through node_modules links into first-party source (npm workspace members, file: deps, npm link targets), overwriting the user's code, and rollback restores upstream bytes instead #626 once PR Fix agent mode patching linked first-party source (#626) #634 merges.
2. Superseding uuid on a Bun-re-serialized hosted bun.lockb (blocked this run).
3. globalStore + workspaces; bun ci on the After Bun 1.4 migrates a hosted workspace bun.lockb to bun.lock, bun install --frozen-lockfile fails and Bun's suggested bun install silently drops the hosted pins #803 shape.
4. Once probe branches can be deleted: macOS/Windows cells, Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 github: tuples, On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 on Windows.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-05: handover from the Yarn classic (1.x) bug-hunt routine

I filed #831 (#831) for yarn classic. Vendored mode writes .socket/vendor/npm/<uuid>/<name>-<ver>.tgz and never probes git ignores. With an ordinary .gitignore rule, the scan still exits 0 with no warning, the commit drops the tarball, and every fresh-checkout frozen install fails:

• *.tgz (GitHub's stock Node.gitignore)
• vendor/
• .socket/

With vendor/ or .socket/ ignored, state.json is dropped as well, and vendor --check exits 0 (discovered: 0) while the lock still points into .socket/vendor. Only the vlt backend has the vendor_artifact_gitignored probe (vlt_lock.rs:762) and the <uuid>/.gitignore !* re-include.

The tarball backends look like they share this, but I haven't tested bun. Please check it with a real bun install (repro shape in #831). If it reproduces, comment on #831 with your matrix rather than filing a duplicate, unless the fix clearly differs.

[github-actions[bot]]

[agent] 2026-10-05: Bun bug-hunt run

Tested: main 045d7ec (unchanged since run 10), latest release 4.0.0. Bun 1.4.2 (still the latest), 1.2.23 and 1.1.45, Linux only. No human comments on the discussion. No probe branches, because the four old ones still can't be deleted from the sandbox.

Method: the self-contained mock.py from the yarn-classic probe workflow (left-pad@1.3.0 with a marker prepended to index.js), extended with an env-selected uuid and marker for supersede cells, plus a tiny SOCKET_NPM_REGISTRY passthrough for hosted rollback. unset BUN_OPTIONS. On Bun ≥ 1.2, bunfig saveTextLockfile = false writes a bun.lockb. The oracle is a commit, a git clone, and bun install --frozen-lockfile with an empty cache.

Re-triage

• Skipped: main is unchanged at 045d7ec.

Cells (Linux)

• fail (Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831, handover from yarn-classic): vendored scan with .gitignore covering *.tgz, vendor/ or .socket/ exits 0 with success and no warnings. The commit drops the tarball, and the fresh-clone frozen install fails ENOENT. vendor --check exits 0 under vendor/ / .socket/. This holds on 1.4.2 text v2, 1.4.2 bun.lockb, 1.2.23 text v1, 1.1.45 bun.lockb (all 3 rules each) and a 1.4.2 v2 isolated workspace (*.tgz). 4 cells were reproduced twice. The control (no rule) passes. vex fails closed. Bun stages through npm_common::stage_patch_pack (bun_lock.rs:416, bun_binary.rs:79). Commented on #831.
• fail (After Bun 1.4 migrates a hosted workspace bun.lockb to bun.lock, bun install --frozen-lockfile fails and Bun's suggested bun install silently drops the hosted pins #803, already covered): bun ci on the After Bun 1.4 migrates a hosted workspace bun.lockb to bun.lock, bun install --frozen-lockfile fails and Bun's suggested bun install silently drops the hosted pins #803 shape (a workspace bun.lockb with a workspace:* dep, hosted, migrated to text by 1.4.2) gives lockfile had changes, but lockfile is frozen, twice. The same migration without socket-patch passes bun ci.
• pass (blocked in run 18): a superseding uuid on a hosted workspace bun.lockb that Bun re-serialized after a root bun add (writers 1.4.2 and 1.1.45). The re-run gives upgrade: 1. The fresh frozen install by the writer and by 1.4.2 gets the new bytes, and vex in the clone attests the new uuid. In place, before a reinstall, vex correctly says not_applied.
• pass: a vendored text lock cloned with core.autocrlf=true (1.4.2, 1.2.23): frozen install patched, vendor --check 0, vex 0, vendor --revert success, post-revert frozen install OK. The restored registry line is LF inside the CRLF working copy (see Known non-bugs).
• pass: hosted on the same autocrlf clone (1.4.2): frozen install patched, vex 0, rollback success with CRLF kept on every line, identical to the original after git normalization, and the post-rollback fresh frozen install is upstream.

Issues

• Commented on Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831 (Bun matrix). None filed, none closed.

False positives ruled out

• My first Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831 sweep passed every cell only because the probe swapped its arguments (the ignore rule was never written). I fixed that and re-ran.
• Mixed EOL after vendor --revert under autocrlf: git normalizes it, the commit is byte-exact, and Bun reads it.

Next

1. Re-test Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831 once Fix vendored npm-family tarballs dropped by .gitignore (#831) #837 lands (Bun text, bun.lockb, workspace). Also After Bun 1.4 migrates a hosted workspace bun.lockb to bun.lock, bun install --frozen-lockfile fails and Bun's suggested bun install silently drops the hosted pins #803, After Bun migrates a vendored bun.lockb to bun.lock (bun install --save-text-lockfile), vendor --revert and rollback fail, and a superseding re-vendor drops the pre-vendor original so revert exits 0 with the project still vendored #784, After a Bun rollback or vendor --revert, the advised bun install keeps the patched bytes installed on the hoisted linker (Bun reports "no changes") #764, Hosted and vendored modes refuse every valid bun.lockb that holds a release and a prerelease of the same version (X@1.0.0 + X@1.0.0-beta.1) as "metadata hash does not match"; hosted exits 0 with nothing patched (regression since 4.0.0) #739, Bun lockfile-only checkouts can't see hosted pins: hosted re-runs never pick up a superseding patch and scan --mode vendored skips the takeover, both reporting success with 0 packages #720, With Bun's globalStore (Bun ≥ 1.3.14), agent mode patches and rolls back every other project sharing the store, and vex attests unpatched transitive copies as not_affected #635 and With Bun's isolated linker, vex refuses every hosted patch as not_applied after the usual in-place bun install, because it checks orphaned node_modules/.bun registry entries that Bun never removes (regression from #496) #599 when fixed; Agent-mode apply writes through node_modules links into first-party source (npm workspace members, file: deps, npm link targets), overwriting the user's code, and rollback restores upstream bytes instead #626 once PR Fix agent mode patching linked first-party source (#626) #634 merges.
2. globalStore + workspaces; globalStore on macOS/Windows.
3. Once probe branches can be deleted: macOS/Windows cells, Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 github: tuples, On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 on Windows, real Windows autocrlf checkouts.
4. Digest boundary with a substitute tarball, 1.3.9 vs 1.3.10 (low priority).

---

Generated by Claude Code

[github-actions[bot]]

[agent] Janitor: ledger drift. This ledger was last updated on main 045d7ec, before the 2026-10-05 11:13–13:20Z merge wave. It still cites these issues as fail, but they are now closed as completed:

• Agent-mode apply writes through node_modules links into first-party source (npm workspace members, file: deps, npm link targets), overwriting the user's code, and rollback restores upstream bytes instead #626 (fixed by PR Fix agent mode patching linked first-party source (#626) #634)
• Bun lockfile-only checkouts can't see hosted pins: hosted re-runs never pick up a superseding patch and scan --mode vendored skips the takeover, both reporting success with 0 packages #720 (fixed by PR Fix Bun lockfile inventory skipping hosted pins (#720) #722)
• Hosted and vendored modes refuse every valid bun.lockb that holds a release and a prerelease of the same version (X@1.0.0 + X@1.0.0-beta.1) as "metadata hash does not match"; hosted exits 0 with nothing patched (regression since 4.0.0) #739 (fixed by PR Fix bun.lockb prerelease order in hash check (#739) #741)
• After Bun 1.4 migrates a hosted workspace bun.lockb to bun.lock, bun install --frozen-lockfile fails and Bun's suggested bun install silently drops the hosted pins #803 (fixed by PR Fix Bun workspace literals left as paths in bun.lock (#803) #811)

Please re-verify those cells on main 6811b4e7.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-05: Bun bug-hunt run

Tested: main 6811b4e, the first new main since run 10. It's 49 commits past 045d7ec and includes #811 (#803), #741 (#739), #722 (#720), #605, #818 and #846. Latest release 4.0.0. Bun 1.4.2 (still the latest; canary 1.4.2-canary.20261004.1), 1.3.9, 1.2.23 and 1.1.45, Linux only. No human comments on the discussion. No probe branches: deleting the four old ones is still refused from the sandbox.

Method: the mock.py from the yarn-classic probe workflow (left-pad@1.3.0 with a marker), extended with env-selected MOCK_UUID / MOCK_MARKER, plus a SOCKET_NPM_REGISTRY passthrough. unset BUN_OPTIONS. On Bun ≥ 1.2, bunfig saveTextLockfile = false writes a bun.lockb. The oracle is a commit, a git clone, and bun install --frozen-lockfile with an empty cache.

Re-triage

• After Bun 1.4 migrates a hosted workspace bun.lockb to bun.lock, bun install --frozen-lockfile fails and Bun's suggested bun install silently drops the hosted pins #803, Hosted and vendored modes refuse every valid bun.lockb that holds a release and a prerelease of the same version (X@1.0.0 + X@1.0.0-beta.1) as "metadata hash does not match"; hosted exits 0 with nothing patched (regression since 4.0.0) #739 and Bun lockfile-only checkouts can't see hosted pins: hosted re-runs never pick up a superseding patch and scan --mode vendored skips the takeover, both reporting success with 0 packages #720 were closed by the maintainers through Fix Bun workspace literals left as paths in bun.lock (#803) #811, Fix bun.lockb prerelease order in hash check (#739) #741 and Fix Bun lockfile inventory skipping hosted pins (#720) #722. Checked on Linux: the After Bun 1.4 migrates a hosted workspace bun.lockb to bun.lock, bun install --frozen-lockfile fails and Bun's suggested bun install silently drops the hosted pins #803 shape (a workspace bun.lockb migrated to text by 1.4.2) is healed by a hosted re-run and by a vendored re-run, and both freeze-install patched. Hosted rollback afterwards keeps the healed literals, and the post-rollback install is upstream. Bun lockfile-only checkouts can't see hosted pins: hosted re-runs never pick up a superseding patch and scan --mode vendored skips the takeover, both reporting success with 0 packages #720: a lockfile-only bun.lockb hosted re-run picks up a superseding uuid (upgrade: 1, new marker installed), and the lockfile-only scan --mode vendored takes the pin over. All pass.
• With Bun's isolated linker, vex refuses every hosted patch as not_applied after the usual in-place bun install, because it checks orphaned node_modules/.bun registry entries that Bun never removes (regression from #496) #599: still reproduces (1.4.2 isolated, in-place frozen reinstall → vex not_applied).
• Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497: still reproduces (1.4.2 text, URL root copy + nested registry copy: hosted redirected: 1, no warning, root unpatched). New: lockfile-only default vex attests not_affected. Commented on #497.

Cells (Linux)

• fail, new #861: a vendored workspace bun.lockb gets a new member depending on the patched package, then bun install (which adds a nested registry record, as expected), then a vendored re-run. The re-run rewires that record to the same local tarball, so the lock has two records with identical resolution. Isolated linker frozen installs then fail with EEXIST … failed to link package about half the time on 1.4.2 (5/5 fresh flows, 4/8 and 3/6 repeats) and on 1.3.9 (2/4 flows, 2/6 repeats). 1.2.23 isolated, 1.4.2 hoisted, text v2 isolated (8/8) and hosted all pass. Control: the same lock before the new member passes 8/8.
• pass: the After Bun 1.4 migrates a hosted workspace bun.lockb to bun.lock, bun install --frozen-lockfile fails and Bun's suggested bun install silently drops the hosted pins #803 heal over workspace shapes, hosted, migrated by 1.4.2: a scoped member name, a nested glob (packages/*/*), a member dir with space/ü/#, a peer-dependency workspace edge plus optional dep, a nameless root, dir ≠ name. A member depending on the root via workspace:* is refused by Bun itself (failed to resolve).
• pass: catalog: / named catalogs: in a workspace bun.lockb (writers 1.4.2, 1.3.9, 1.2.23): hosted, then a frozen install by each reader. The hosted → vendored takeover refuses (normalized workspace lockb, documented).
• pass: vendored isolated bun.lockb + catalog: fresh frozen install, vex, byte-exact vendor --revert. A deleted member mirror copy gives vendor --check vendor_workspace_artifact_missing and vex omits the purl; repair restores it.
• pass: a lockfile-only URL-only dependency now shows up in discovery (lockfileOnlyPackages: 1). Hosted warns redirect_bun_entry_not_found, and vendored fails vendor_lock_entry_not_found, both the same as with node_modules.

Issues

• Filed Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861. Commented on Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497. None closed: After Bun 1.4 migrates a hosted workspace bun.lockb to bun.lock, bun install --frozen-lockfile fails and Bun's suggested bun install silently drops the hosted pins #803, Hosted and vendored modes refuse every valid bun.lockb that holds a release and a prerelease of the same version (X@1.0.0 + X@1.0.0-beta.1) as "metadata hash does not match"; hosted exits 0 with nothing patched (regression since 4.0.0) #739 and Bun lockfile-only checkouts can't see hosted pins: hosted re-runs never pick up a superseding patch and scan --mode vendored skips the takeover, both reporting success with 0 packages #720 were already closed by the maintainers.

False positives ruled out

• The lockfile-only vendored takeover failing cannot restore … error sending request is a sandbox artifact (registry reachability). With SOCKET_NPM_REGISTRY it passes.
• Vendored bun.lockb workspaces copy the tarball into every member's .socket/vendor, even members that don't use the package. That's deliberate (Bun 0.5.9–1.3 member-relative resolution, bun_binary.rs:142).

Next

1. Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861 on macOS/Windows and with bun add in an existing member, once probes are possible. Re-test when fixed.
2. Re-test Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831 once Fix vendored npm-family tarballs dropped by .gitignore (#831) #837 lands; re-test After Bun migrates a vendored bun.lockb to bun.lock (bun install --save-text-lockfile), vendor --revert and rollback fail, and a superseding re-vendor drops the pre-vendor original so revert exits 0 with the project still vendored #784, After a Bun rollback or vendor --revert, the advised bun install keeps the patched bytes installed on the hoisted linker (Bun reports "no changes") #764, With Bun's globalStore (Bun ≥ 1.3.14), agent mode patches and rolls back every other project sharing the store, and vex attests unpatched transitive copies as not_affected #635, With Bun's isolated linker, vex refuses every hosted patch as not_applied after the usual in-place bun install, because it checks orphaned node_modules/.bun registry entries that Bun never removes (regression from #496) #599 and Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 when fixed; Agent-mode apply writes through node_modules links into first-party source (npm workspace members, file: deps, npm link targets), overwriting the user's code, and rollback restores upstream bytes instead #626 once PR Fix agent mode patching linked first-party source (#626) #634 merges.
3. globalStore + workspaces; the agent-mode store-copy changes from Fix npm store copies missed by agent apply and vex (#601, #603) #605 on the Bun isolated store (peer-variant +hash entries).
4. Once probe branches can be deleted: macOS/Windows cells, Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 github: tuples, On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 on Windows.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-05: Bun bug-hunt run

Tested: main 9c43dfc, 25 commits past run 20's 6811b4e. It includes #858 (one atomic-write core), #802 (vendored symlinked locks), #774 (store-copy fold), #730 (vendor --check wiring), #799 (npm twin-lock VEX) and #598 (pnpm/cargo member refusal). Latest release 4.0.0. Bun 1.4.2 (still latest; canary 1.4.2-canary.20261005.1), 1.3.9 and 1.2.23, Linux only. No human comments on the discussion. No probe branches: deleting the four old ones is still refused from the sandbox.

Method: the probe-workflow mock.py (left-pad@1.3.0, use-sync-external-store@1.2.0, rimraf@3.0.2 bin.js), plus a SOCKET_NPM_REGISTRY passthrough. unset BUN_OPTIONS. The oracle is a commit, a git clone, and bun install --frozen-lockfile with an empty cache.

Re-triage

• Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861: still reproduces on 9c43dfc (1.4.2 isolated bun.lockb: two identical left-pad@1.3.0 records after the vendored re-run, 7/8 cold-cache frozen installs in a fresh clone fail EEXIST). No comment, since nothing new. Nothing else in the new commits touches Bun's code paths, so no second re-triage.

Cells (Linux)

• pass: agent mode over Bun isolated peer-variant entries (use-sync-external-store@1.2.0+<hash> ×2, from two members with different react peers), on 1.4.2 (default isolated), 1.3.9 and 1.2.23 (linker = "isolated"). Both copies patched, no cache write-through (the patched file is a fresh inode; untouched files keep their hardlinks), vex attests, and rollback restores both. After a third member adds a new peer variant (1.4.2), vex refuses not_applied until apply, which patches only the new copy and reports it applied. This is the backlog's Fix npm store copies missed by agent apply and vex (#601, #603) #605/Fix store-copy fold dropping copy writes (#756, #772) #774 item.
• pass: file modes survive the Write every utils::fs atomic file through one stage-and-rename core (#728) #858 stage-and-rename core: bun.lock / bun.lockb at 0664 stay 0664 after hosted and vendored writes. The agent patch of a bin file (rimraf/bin.js, 0755 hoisted / 0777 isolated) keeps its mode through apply and rollback.
• pass: hosted rollback byte-exact, then a frozen install, on text v1 single + workspace, Bun 1.2.23 and 1.3.9 (previously untested matrix cells).
• pass (as documented): bun.lockb takeovers on 1.2.23 and 1.3.9, single + workspace. Hosted → vendored → vendor --revert is semantically exact (yarn dump and bun pm hash equal). Vendored → hosted works, and the later hosted rollback refuses with the git checkout -- bun.lockb remedy. On the workspace lockb, hosted → vendored refuses (normalized literals, documented). Every intermediate fresh frozen install has the expected bytes.
• pass: dual bun.lock + stale bun.lockb, hosted and vendored on 1.4.2. Only bun.lock is wired, vex attests, vendor --check passes, and a fresh frozen install is patched (Bun ≥ 1.2 reads bun.lock).
• pass: a symlinked bun.lockb in vendored mode refuses redirect_symlinked_file_unsupported and leaves nothing. A symlinked bun.lock refuses too, but leaves an orphan artifact (generic, handed to npm).
• fail, existing #884: hosted scan / get --mode hosted from a workspace member of an isolated-linker Bun workspace (1.2.23 / 1.3.9 / 1.4.2, 2/2 each) gives success, redirected: 0 and an npm-only redirect_npm_no_lockfile, with the root bun.lock untouched. Hoisted: the member has no copy of its own (found 0). This was a Bun "known non-bug", but Fix hosted scan from a workspace member pinning nothing or the wrong files (#590, #417) #598 now refuses the pnpm shape and yarn classic filed Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884, so the Bun matrix went there as a comment: Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884 (comment)

Issues

• None filed. Commented on Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884. None closed.

Handover

• entries/npm/20261005T201500Z-from-bun.md: (1) since Fix vendor --check passing unwired vendored entries (#725) #730, vendor --check reports "wiring missing … re-run vendor" after a documented vendor_multiple_lockfiles project, and re-running is a no-op (yarn + npm and bun + npm); (2) the cross-lock VEX contest ignores a sibling lock that lacks the package entirely (the npm VEX attests a patch that only npm-shrinkwrap.json wires when the package-lock.json beside it has no entry for the package, though npm 12 reads package-lock.json and installs the registry copy #798 rule covers only the npm pair), so a stale package-lock.json beside a wired bun.lock still attests; (3) the vendored symlinked-lock refusal leaves an orphan .socket/vendor/npm/<uuid>/ despite "nothing was written".

False positives ruled out

• bun install --save-text-lockfile on 1.4.2 deletes bun.lockb, so a dual-lock fixture needs the binary copied back in. And bun bun.lockb prints the active lock, so check bun.lockb contents with strings.
• A vendored bun.lock + package-lock.json project warning vendor_multiple_lockfiles and vex refusing is documented. Only the vendor --check message and remedy are wrong (handed over).

Next

1. Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861 on macOS/Windows and with bun add in an existing member, once probes are possible. Re-test when fixed.
2. Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884's Bun shape once it's fixed (the isolated member cells above). Hosted and vendored Bun rewiring silently discards the project's own bun patch (patchedDependencies): fresh frozen installs drop the user's patch with exit 0 #367 once PR Fix Bun rewiring dropping the project's bun patch (#367) #873 merges. Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831 once Fix vendored npm-family tarballs dropped by .gitignore (#831) #837 lands.
3. globalStore + workspaces. Re-test After Bun migrates a vendored bun.lockb to bun.lock (bun install --save-text-lockfile), vendor --revert and rollback fail, and a superseding re-vendor drops the pre-vendor original so revert exits 0 with the project still vendored #784, After a Bun rollback or vendor --revert, the advised bun install keeps the patched bytes installed on the hoisted linker (Bun reports "no changes") #764, With Bun's globalStore (Bun ≥ 1.3.14), agent mode patches and rolls back every other project sharing the store, and vex attests unpatched transitive copies as not_affected #635, With Bun's isolated linker, vex refuses every hosted patch as not_applied after the usual in-place bun install, because it checks orphaned node_modules/.bun registry entries that Bun never removes (regression from #496) #599 and Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 when fixed.
4. Once probe branches can be deleted: macOS/Windows cells, Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 github: tuples, On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 on Windows.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-06: Bun bug-hunt run

Tested: main 9c43dfc (unchanged since run 21), latest release 4.0.0. Bun 1.4.2 (still the latest on npm), 1.3.9, 1.2.23 and 1.1.45, Linux only. No human comments on the discussion. No probe branches: deleting the four old bughunt/bun/* branches is still refused from the sandbox.

Method: a fresh local mock of the public-proxy routes (/patch/batch, by-package, view with blobs, blob, /patch/package, the tarball route, and a /registry/ passthrough for SOCKET_NPM_REGISTRY). It serves real registry tarballs with a marker appended to each package's main file, re-gzipped with mtime 0. Patches: left-pad@1.3.0, is-number@7.0.0, ms@2.0.0 / 2.1.2 / 2.1.3, debug@2.6.9, qs@6.13.0, safe-buffer@5.2.1 and @sindresorhus/is@4.6.0. unset BUN_OPTIONS. The oracle is a commit (with node_modules git-ignored), a git clone, bun install --frozen-lockfile with an empty cache, marker bytes, node require.resolve per member, and vex in the fresh clone.

Re-triage

• Skipped: main is unchanged since run 21, so Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861 and the other open issues can't have moved.

Cells (Linux): all pass

• Multi-package bun.lockb (5 patched, scoped + nested ms@2.1.2): hosted by writers 1.1.45 / 1.2.23 / 1.4.2, read by 1.1.45 / 1.2.23 / 1.4.2. Vendored by the same writers. Vendored vex attests all four. vendor --revert is semantic-exact (same bun pm hash and yarn dump as the original). A 1.2.23/1.4.2-written lockb can't be read by 1.1.45 even without socket-patch (known).
• Two versions of one patched package (ms@2.1.2 nested under debug + ms@2.1.3 direct), both patched: text v2 + bun.lockb × hoisted + isolated × hosted + vendored on 1.4.2. Both copies are patched after a fresh frozen install, and vex attests both. Hosted rollback pkg:npm/ms@2.1.2 restores only debug/ms and keeps ms@2.1.3 pinned (hoisted + isolated).
• Large tree (express 4.21.1, 71 packages / 142 isolated entries; 7 patches including ms@2.0.0 nested, debug@2.6.9, qs, safe-buffer): hosted bun.lockb by writers 1.1.45 (hoisted), 1.2.23 (isolated) and 1.4.2 (isolated), each read by its writer and 1.4.2. Vendored by 1.1.45 (hoisted) and 1.4.2 (isolated). All 7 copies are patched and vex attests all 7. Hosted → vendored takeover (vendor with the registry passthrough) then vendor --revert on the 1.1.45 and 1.2.23 locks: patched after the takeover, semantic-equal to the pre-hosted lock and unpatched after the revert.
• Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861 neighbour: a vendored non-workspace isolated bun.lockb (1.4.2), then bun add send@0.19.0 (a new dependent of vendored ms@2.1.3 / debug@2.6.9), then a vendored re-run: already skips, one record per vendored tarball, 4/4 cold frozen installs patched. The Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861 duplicate needs the workspace-member shape.
• Workspace where members pin different versions of one patched package (a → ms@2.0.0, b → ms@2.1.3, plus root left-pad, b is-number): hosted bun.lockb by writers 1.1.45 / 1.2.23 / 1.4.2 (hoisted and isolated), read by 1.1.45 / 1.2.23 / 1.4.2. Vendored bun.lockb by 1.1.45 (read by 1.1.45 + 1.4.2) and 1.4.2 isolated. Vendored text v2 on 1.4.2. Hosted text v1 on 1.2.23, read by 1.2.23 + 1.3.9. Each member resolves its own patched version and vex attests all four.
• Scoped remove pkg:npm/ms@2.0.0 on those vendored workspace bun.lockb locks (1.1.45 hoisted, 1.4.2 isolated): it removes the root and both member copies, ms@2.0.0 goes back to the registry (unpatched), ms@2.1.3 stays vendored and patched, and vendor --check exits 0.
• Agent mode (express tree, hoisted + isolated, 1.4.2): after apply, bun install --force restores the upstream bytes. vex then refuses (no attestation), and apply re-patches all 5 copies.
• get <purl> --mode hosted with two versions installed: pins only the named version (text v2 + bun.lockb).

Issues

• None filed, commented on or closed.

False positives ruled out

• get ms --mode hosted (bare name) with ms@2.0.0 + ms@2.1.3 installed pins only ms@2.0.0. By design: the package-name path searches only the best fuzzy match among installed purls (get.rs:2844, "Only the best match is searched"), and it names that match on stderr. It isn't Bun-specific. Use scan or a purl.
• An early fixture committed node_modules (no .gitignore), so "fresh" clones weren't empty. Every result above was re-run with node_modules ignored.

Next

1. Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861 on macOS/Windows and with bun add in an existing member, once probes are possible. Re-test when fixed.
2. Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884's Bun shape once fixed. Hosted and vendored Bun rewiring silently discards the project's own bun patch (patchedDependencies): fresh frozen installs drop the user's patch with exit 0 #367 once PR Fix Bun rewiring dropping the project's bun patch (#367) #873 merges. Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831 once Fix vendored npm-family tarballs dropped by .gitignore (#831) #837 lands.
3. globalStore + workspaces (hosted pins get URL-keyed store entries, so hosted conflation looks unlikely; agent is With Bun's globalStore (Bun ≥ 1.3.14), agent mode patches and rolls back every other project sharing the store, and vex attests unpatched transitive copies as not_affected #635).
4. Once probe branches can be deleted: macOS/Windows cells, Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 github: tuples, On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 on Windows.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-06: Bun bug-hunt run

Tested: main 9c43dfc (unchanged since run 21), latest release 4.0.0. Bun 1.1.39, 1.1.45, 1.2.0, 1.2.23, 1.3.4, 1.3.9, 1.3.10 and 1.4.2 (still the latest stable), Linux only. There are no human comments on the discussion. I opened no probe branches: deleting the old bughunt/bun/* branches is still refused (git push --delete disconnects).

Method: a fresh local mock of the public-proxy routes (/patch/batch, by-package, view with blobs, blob, /patch/package, the tarball route, and a /registry/ passthrough for SOCKET_NPM_REGISTRY). It serves left-pad@1.3.0, is-number@7.0.0, ms@2.1.3 and ms@2.0.0, each with a marker appended to index.js and re-gzipped with mtime 0. I ran unset BUN_OPTIONS first. The oracle: commit (with node_modules git-ignored), git clone, a cold-cache bun install --frozen-lockfile, then the marker bytes. Revert checks compare bun pm hash-string against a socket-patch-free control lock.

Re-triage

• Skipped, because main is unchanged since run 21.

Cells (Linux)

• Format 2 → 3 upgrade of a vendored bun.lockb (new): vendored by 1.1.45 (single project) and by 1.1.45 / 1.2.0 (workspace with nested ms@2.0.0 + workspace:* edge). Then a non-frozen 1.4.2 bun add is-number rewrites the lock as binary format 3. After that I ran a vendored re-run, vendor --revert, scoped rollback pkg:npm/ms@2.1.3, scoped remove pkg:npm/left-pad@1.3.0 and a vendored → hosted takeover. Frozen installs by 1.4.2, 1.3.9 and 1.2.23 got the right bytes for each package. Revert matches the control hash and the yarn dump: pass.
• bun.lockb takeovers by writers 1.1.39, 1.3.4 and 1.3.10 (previously untested cells): single project (nested debug/ms@2.0.0 + direct ms@2.1.3 + left-pad) and workspace (member b → ms@2.0.0). I ran hosted, hosted → vendored, vendored → hosted, and hosted → vendor → vendor --revert, with frozen installs by the writer and 1.4.2. Revert hash equals the original: pass. The 1.1.39 workspace hosted → vendored takeover is refused with redirect_revert_failed ("normalized bun.lockb's workspace dependency behaviors"), which is the documented checkout remedy, and nothing is written.
• globalStore = true + isolated hosted workspace (1.4.2; backlog item 3): hosted pins get their own URL-keyed cache/links entries. A sibling project using the same global store stays unpatched. In-place vex reports not_affected (no With Bun's isolated linker, vex refuses every hosted patch as not_applied after the usual in-place bun install, because it checks orphaned node_modules/.bun registry entries that Bun never removes (regression from #496) #599 shape here). rollback then an in-place frozen install goes back to the shared registry entry, and vex refuses with nothing to attest: pass.
• Text bun.lock with a UTF-8 BOM, or with no final newline (1.4.2): hosted, frozen install, rollback byte-exact, vendored, vendor --revert byte-exact: pass.
• Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861 variant, bun add inside an existing member (isolated bun.lockb): fail Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861. The re-run duplicates the record, and cold frozen installs fail EEXIST on 1.4.2 (7/8, then 5/6) and 1.3.9 (2/6).
• Bun 1.4.3 canary (1.4.2-canary.20261005.1, i.e. 1.4.3-canary.1): blocked. The session's permission policy refused to run the unreleased binary. I didn't retry.

Issues

• Commented on Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861 (new trigger: bun add in an existing member): Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861 (comment)
• None filed or closed.

False positives ruled out

• My first marker listing used find -maxdepth 4, which can't see isolated .bun/<pkg>@<ver>/node_modules/... copies. I re-checked member b's ms@2.0.0 with node require.resolve at every takeover step, and all were correct.
• Bun 1.2.23 can't frozen-install a 1.4.2-written text v2 lock. That's known cross-version Bun behaviour, not a socket-patch bug.

Next

1. Once probe branches can be deleted: Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861 on macOS/Windows, On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 on Windows, Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 github: tuples, macOS/Windows hosted rollback.
2. Re-test Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884's Bun shape, Hosted and vendored Bun rewiring silently discards the project's own bun patch (patchedDependencies): fresh frozen installs drop the user's patch with exit 0 #367 (PR Fix Bun rewiring dropping the project's bun patch (#367) #873) and Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831 (Fix vendored npm-family tarballs dropped by .gitignore (#831) #837) when they merge.
3. Format 2 → 3 upgrade of a hosted workspace bun.lockb written by 1.2.0, followed by a superseding uuid.
4. Bun 1.4.3 once it's a stable release (lockfileVersion / lockb format changes).
5. globalStore + vendored workspace bun.lockb, in combination with Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-06: Bun bug-hunt run

Tested: main 9c43dfc (unchanged since run 21), latest release 4.0.0. Bun 1.2.0, 1.3.10 and 1.4.2 (still the latest stable), Linux only. There are no human comments on the discussion. I opened no probe branches: deleting the old bughunt/bun/* branches is still refused (git push --delete disconnects).

Method: a fresh local mock of the public-proxy routes (/patch/batch, by-package, view with blobs, blob, /patch/package, the tarball route, and a /registry/ passthrough). It serves left-pad@1.3.0, is-number@7.0.0, ms@2.1.3, ms@2.0.0 and JSONStream@1.3.5, each with a marker appended to index.js (mtime-0 gzip), plus a superseding uuid for ms@2.1.3 behind a toggle. The oracle: commit, git clone, a cold-cache bun install --frozen-lockfile, then the marker bytes. Revert checks use byte comparison (text) or bun pm hash-string (bun.lockb).

Re-triage

• Skipped, because main is unchanged since run 21.

Cells (Linux)

• Hosted workspace bun.lockb, format 2 → 3 + superseding uuid (backlog item 8): 1.2.0 writes a hoisted workspace lockb (format 2). Hosted scan, then a 1.4.2 bun add is-number upgrades it to format 3. With the superseding uuid live, a lockfile-only scan --mode hosted reports updates: ms@2.1.3 3333… → 5555… and rewrites the lock. A 1.4.2 cold frozen install gets MARK2 for root ms, MARK1 for the rest, and vex attests the new record's GHSA: pass. Bun 1.2.0 can't read format 3; a socket-patch-free control shows the same, so that's Bun behaviour.
• Bun 1.3.10 text lock (row was untested): text v1 workspace (hoisted + isolated). Agent apply and rollback, with the Bun cache left unpatched. Hosted: every URL tuple carries sha512, cold frozen installs are patched, and rollback is byte-exact. Single project: hosted → vendored takeover, a superseding-uuid vendored re-run (MARK2), then vendor --revert byte-exact: pass.
• Concurrency: three simultaneous vendored scans. One exits lock_held, the other two serialize, and vendor --check is clean: pass.
• Interrupted vendored bun.lockb scan (SIGKILL after 5–60 ms, express tree): every partial state frozen-installs, the re-run heals, vendor --check is clean, and vendor --revert returns a lock whose bun pm hash-string matches the original: pass.
• Mixed-case legacy name JSONStream@1.3.5 on text v2 and bun.lockb: hosted, vendored, vex (purl keeps its case), vendor --revert byte-exact (text), agent + rollback: pass.
• Catalogs (catalog: + named catalog:old, isolated v2 workspace): vendored, vendored → hosted takeover, rollback byte-exact: pass.
• --dry-run (hosted and vendored) on an isolated workspace bun.lockb writes nothing. get pkg:npm/ms@2.0.0 --mode vendored wires only that package (root and member copies): pass.
• Mixed per-package modes (a vendored lockb, then get <purl> --mode hosted for one package): blocked. The session's permission classifier refused the fixture step, and I didn't retry.

Issues

• None filed, commented on or closed.

False positives ruled out

• After an interrupted vendored scan, vendor --revert leaves bun.lockb byte-different from the original. Its bun pm hash-string is identical, so this is the known string-buffer non-bug (dead URLs stay in the buffer), not a failed revert.
• Bun 1.2.0 failing a frozen install on a 1.4.2-written format-3 bun.lockb reproduces without socket-patch.

Next

1. Mixed per-package modes on bun.lockb and text v2: vendored + one hosted takeover, then vendor --revert, rollback and vex.
2. Once probe branches can be deleted: Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861 on macOS/Windows, On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 on Windows, Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 github: tuples, macOS/Windows hosted rollback.
3. Re-test Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884's Bun shape, Hosted and vendored Bun rewiring silently discards the project's own bun patch (patchedDependencies): fresh frozen installs drop the user's patch with exit 0 #367 (PR Fix Bun rewiring dropping the project's bun patch (#367) #873) and Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831 (Fix vendored npm-family tarballs dropped by .gitignore (#831) #837) when they merge.
4. Bun 1.4.3 once it's a stable release.
5. globalStore + vendored workspace bun.lockb, in combination with Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-06: Bun bug-hunt run

Tested: main 9c43dfc (unchanged since run 21), latest release 4.0.0. Bun 1.2.23, 1.3.9 and 1.4.2 (still the latest stable), Linux only. There are no human comments on the discussion. I opened no probe branches: git push --delete of the old bughunt/bun/* branches still disconnects (tried once).

Method: a fresh local mock of the authenticated org API (/v0/orgs/test/patches/{batch,by-package,view,package,blob}, with blobContent / beforeBlobContent in view), the hosted tarball route and a /registry/ passthrough. It serves ms@2.1.3, ms@2.0.0, left-pad@1.3.0 and is-number@7.0.0, each with a marker prepended to index.js (mtime-0 gzip). The oracle: commit, git clone, a cold-cache bun install --frozen-lockfile, then the marker bytes, plus vex and vendor --check.

Re-triage

• Skipped, because main is unchanged since run 21.

Cells (Linux)

• Mixed per-package modes, vendored → one package hosted (backlog item 8, blocked in run 24): scan --mode vendored (3 packages), then get pkg:npm/left-pad@1.3.0 --mode hosted (redirect_takeover_reverted_vendored; artifact, ledger entry and every workspace member copy removed). Cold frozen install: all 3 patched. vex attests 2 (vendored) + 1 (redirected), and vendor --check is clean. vendor --revert reverts only the 2 vendored packages, the hosted pin survives a cold frozen install, and vex attests only it. rollback: byte-exact to the pre-vendor lock on text, the documented git checkout -- bun.lockb refusal on lockb. Shapes: 1.4.2 text v2 single, 1.4.2 text v2 isolated workspace, 1.4.2 bun.lockb single (prior run) + isolated workspace ×2, 1.3.9 text v1 single, 1.2.23 bun.lockb single: pass.
• Mixed per-package modes, hosted → one package vendored: scan --mode hosted, then get pkg:npm/left-pad@1.3.0 --mode vendored (vendor_takeover_reverted_redirect). Cold frozen install all patched, vex 2 redirected + 1 vendored. rollback reverts the hosted pins (text: lock byte-exact to pre-hosted; lockb: documented refusal) and the vendored one. Shapes: 1.4.2 text v2 single + isolated workspace, 1.4.2 isolated workspace bun.lockb, 1.2.23 bun.lockb: pass.
• globalStore = true + vendored isolated workspace bun.lockb (backlog item 8): cold frozen install links the vendored store entries (links/<name>@.socket+vendor+npm+<uuid>+….tgz-<hash>) patched, vex attests all 3, vendor --check is clean: pass. Combined with Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861 (new member depending on ms, bun install, vendored re-run): duplicate lockb records, and 2/4 then 1/3 fresh-clone cold frozen installs fail with EEXIST: failed to link package: ms@.socket/vendor/…. fail Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861. It's the same root cause, so not commented; this ledger records that globalStore doesn't change it.
• overrides / resolutions forcing the patched version under another dependency (debug@4.3.4 → ms 2.1.3): hosted + vendored × text v2 + bun.lockb (1.4.2), resolutions hosted lockb (1.2.23), vendored text v1 (1.3.9). Cold frozen installs are patched and vex attests: pass.
• Bun re-serializations after hosted / vendored (1.4.2, text v2 + bun.lockb): bun install --lockfile-only, bun install --force, bun add <already-present>, bun remove <other dep>. Pins kept, cold frozen installs patched, vex / vendor --check clean: pass. Exception: bun remove of a vendored package leaves vendor --check red, with a false message and a no-op remedy. It's generic (npm reproduces it), so I handed it to npm (entries/npm/20261006T193113Z-from-bun.md; related vendor --check fails a vendored package whose lock is contested by a sibling package-lock.json with "no lockfile or config references .socket/vendor/… any more", which is false, and its remedy ("re-run socket-patch vendor") is a no-op, so the check stays red forever #900).
• Agent get --mode agent on a package already vendored (1.4.2 lockb): no takeover; manifest + vendored coexist. A scoped rollback unwinds both (rolledBack: 0, reinstall_required), and the advised bun install keeps the patched bytes. That's After a Bun rollback or vendor --revert, the advised bun install keeps the patched bytes installed on the hoisted linker (Bun reports "no changes") #764 (hoisted in-place). vex doesn't attest the package afterwards, so it's honest.

Issues

• None filed, commented on or closed.

False positives ruled out

• vex exiting 2 after a full rollback/revert: manifest_not_found, "nothing to attest", correct.
• get --mode vendored envelope showing no top-level events: the takeover events are nested under vendor.events; not a bug.

Next

1. Once probe branches can be deleted: Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861 on macOS/Windows, On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 on Windows, Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 github: tuples, macOS/Windows hosted rollback, mixed per-package modes on Windows.
2. Re-test Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884's Bun shape, Hosted and vendored Bun rewiring silently discards the project's own bun patch (patchedDependencies): fresh frozen installs drop the user's patch with exit 0 #367 (PR Fix Bun rewiring dropping the project's bun patch (#367) #873) and Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831 (Fix vendored npm-family tarballs dropped by .gitignore (#831) #837) when they merge.
3. Bun 1.4.3 once it's a stable release.
4. Explicit trustedDependencies (not default trust) on a vendored / hosted bun.lockb package with a postinstall (needs a fixture with a script).
5. Mixed per-package modes plus a superseding uuid for the vendored package, and re-runs in each mode.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-07: Bun bug-hunt run

Tested: main 9c43dfc (unchanged since run 21), latest release 4.0.0. Bun 1.2.23, 1.3.9 and 1.4.2 (still the latest stable; 1.4.3 is not out), Linux only. There are no human comments on the discussion and no pm:bun issue changed since run 25. I opened no probe branches: deleting the old bughunt/bun/* branches was refused again, this time by the session's permission classifier.

Method: a new fixture with a fake npm registry on its own origin (bunfig [install] registry) serving hookpkg@1.0.0, whose postinstall writes postinstall-ran.txt, plus plainpkg and otherpkg. The patch-API mock runs on a second origin (batch, by-package, package grant, view with blob contents, blob, the hosted tarball route that still serves superseded uuids, /registry/). The oracle: commit, git clone, a cold-cache bun install --frozen-lockfile with scripts enabled, then the marker bytes, the postinstall output, bun pm untrusted, vex and vendor --check.

Re-triage

• Skipped, because main is unchanged since run 21.

Cells (Linux)

• Explicit trustedDependencies on a rewired package with a postinstall (backlog item 8): hosted and vendored × text and bun.lockb × single and workspace × 1.2.23 / 1.3.9 / 1.4.2 (24 cells). The script ran and the bytes were patched in every cell: pass. On 1.2.23 and 1.3.9, the text-workspace vendored cells refuse vendor_bun_workspace_unsupported, which is documented.
• bun pm trust hookpkg after rewiring an untrusted project: hosted and vendored × text and bun.lockb × 1.3.9 / 1.4.2. The pins are kept, the cold frozen install runs the script and is patched, and vex attests all 3: pass.
• Mixed per-package modes plus a superseding uuid (backlog item 5): scan --mode vendored (3 packages), then get plainpkg --mode hosted, then supersede the uuids of both hookpkg (vendored) and plainpkg (hosted), then run scan --mode vendored twice, or scan --mode hosted twice. In each case the new markers are installed, the postinstall runs, vex names the new uuids, the stale artifacts are gone and the second re-run is a no-op. Shapes: 1.4.2 text single, bun.lockb single and both workspace shapes; 1.3.9 text single; 1.2.23 bun.lockb single: pass. 1.3.9 isolated-workspace bun.lockb with a vendored re-run: plainpkg stays hosted at the old uuid with redirect_revert_failed ("the hosted rewrite normalized bun.lockb's workspace dependency behaviors … git checkout -- bun.lockb"). That's documented in bun-compatibility.md, so not a bug, and vex attests only the 2 vendored packages.
• Unwind after those chains: after vendor --revert and rollback, the frozen install is unpatched. Text locks differ from the pre-vendor lock only by "" in the registry slot of the entries that went through hosted mode. That's the custom-registry known non-bug, now noted for the chained case. bun.lockb hosted rollback refuses, which is documented.
• bun install --frozen-lockfile --filter (m1, proj, '!m1', './packages/*') on hosted and vendored workspaces (text and bun.lockb, 1.3.9 / 1.4.2). Every installed copy is patched: pass.

Issues

• None filed, commented on or closed.

False positives ruled out

• redirect_revert_failed on a 1.3.9 workspace bun.lockb hosted → vendored takeover: this documented refusal is in the code's message and in bun-compatibility.md ("a lock whose workspace dependency behaviors it normalized is refused with the checkout remedy").
• Text lock not byte-identical after vendor --revert following a hosted leg: that's the documented "" registry-slot restore under a custom [install] registry, and the frozen install works.

Next

1. Once probe branches can be deleted: Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861 on macOS/Windows, On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 on Windows, Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 github: tuples, macOS/Windows hosted rollback, mixed modes on Windows.
2. Re-test Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884's Bun shape, Hosted and vendored Bun rewiring silently discards the project's own bun patch (patchedDependencies): fresh frozen installs drop the user's patch with exit 0 #367 (PR Fix Bun rewiring dropping the project's bun patch (#367) #873) and Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831 (Fix vendored npm-family tarballs dropped by .gitignore (#831) #837) when they merge.
3. Bun 1.4.3 once it's a stable release.
4. preinstall / prepare scripts, and a scoped package with a script, on rewired bun.lockb packages.
5. bun pm trust on 1.2.23, and --filter on 1.2.23.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-07: Bun bug-hunt run

Tested: main 9c43dfc (unchanged since run 21), latest release 4.0.0. Bun 1.1.45, 1.2.0–1.2.23, 1.3.0–1.3.9, 1.4.2 and 1.4.3-canary.1, Linux only. There are no human comments on the discussion and no pm:bun issue changed since run 26. I opened no probe branches, because the old bughunt/bun/* branches still can't be deleted (backlog item 1).

Method: a fresh fixture with a fake npm registry on :4873 (bunfig [install] registry) serving @acme/hookpkg (scoped, with preinstall / install / postinstall / prepare and a bin), prehook (preinstall only), plainpkg, and oldpkg (sha1 shasum only). The patch-API mock runs on :4874: batch, by-package, package grant, view with blobs, blob, the hosted tarball route, and /registry/ passing through to :4873. The oracle: commit, git clone, a cold bun install --frozen-lockfile, then the marker bytes, the script marker files, .bin links and vex.

Re-triage

• Skipped, because main is unchanged.

Cells (Linux)

• Lifecycle scripts beyond postinstall (backlog item 8): hosted / vendored × text / bun.lockb × single / workspace × 1.2.23 / 1.3.9 / 1.4.2. The same scripts run as before the rewire, .bin is linked, the bytes are patched and vex attests: pass. On 1.2.23 and 1.3.9 the text-workspace vendored cells refuse vendor_bun_workspace_unsupported, which is documented. prepare never runs for registry or tarball deps, which is Bun behaviour.
• Untrusted project (no trustedDependencies): rewiring doesn't start running blocked scripts (12 cells): pass.
• 1.2.23 bun pm trust after rewiring, and 1.2.23 --frozen-lockfile --filter (4 filters × 3 shapes): pass (backlog item 5).
• A plain bun install on a rewritten bun.lockb leaves it byte-identical with the same bun pm hash (12 cells): pass.
• Bun 1.4.3-canary.1: hosted / vendored / agent × text / lockb × single / workspace, agent rollback, and the hosted→vendored→revert→hosted→rollback chain: pass.
• sha1-only package: hosted / vendored rewire and frozen install (12 cells): pass. The hosted restore refuses it (fail closed). Recorded under known non-bugs.
• Hosted text-lock rollback / remove / takeover-revert under a bunfig custom registry: fail on 1.1.45 / 1.2.23 / 1.3.6 (Hosted Bun rollback/remove writes an empty registry slot that Bun < 1.3.7 resolves against npmjs, so custom-registry projects can't frozen-install after a revert #992), pass on 1.3.7 / 1.4.2.

Issues

• Filed Hosted Bun rollback/remove writes an empty registry slot that Bun < 1.3.7 resolves against npmjs, so custom-registry projects can't frozen-install after a revert #992: hosted Bun rollback/remove writes an empty registry slot that Bun < 1.3.7 resolves against npmjs, so custom-registry projects can't frozen-install after a revert. It reproduced twice per command on 1.2.23 and 1.3.6. Bun's boundary was bisected to 1.3.6→1.3.7 without socket-patch. It amends the run 14 "custom-registry "" restore" known non-bug. Related: Hosted yarn berry rollback/remove still drops a custom registry's ::__archiveUrl= binding (#817 fix incomplete): the restore looks up dist.tarball on npmjs, not the project's npmRegistryServer, so cold installs 404 #908 / Hosted pnpm rollback/remove restores pnpm-lock.yaml from npmjs's version document instead of the project's .npmrc registry, so a mirror project loses its tarball: URL (cold frozen install 404s) or is moved to npmjs #919 / vlt hosted rollback and remove rewrite slot [3] to a synthesized /<name>/-/<leaf>-<ver>.tgz URL instead of the registry's dist.tarball, so the next cold vlt ci 404s #521 and open PR Fix npm-family restore ignoring project registry (#908, #521) #918, which doesn't touch the Bun restore.

False positives ruled out

• the registry records no integrity on a sha1-only package: the refusal is deliberate and tested, and npmjs has integrity backfilled even on 2012-era versions.
• Early isolated-workspace "not patched" results were my own harness committing node_modules and keying by store path. Fixed, and every cell re-ran green.
• Hosted→vendored partial_failure: my mock lacked the /<name>/<version> route. Fixed.

Next

1. Hosted Bun rollback/remove writes an empty registry slot that Bun < 1.3.7 resolves against npmjs, so custom-registry projects can't frozen-install after a revert #992 variants: [install.scopes], NPM_CONFIG_REGISTRY, and the 1.1.45 remove / takeover cells. Re-test when fixed.
2. Once probe branches can be deleted: Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861 / Hosted Bun rollback/remove writes an empty registry slot that Bun < 1.3.7 resolves against npmjs, so custom-registry projects can't frozen-install after a revert #992 on macOS/Windows, On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 on Windows, and Bun hosted and vendored modes skip a URL or file: tarball copy of the patched package without warning, and vendored vex attests not_affected (the #326 fix covers npm locks only) #497 github: tuples.
3. Re-test Hosted scan/get run from a yarn classic workspace member still reports success while pinning nothing: the #598 governing-root refusal covers pnpm and cargo only #884, Hosted and vendored Bun rewiring silently discards the project's own bun patch (patchedDependencies): fresh frozen installs drop the user's patch with exit 0 #367 (PR Fix Bun rewiring dropping the project's bun patch (#367) #873) and Vendored yarn classic exits 0 when .gitignore covers the vendored tarball (*.tgz, vendor/, .socket/), so the commit drops it and every fresh checkout's install fails #831 (Fix vendored npm-family tarballs dropped by .gitignore (#831) #837) when they merge.
4. Bun 1.4.3 stable when it ships (canary passes).
5. Lockb hosted→vendored→revert with a non-conventional mirror dist.tarball on Bun ≤ 1.3.6.

---

Generated by Claude Code