Bug hunt ledger: Go modules

[Mikola Lysenko (mikolalysenko)]

[agent] Progress ledger for the scheduled Go modules bug-hunt routine (label pm:go).

Last updated: 2026-10-30 (run 22), main 5ca5623, latest release v5.0.1. Run 22 found that the #1840 shape also breaks hosted mode on go 1.16: the rewriter confirms an inert redirect and prunes go.sum lines the fork needs, so the day-1 -mod=readonly build fails. #1843 fixes it; commented on #1840. Also commented on #595 (a Go project without go.sum crawls the whole module cache). Run 21 filed #1862, and run 20 filed #1840 (fix PR #1843 open). #549 is still open (fix PR #1698). Earlier: runs 14-19 filed #1766, #1777, #1799, #1810 and #1823, all fixed. Between runs 12 and 13, fixes closed #343, #344, #346, #391, #392, #393, #422, #458, #484, #509, #531, #618 and #682. Cells marked "fixed #N" haven't been re-verified unless they say "pass (run N)".

Coverage matrix

Cells are "pass", "fail #N" or "untested". Every cell uses a real go build/go run against a hermetic file GOPROXY and a hand-staged .socket/manifest.json plus blob (the tests/e2e_golang_build.rs shape). Since run 6, hosted and vendored cells use a local Python mock patch API (hosted: view/<uuid> + /patches/package with a goproxy override, as in e2e_golang_hosted_build.rs; vendored: a granted tarball with sha512, as in vendor/golang.rs mount_go_granted). The module proxy is served over http so hosted rollback works. Global cells use a real go install as a non-root user plus a local mock patch API. Rows before run 3 were tested on f6b7fb9. Since v5, vendored vendor needs the patch service (--vendor-source=service), so new vendored cells need a mock.

OS	go	Agent apply (plain)	Agent edge shapes (uppercase, /v2, pseudo, gopkg.in, CRLF, replace block/exclude/retract/toolchain, godebug/tool, nested module paths, new-file patches, tidy, idempotent, rollback, remove)	+incompatible / no-go.mod module (%2B key)	Vendored vendor (plain)	Committed vendor/ dir	go env -w settings	Upgrade drift → VEX	Transitive / unselected version	go.work user replace	go.work without use .	go.work shared replace (#1764)	go.work, 2 members each patched	Hosted	tidy → rollback/remove (go.sum)	GOWORK=off / GOWORK= / GOFLAGS=-modfile	Patch edits module's own go.mod (bump/add require)	Hosted patch update (new uuid / republish)	Hosted /v2, +incompatible, pseudo, indirect	go.work members require different versions	go work vendor (non-root member)	Module only a replace target (fork idiom)	Replace target, fork required only transitively (go 1.16 graph)	Stale go.sum zip after go get downgrade (go 1.16 directive)
Linux	1.16.15	blocked (no 1.16 download: go.dev/dl.google.com denied)	blocked	blocked	untested	fixed #343	fixed #344	untested	untested	n/a (no go.work)	n/a	n/a	n/a (no go.work)	untested	untested	n/a	n/a (no proxy toolchain)	untested	untested	n/a (no go.work)	n/a	blocked	blocked	blocked
Linux	1.21.13	pass (run 16; + patch update)	/v2, rollback, remove pass (run 16); rest untested	pass (run 16: apply/check/vex/rollback/remove)	pass (probe)	fixed #343	fixed #344	fixed #391 (agent)	untested	fixed #393 (agent)	untested	fixed #1810 (not re-run on 1.21)	untested	untested	untested	-modfile fixed #1799 (e2e pass run 20)	fixed #618 (agent)	fixed #682	pass	untested	n/a (go < 1.22)	fixed #1823 (e2e pass run 20)	fail #1840 (agent)	fail #1862 (agent)
Linux	1.24.7 (+1.22.12)	pass (run 13; CRLF go.mod/go.sum pass)	pass	apply/check/rollback pass; vex fixed #484 (agent only; vendored + takeover pass)	pass	fixed #343 (agent, vendored, hosted apply/rollback); vendored undo fixed #1777 (not re-run)	fixed #344	fixed #391 (agent) / vendored pass / hosted pass (vex exits 2)	fixed #392 (agent + vendored), fixed #509 (hosted, go 1.16)	fixed #393 (agent, vendored, hosted)	fixed #458 (agent, vendored, hosted)	apply/rollback/remove/CRLF pass (run 18); GOWORK=/ci.work apply/rollback/remove + ci.work user replace pass (run 20)	fixed #531 (agent, 1.22 + 1.24; vendored 1.24); hosted pass (identical module-path replaces)	plain get/day-2/idempotent/rollback/CRLF pass; +incompatible blocked (server contract)	fail #549 (agent, 1.22 + 1.24; vendored 1.24); hosted pass	off pass; <path> pass; <path> + user replace fixed #393; -modfile (env and go env -w) pass (run 20)	fixed #618 (agent 1.22 + 1.24, vendored 1.24, hosted 1.21/1.22/1.24/1.26)	fixed #682	pass	fixed #1751; transitive (dep go.mod, unpruned chains, go.work version replace) pass (run 17)	apply pass; rollback/remove fixed #1766 (pass run 16, 2 members, 1.24.7)	pass (run 20, agent; fixed #1823); go.work fork replace refuses (pass)	fail #1840 (agent, versioned + versionless, v5.0.1 too; hosted run 22: inert pin + pruned go.sum breaks the build; fixed on #1843 head); same shape in go.work refuses (pass)	fail #1862 (agent; main, v5.0.1, #1843 head); hosted pass (run 22: the rewrite prunes the stale zip line); go 1.21 directive pass
Linux	1.26.3	pass (probe)	/v2, rollback, remove pass (1.26.8, run 16)	pass (1.26.8, run 16)	pass (probe)	fixed #343	fixed #344	fixed #391 (agent (1.26.8))	untested	fixed #393 (agent (1.26.8))	fixed #458 (agent, 1.26.8)	fixed #1810 (not re-run on 1.26)	fixed #531 (agent, 1.26.8)	untested	fail #549 (agent, 1.26.8)	untested	fixed #618 (agent, 1.26.8)	fixed #682 (1.26.8)	pass (1.26.8)	fixed #1751; transitive fixed by #1763 (not re-run on 1.26)	rollback/remove fixed #1766 (not re-run on 1.26)	fixed #1823 (e2e pass run 20, 1.26.8)	fail #1840 (agent, 1.26.8)	fail #1862 (agent, 1.26.8)
macOS	1.24.13 / 1.26.3	untested (plain; the vendor/-dir cell got as far as apply exit 0)	untested	untested	untested	fixed #343	fixed #344	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested
Windows	1.16.15 / 1.21.13 / 1.26.3	fixed #346	untested (#346 fixed)	untested (#346 fixed)	fixed #346	untested (#346 fixed)	fixed #344	untested (#346 fixed)	untested (#346 fixed)	untested (#346 fixed)	untested (#346 fixed)	untested	untested (#346 fixed)	untested	untested (#346 fixed)	untested	untested (#346 fixed)	untested	untested	untested	untested	untested	untested	untested

Global (-g / --global-prefix / SOCKET_GLOBAL)

OS	go	scan -g report (+ --json)	-g --mode hosted refusal	scan -g --mode agent / get -g apply	installed go install binary	rollback -g	vex -g	unwritable prefix	GOENV GOMODCACHE
Linux	1.24.7	pass	pass	pass (cache)	pass (run 13: warns go_installed_tool_stale; pass after reinstall)	pass	fixed #422 (attests stale binary); pass after cache revert	pass (loud)	fixed #344 (silent 0 packages)
Linux	1.25.1	untested	untested	pass (cache)	fixed #422	untested	fixed #422	untested	untested
Linux	1.22.12 / 1.26.8	Go hit crawled (report fields untested: mock lacks /patches/batch)	untested	pass (cache)	fixed #422	pass	pass	untested (ran as root)	untested
Linux	1.16 / 1.21	untested	untested	untested	untested	untested	untested	untested	untested
macOS	any	untested (probe branches blocked)	untested	untested	untested	untested	untested	untested	untested
Windows	any	untested (probe branches blocked)	untested	likely untested (#346 fixed)	untested	untested	untested	untested	untested

Backlog

Mode takeovers (runs 15-16, Linux, go 1.24.7)

Takeover	Result
agent → hosted (get --mode hosted over a go-patches replace)	go.mod/go.sum rewritten, PATCHED, tidy clean; leaves the agent manifest entry and copy behind, so later apply exits 1 (refuses the hosted replace). Docs say to roll back first: known non-bug
hosted → agent (apply)	refuses (intended)
hosted → vendored (vendor eject)	pass (LF + CRLF go.mod), vendor --check pass, vendor --revert restores upstream byte for byte
vendored undo with committed vendor/	fixed #1777 (#1778)
agent → vendored (vendor over a go-patches replace)	pass (run 16): takeover warning, PATCHED, vendor --check, VEX; vendor --revert byte for byte, then apply restores

0. Maintainer request (partly covered, keep it on top): global (-g) mode on macOS and Windows. Linux is done (Global Go patching (-g) reports success and VEX attests not_affected, but tools already built with go install keep running the unpatched code, and nothing tells the user to reinstall them #422 is fixed; its warning passed in run 13). The full checklist is in the 20261001T040000Z entry.
1. Needs a maintainer: delete the stale probe branches bughunt/go/20260930-goenv-vendor, bughunt/go/20260930-windows-apply and bughunt/go/20260930-windows-bisect. git push --delete from the sandbox was denied by the permission classifier again in run 16. Until they're gone, no new probe branches get pushed.
2. On a go 1.16 go.mod, Go apply, apply --check and vex trust a stale go.sum zip line left by a downgrade, so they report an inert replace as applied (or refuse a selected version) #1862 and Go apply, apply --check and vex still treat a replace-target module as built when the replaced fork is required only by a dependency (go 1.16 module), so the patch is attested while the build stays unpatched #1840 in vendored mode (shared go_build_list::select); hosted done in run 22 (On a go 1.16 go.mod, Go apply, apply --check and vex trust a stale go.sum zip line left by a downgrade, so they report an inert replace as applied (or refuse a selected version) #1862 pass, Go apply, apply --check and vex still treat a replace-target module as built when the replaced fork is required only by a dependency (go 1.16 module), so the patch is attested while the build stays unpatched #1840 fail, commented). Re-check Go apply, apply --check and vex still treat a replace-target module as built when the replaced fork is required only by a dependency (go 1.16 module), so the patch is attested while the build stays unpatched #1840 agent + hosted once Fix Go replace target missed in go 1.16 graphs (#1840) #1843 merges. Unpruned (go 1.16) graphs elsewhere in go_build_list: a versioned fork replace at a version MVS raises. -overlay in GOFLAGS, and -modfile in hosted/vendored modes. Still to do from before: a use member that is the patched module, hosted go.work/go.work.sum rollback, member exclude vs a transitive raise, ci.work.sum vs go.work.sum pin reading in hosted/vex.
3. Re-check Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549 once Fix Go patch delivery, audits, and reinstalls #1698 merges (still reproduces on c07af61), and hosted pins after tidy once Keep Go hosted pins after go mod tidy drops the zip line #1748 merges.
4. Vendored → hosted takeover. scan --mode hosted with /patches/batch in the mock and a %2B purl. Vendored mode on 1.21.13 and 1.26.8.
5. Regression re-checks of the Go apply and vendor break every build in projects with a committed vendor/ directory (modules.txt not synced), while apply --check and VEX report success #343/Go settings written with go env -w are ignored: GOPRIVATE modules are requested from proxy.golang.org, a GOPROXY mirror is bypassed, and a GOMODCACHE cache is not found #344/A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393/Go apply writes its replace into a root go.mod that go.work doesn't use, so the workspace build links the unpatched module while apply, apply --check and VEX all report it patched #458/Running Go apply in a second go.work member writes a second replace for the same module@version, so every workspace build fails with "conflicting replacements" while apply, apply --check and VEX all report success #531 fixes on 1.21 and 1.26, and of Vendored Go undo (vendor --revert, rollback, remove) stays silent about a stale vendor/modules.txt, so every build fails with "inconsistent vendoring" #1777 on 1.26. (Run 20: the repo's agent/hosted/vendored Go e2e suites pass on 1.21.13 and 1.26.8.)
6. go.work.sum in hosted workspace mode; a CRLF go.sum in vendored mode.
7. Windows HOME vs USERPROFILE mismatch (go_crawler.rs::get_gomodcache).

Known non-bugs

• GitHub search/issues can return 403 from the sandbox. Dedupe by fetching repos/…/issues?state=all&per_page=100&page=N and grepping locally.
• patches-api.socket.dev is blocked by the sandbox proxy. Stage .socket/manifest.json plus blobs locally. proxy.golang.org IS reachable from the sandbox.
• patches-api.socket.dev is blocked, but a local mock API works for hosted and vendored cells (see the run-6 entry). In the mock's view/<uuid> record, give real before/after hashes: hosted vex checks the cached gopatch module against them (hash_mismatch otherwise). Hosted rollback refuses a file:// upstream proxy URL, so serve the proxy over http://.
• Running apply from a package subdirectory (no go.mod in cwd) fails closed with "matched no installed package". Use --cwd <module root>.
• Hosted rollback with a go.sum that lists ONLY the patched module rewrites the restored lines as LF even when the file was CRLF. Cosmetic (go accepts both); with other modules present, CRLF is kept. Not filed.
• Hosted rollback after an upgrade (go get M@newer) refuses with patched_ref_invalid and points at git checkout -- go.mod: fails closed by design.
• 3.3.0 rejects the hand-staged manifest shape (apply exit 1), so it can't be compared on these cells. 4.0.0 vex needs an explicit --product in these fixtures (there's no git remote).
• apply refuses (exit 1) when go.mod has a user-authored replace M => … for the patched module: intended. (The same line in go.work is NOT refused, which is A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393.)
• Agent-mode repair doesn't rebuild a deleted .socket/go-patches/ copy. repair --help scopes rebuilding to vendored artifacts; re-run apply.
• go ... -modcacherw leaves cache FILES read-only (directories only), so it's not a workaround for On Windows, Go apply and vendor always fail with "Access is denied. (os error 5)" because the copied module-cache files keep their read-only attribute #346.
• With manifest deleted, agent-mode go-patches redirects are not attestable (manifest_not_found): documented in e2e_golang_build.rs.
• Workspace mode rejects GOFLAGS=-mod=mod (a go restriction); unset GOFLAGS in go.work fixtures.
• Fixture pitfalls: build proxy zips with zip -D (directory entries change the h1 hash, so go mod verify fails on a pristine cache). As non-root, chmod -R u+w before rm -rf of a module cache. A partly deleted cache survives and contaminates the next run.
• rollback -g needs the before blob (fetched from patches-api.socket.dev, which the sandbox blocks). Stage it in .socket/blobs/ and use --offline. A loud failure without it is expected.
• go mod verify reports dir has been modified after a global (-g) in-place patch. That's inherent to patching the module cache in place, and rollback restores it.
• A go.work root with NO root go.mod: apply exits 1 "matched no installed package" and writes nothing (root-only discovery, fails closed). Run with --cwd <member> instead, which builds PATCHED. Not filed.
• go.work use ( . ./svc ) on one line is a go parse error; put each use on its own line or in a multi-line block.
• In v5, rollback removes the manifest entry, so a later remove <purl> reports "No patch found". Expected.
• GOPROXY=file:// with a space in the path breaks go mod download (fixture issue). Keep proxy and cache paths plain.
• Concurrent apply runs are serialized by .socket/apply.lock; the losers fail fast with a --lock-timeout hint. Expected.
• v5 vendor --offline fails with "--vendor-source=service needs the network": by design (local artifact building was removed in v5).
• A backtick-quoted path in go.mod is rejected by go itself ("invalid quoted string"). Not a socket-patch bug. Double-quoted paths work.
• GOWORK=off with a root go.work that doesn't use .: builds use go.mod only and are PATCHED, so Go apply writes its replace into a root go.mod that go.work doesn't use, so the workspace build links the unpatched module while apply, apply --check and VEX all report it patched #458 doesn't apply.
• apply --check audits only the manifest's files in .socket/go-patches/<m>@<v>/. An edited unpatched file, or an added .go file, passes --check and gets built. That's by design (docs: commit and review the copy like vendored code). Not filed.
• Agent apply with a cold module cache exits 1 with package_not_installed: correct. Run go mod download first.
• Rollback of a go.mod that had no trailing newline leaves one added. Cosmetic, not filed.
• Vendored mock: SOCKET_VENDOR_URL=<mock> plus POST */patch/package granted tarball (see the run-9 entry). vex needs non-empty vulnerabilities in the manifest, otherwise it errors with "No applied patches with vulnerability metadata".
• Hosted rollback needs the upstream go.sum hashes. For a module sum.golang.org doesn't know, it exits 1 ("Cannot restore … restore it from version control") unless GOSUMDB=off / GONOSUMDB is set: fails closed by design.
• Hosted get with a user replace for the patched module in go.mod (versioned or versionless) writes nothing and warns redirect_golang_replace_conflict: intended.
• Hosted mode in a go.work with several members writes identical module-path replaces, which Go accepts. So Running Go apply in a second go.work member writes a second replace for the same module@version, so every workspace build fails with "conflicting replacements" while apply, apply --check and VEX all report success #531 is agent- and vendored-only.
• Toolchains for 1.21+ are fetched with GOMODCACHE=<dir> GOTOOLCHAIN=go<ver> GOPROXY=https://proxy.golang.org GOSUMDB=sum.golang.org go version, then run <dir>/golang.org/toolchain@v0.0.1-go<ver>.linux-amd64/bin/go directly against the fixture proxy.
• Hosted rollback after a patch update (Hosted Go redirect leaves the superseded gopatch module's go.sum lines behind when a newer patch replaces an existing redirect, so go mod tidy is no longer a no-op #682) still restores byte for byte, because it prunes every patch.socket.dev/gopatch/ line. Only the forward rewrite leaves stale lines.
• A UTF-8 BOM in go.mod: go itself rejects it ("unexpected input character '\ufeff'"). Not applicable.
• A relative GOWORK: go rejects it ("not an absolute path"). socket-patch still resolves the file and refuses on its replace, so it fails closed.
• go.work use spellings (a, ./a/, ./b/../a, quoted, absolute) and symlinked members all match correctly for the Go apply writes its replace into a root go.mod that go.work doesn't use, so the workspace build links the unpatched module while apply, apply --check and VEX all report it patched #458 member check (run 14).
• The Global Go patching (-g) reports success and VEX attests not_affected, but tools already built with go install keep running the unpatched code, and nothing tells the user to reinstall them #422 go_installed_tool_stale check dates binaries by mtime: an older-touched rebuilt binary is flagged again (conservative). A tool built later from its own vendor/ isn't built from the patched cache, so it's out of scope for -g.
• A direct agent → hosted takeover (get --mode hosted without rollback first) leaves the agent manifest entry and .socket/go-patches/ copy, and later apply exits 1 refusing the hosted replace. migrating-to-v5.md says to run rollback before moving to hosted. Not filed.
• An offline rollback of that mixed state removes the agent record, then fails the hosted restore (exit 1, "restore it from version control"). It fails closed.
• A hosted → vendored eject on a CRLF go.sum that lists only the patched module writes it back as LF. Cosmetic, the same as the hosted-rollback note above.
• My mock read cfg.json only once at startup. Reload it on every request, or get returns notFound.
• Hosted rollback with GOPRIVATE, GONOPROXY, GOPROXY=off or GOPROXY=direct exits 1, writes nothing and points at SOCKET_GOPROXY / version control. That's fail-closed by design (run 16). GOPRIVATE + SOCKET_GOPROXY restores byte for byte.
• go 1.16 can't be fetched in the sandbox (go.dev and dl.google.com are denied, and toolchain modules start at 1.21). Cover it only via probe branches.
• After rollback, .socket/blobs is gone too. To re-apply in a fixture, re-stage the blob as well as the manifest.
• GOWORK naming another file in the root while the root go.mod is a use member: the build is PATCHED through the mirrored root go.mod replace (only a stray go.work write). Covered by Go apply writes the shared replace into ./go.work when GOWORK names another file in the same directory, reports success, and the workspace builds unpatched #1810 and not filed separately.
• vendor --revert after an agent → vendored takeover leaves the project unpatched and warns to run apply. That's documented in the warning; apply restores it.
• The repo's *_needs_go_work_vendor_in_workspace e2e tests fail on go 1.21.x in fixture setup, because go work vendor only exists from go 1.22. That's a toolchain limit, not a product bug.
• Duplicate require lines for one module: go refuses them under -mod=readonly ("updates to go.mod needed"), so the last-wins parse in parse_required_versions isn't reachable (run 22).
• A Go project with a go.mod but no go.sum (deps only via directory replaces) crawls the whole GOMODCACHE. With go 1.16, agent apply/vex then attest cached modules that are absent from the build (Unknown selection). Tracked under Tracking: scope project-mode cache crawls to what the project resolves #595 (comment, run 22), not filed separately: nothing unpatched ships.
• Unpruned exclude after go mod tidy: go.sum holds only the selected version, so selection is correct (run 22).

[github-actions[bot]]

[agent] 2026-09-30: Go modules bug-hunt run

This is the first run, so the ledger started empty and there were no pm:go issues to re-triage.

Tested: main f6b7fb9 (CLI reports 4.0.0), latest release 4.0.0, previous release 3.3.0 (GitHub release binaries). Toolchains: go 1.24.7 locally; probes covered 1.16.15, 1.21.13, 1.24.13 and 1.26.3.

Setup: a hermetic file GOPROXY (plus a python3 -m http.server "mirror" for the GOPROXY/GOPRIVATE cells), a real go mod download into a temp GOMODCACHE, and a hand-staged .socket/manifest.json plus blob patching lib.go from PRISTINE to PATCHED. The oracle is the real go build / go run, the same shape as tests/e2e_golang_build.rs. The patch API is blocked by the sandbox, and 3.3.0 doesn't accept the hand-staged manifest, so it can't be compared.

Cells

• Agent apply + rollback, odd module paths and versions (Linux): pass for uppercase path (example.com/Azure/Upstream), /v2 module, pseudo-version, uppercase pre-release, gopkg.in/x.v3. Rollback restores go.mod byte-exact.
• Agent, CRLF go.mod: pass (CRLF kept, byte-exact rollback).
• Agent, idempotent re-apply + go mod tidy: pass (both no-ops).
• Agent, user version-less replace M => ../fork: loud refusal (user-authored replace … refusing to overwrite). OK.
• Agent/vendored with a committed vendor/ (go mod vendor): fail → Go apply and vendor break every build in projects with a committed vendor/ directory (modules.txt not synced), while apply --check and VEX report success #343. Exit 0, but the build breaks with "inconsistent vendoring", apply --check says in sync, and VEX attests. Covered Linux 1.16/1.21/1.24/1.26 and macOS 1.24/1.26.
• go env -w settings (GOENV file): fail → Go settings written with go env -w are ignored: GOPRIVATE modules are requested from proxy.golang.org, a GOPROXY mirror is bypassed, and a GOMODCACHE cache is not found #344. GOPRIVATE leaks the module path to proxy.golang.org, a GOPROXY mirror is bypassed, and GOMODCACHE is not found. Covered all 8 probe cells (Linux, macOS, Windows).
• Windows agent apply / vendored vendor: fail → On Windows, Go apply and vendor always fail with "Access is denied. (os error 5)" because the copied module-cache files keep their read-only attribute #346. Access is denied (os error 5) because of the read-only attribute copied from the module cache. Covered windows-latest and windows-2022 × go 1.16/1.21/1.26, main and 4.0.0. Clearing R makes it pass.
• Agent upgrade drift (go get M@v1.0.1 after apply): apply --check flags it (exit 1), but vex still attests not_affected for M@v1.0.0 (exit 0). Vendored mode correctly omits it (vendor_unwired). Reproduced 3× on main plus 4.0.0. Not filed yet (3-issue cap); it's backlog item 1, and the draft is below.
• go.work root that is not itself a module (use ./svc), apply at the root: exit 1, "matched no installed package". Loud; see backlog. From the member directory: pass (both the member build and the workspace build are PATCHED).
• Vendored repair after deleting .socket/vendor/golang: pass (rebuilt offline). Agent repair doesn't rebuild .socket/go-patches (repair's help limits it to vendored artifacts, so that's not a bug). A re-apply heals it.
• remove: pass (go.mod restored).

Issues

• Filed Go apply and vendor break every build in projects with a committed vendor/ directory (modules.txt not synced), while apply --check and VEX report success #343: Go apply and vendor break every build in projects with a committed vendor/ directory (modules.txt not synced), while apply --check and VEX report success #343 (committed vendor/ → build broken)
• Filed Go settings written with go env -w are ignored: GOPRIVATE modules are requested from proxy.golang.org, a GOPROXY mirror is bypassed, and a GOMODCACHE cache is not found #344: Go settings written with go env -w are ignored: GOPRIVATE modules are requested from proxy.golang.org, a GOPROXY mirror is bypassed, and a GOMODCACHE cache is not found #344 (go env -w GOPRIVATE/GOPROXY/GOMODCACHE ignored)
• Filed On Windows, Go apply and vendor always fail with "Access is denied. (os error 5)" because the copied module-cache files keep their read-only attribute #346: On Windows, Go apply and vendor always fail with "Access is denied. (os error 5)" because the copied module-cache files keep their read-only attribute #346 (Windows read-only attribute → every Go apply/vendor fails)

False positives ruled out

• The GOMODCACHE-via-go env -w miss is loud (exit 1), but it's still a real bug, filed as part of Go settings written with go env -w are ignored: GOPRIVATE modules are requested from proxy.golang.org, a GOPROXY mirror is bypassed, and a GOMODCACHE cache is not found #344.
• 3.3.0 apply exit=1: the hand-staged manifest isn't accepted, so it's not comparable.
• The -modcacherw probe variant: it only affects directories, and cache files stay read-only (not a socket-patch issue).

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/36746894687 (vendor/, GOENV; Linux/macOS/Windows × 1.16–1.26)
• https://github.com/SocketDev/socket-patch/actions/runs/36748566793 (Windows plain apply/vendor)
• https://github.com/SocketDev/socket-patch/actions/runs/36750101890 (Windows main vs 4.0.0, R set vs cleared)

git push --delete got HTTP 403 from the git proxy, so a maintainer needs to delete bughunt/go/20260930-goenv-vendor, bughunt/go/20260930-windows-apply and bughunt/go/20260930-windows-bisect.

Next

1. File: agent-mode vex attests an inert .socket/go-patches replace after upgrade drift. The suspect is crates/socket-patch-cli/src/commands/vex.rs:1333 synthesize_go_patches, which never compares the LHS version with require (vendored mode does). The repro is in this entry.
2. go.work root with no root go.mod: decide whether apply/vendor at the workspace root should wire each member or refuse with a clear message (today it's "matched no installed package").
3. Hosted mode (wiremock harness from e2e_golang_hosted_build.rs) × committed vendor/, +incompatible, /v2 originals, and CRLF / BOM go.sum.
4. Windows cells beyond On Windows, Go apply and vendor always fail with "Access is denied. (os error 5)" because the copied module-cache files keep their read-only attribute #346 once it's fixed: long paths, drive-letter replace targets, CRLF checkouts of go.mod.
5. GOFLAGS=-mod=vendor / -mod=readonly in the env or GOENV, and retracted versions.

[github-actions[bot]]

[agent] 2026-09-30 (run 2): Go modules bug-hunt run

Tested: main f6b7fb9, unchanged since run 1 (CLI 4.0.0), and the 4.0.0 GitHub release binary (linux musl) for comparison. Toolchain: go 1.24.7 (Linux only). This run needed no probe branches: all three findings come from go.mod/go.work text logic, which doesn't depend on the OS.

Setup: the same hermetic file GOPROXY + temp GOMODCACHE + hand-staged .socket/manifest.json and blob (the tests/e2e_golang_build.rs shape), extended with upstream v1.0.0/v1.0.1/v1.1.0 and the intermediate modules mida → upstream v1.0.0 and midb → upstream v1.0.1. The oracle is the real go build / go run.

Re-triage

• Go apply and vendor break every build in projects with a committed vendor/ directory (modules.txt not synced), while apply --check and VEX report success #343, Go settings written with go env -w are ignored: GOPRIVATE modules are requested from proxy.golang.org, a GOPROXY mirror is bypassed, and a GOMODCACHE cache is not found #344, On Windows, Go apply and vendor always fail with "Access is denied. (os error 5)" because the copied module-cache files keep their read-only attribute #346: main is unchanged (f6b7fb9), so all three are still open and no fix PR exists. Nothing to close.

Cells

• Agent upgrade drift → VEX (go get M@v1.0.1 / @v1.1.0 after apply): fail → Agent-mode Go vex attests not_affected after go get upgrades the patched module, although the go-patches replace no longer applies and the build links the unpatched code #391. The binary is PRISTINE and apply --check exits 1, but vex exits 0 with not_affected. Reproduced 3× on main, plus on 4.0.0 (4.0.0 needs --product).
• Transitive MVS selection, go 1.16 go.mod (the graph selects upstream v1.0.1; v1.0.0 is also cached and patched): fail → Agent-mode Go apply writes a go-patches replace for a module version the build graph doesn't select, reports it applied, and on a go 1.16 go.mod apply --check and vex also report it as patched #392. apply exits 0 and reports it applied, --check says in sync, vex gives not_affected, and the binary is PRISTINE. Same on 4.0.0.
• Same graph with a go 1.21 go.mod: apply exits 0 and reports it applied, and its own --check then flags drift. The VEX leak is Agent-mode Go vex attests not_affected after go get upgrades the patched module, although the go-patches replace no longer applies and the build links the unpatched code #391; the apply part is covered in Agent-mode Go apply writes a go-patches replace for a module version the build graph doesn't select, reports it applied, and on a go 1.16 go.mod apply --check and vex also report it as patched #392.
• Project that doesn't depend on the patched module (only cached): apply exits 0 and writes a replace into the unrelated go.mod. Covered in Agent-mode Go apply writes a go-patches replace for a module version the build graph doesn't select, reports it applied, and on a go 1.16 go.mod apply --check and vex also report it as patched #392.
• go.work user replace (M v1.0.0 => ../fork, M => ../fork): fail → A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393. Agent apply and vendored vendor both exit 0, the build links FORK, --check says in sync, and VEX gives not_affected ((vendored) in vendored mode). The same line in go.mod is correctly refused.
• go.mod with a replace ( … ) block, exclude, retract, toolchain, and comments: pass (apply, build PATCHED, --check, byte-exact rollback).
• GOFLAGS=-mod=readonly build after apply: pass.
• Idempotent re-apply and go mod tidy after apply: pass (go.mod md5 unchanged).
• remove <purl> -y: pass (go.mod restored, build PRISTINE, blob GC'd).

Issues

• Filed Agent-mode Go vex attests not_affected after go get upgrades the patched module, although the go-patches replace no longer applies and the build links the unpatched code #391: Agent-mode Go vex attests not_affected after go get upgrades the patched module, although the go-patches replace no longer applies and the build links the unpatched code #391 (VEX ignores upgrade drift)
• Filed Agent-mode Go apply writes a go-patches replace for a module version the build graph doesn't select, reports it applied, and on a go 1.16 go.mod apply --check and vex also report it as patched #392: Agent-mode Go apply writes a go-patches replace for a module version the build graph doesn't select, reports it applied, and on a go 1.16 go.mod apply --check and vex also report it as patched #392 (apply redirects a version the build graph doesn't select; go ≤1.16 hides it from check/VEX)
• Filed A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393: A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393 (a go.work user replace overrides the Socket replace)

False positives ruled out

• The workspace build failing with -mod may only be set to readonly or vendor when in workspace mode came from my fixture's GOFLAGS=-mod=mod, not from socket-patch. Re-ran with GOFLAGS= unset.
• remove --yes isn't a flag (-y is), so the first remove attempt was a CLI usage error and not a bug.

Probe branches

None were pushed. Run 1's three stale probe branches still need a maintainer to delete them, because git push --delete got a 403 then.

Next

1. Hosted mode via the wiremock harness (e2e_golang_hosted_build.rs) × go.work user replace (A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393 variant), upgrade drift, /v2, +incompatible, CRLF/BOM go.sum.
2. Toolchain matrix for Agent-mode Go vex attests not_affected after go get upgrades the patched module, although the go-patches replace no longer applies and the build links the unpatched code #391/Agent-mode Go apply writes a go-patches replace for a module version the build graph doesn't select, reports it applied, and on a go 1.16 go.mod apply --check and vex also report it as patched #392/A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393 on 1.16 (no go.work there), 1.18, 1.21 and 1.26 via a probe branch, if the branches can be deleted afterwards.
3. GOFLAGS=-mod=vendor in the env or GOENV, and a committed vendor/ together with go.work (go work vendor, 1.22+).
4. go.work root without a root go.mod: decide whether it's a limitation or a bug (still "matched no installed package").
5. Windows cells once On Windows, Go apply and vendor always fail with "Access is denied. (os error 5)" because the copied module-cache files keep their read-only attribute #346 is fixed.

[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 Go modules version and on Linux, macOS and Windows.

Where Go modules puts global installs: go install pkg@version and the module cache (GOMODCACHE, GOPATH/pkg/mod, go env -w values; see #344). Check read-only module-cache files on Windows (see #346).

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 Go modules 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 Go modules 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 × Go modules 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: Go modules bug-hunt run

Tested: main 2463257 (feat!: consolidate the v5 patching workflow (#277); the CLI still reports 4.0.0), latest release 4.0.0 (linux musl binary) for comparison. Toolchains: go 1.24.7 and 1.25.1, Linux only. Global cells ran as the non-root ubuntu user, so read-only module-cache permissions were real.

Setup: a hermetic file GOPROXY (zips must be built with zip -D, otherwise go mod verify fails even on a pristine cache), a real go install example.com/tool@v1.0.0 that depends on example.com/upstream@v1.0.0, and a local Python mock of the patch API (/patches/batch, /patches/by-package, /patches/view, in the shape tests/docker_e2e_golang.rs uses), passed with --api-url/--api-token/--org.

Re-triage

• Agent-mode Go vex attests not_affected after go get upgrades the patched module, although the go-patches replace no longer applies and the build links the unpatched code #391: still reproduces on 2463257 (commented). The new docs line "regenerate VEX after dependency updates" doesn't help, because the regenerated VEX is the wrong one.
• A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393: still reproduces on 2463257 (commented).

Cells (maintainer backlog item 0: global -g)

• scan -g report-only, outside a project, human and --json: pass. It finds exactly the module-cache modules (upstream + tool) and lists the one with a patch.
• scan -g inside a project: pass. Same result, and no project files are written.
• scan -g --mode hosted / scan --global-prefix … --mode hosted: pass (exit 2, designed message, nothing written).
• scan -g --mode agent, get -g, SOCKET_GLOBAL=1 get: the module cache is patched in place and the read-only modes are restored. The next go build / go install links PATCHED. But the already-installed go install binary stays PRISTINE, there's no reinstall hint, and vex -g attests not_affected → fail Global Go patching (-g) reports success and VEX attests not_affected, but tools already built with go install keep running the unpatched code, and nothing tells the user to reinstall them #422 (1.24.7 and 1.25.1; also on 4.0.0).
• apply -g re-run: pass (idempotent, "already patched").
• rollback -g --offline with the before blob in .socket/blobs: pass (byte-exact, go mod verify passes again, manifest emptied). Without the before blob it fails loudly (the blob fetch goes to patches-api.socket.dev, which the sandbox blocks).
• vex -g after go clean -modcache plus a re-download: pass (omitted as not_applied, exit 1).
• --global-prefix "/opt/gm root/modcache" (space in the path, root-owned, run as non-root): pass. Loud Permission denied (os error 13), exit 1, JSON apply_failed.
• go env -w GOMODCACHE=… + scan -g: fail, silent (scannedPackages: 0, exit 0). Same root cause as Go settings written with go env -w are ignored: GOPRIVATE modules are requested from proxy.golang.org, a GOPROXY mirror is bypassed, and a GOMODCACHE cache is not found #344, so I commented there instead of filing.

Issues

• Filed Global Go patching (-g) reports success and VEX attests not_affected, but tools already built with go install keep running the unpatched code, and nothing tells the user to reinstall them #422: Global Go patching (-g) reports success and VEX attests not_affected, but tools already built with go install keep running the unpatched code, and nothing tells the user to reinstall them #422
• Commented Agent-mode Go vex attests not_affected after go get upgrades the patched module, although the go-patches replace no longer applies and the build links the unpatched code #391, A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393 (still reproduce on v5 main) and Go settings written with go env -w are ignored: GOPRIVATE modules are requested from proxy.golang.org, a GOPROXY mirror is bypassed, and a GOMODCACHE cache is not found #344 (global-mode impact).

False positives ruled out

• go mod verify "dir has been modified" after a byte-exact rollback: a fixture artifact. zip -r adds directory entries, which changes the zip h1 hash. Rebuilt the fixture with zip -D, and verify passes on a pristine cache and after rollback.
• 1.25.1 "before: PATCHED": a fixture artifact. As non-root, rm -rf can't delete the read-only module cache, so the previous run's patched cache survived. Fixed with chmod -R u+w first.
• Project (hosted default) scan exit 1 "failed to resolve patch references": my mock doesn't implement the hosted reference endpoint. Not a bug.

Probe branches

None pushed. git push origin --delete bughunt/go/20260930-goenv-vendor still fails (the remote hangs up / 403), so new probe branches couldn't be cleaned up. The three stale run-1 branches still need a maintainer to delete them. macOS and Windows -g cells are blocked on this.

Next

1. Global -g on macOS and Windows (and on go 1.16 / 1.21 / 1.26), once probe branches can be deleted. Windows -g apply is presumably also hit by On Windows, Go apply and vendor always fail with "Access is denied. (os error 5)" because the copied module-cache files keep their read-only attribute #346 (read-only attribute).
2. --global-prefix shapes: $GOPATH root instead of $GOPATH/pkg/mod (does the crawler report pkg/mod/... module paths or the cache/download tree?), multi-entry GOPATH, empty GOMODCACHE/GOPATH, relative GOMODCACHE (go rejects it).
3. Hosted mode: extend the mock with the hosted reference + gopatch module endpoints (see e2e_golang_hosted_build.rs), then × go.work replace, upgrade drift, /v2, +incompatible, CRLF/BOM go.sum.
4. GOFLAGS=-mod=vendor in env/GOENV, and go work vendor with a committed vendor/.
5. go.work root without a root go.mod (still "matched no installed package"): limitation or bug.

[github-actions[bot]]

[agent] 2026-10-01 (run 4): Go modules bug-hunt run

Tested: main 2463257 (unchanged since run 3; CLI 4.0.0), latest release 4.0.0 (linux musl binary) for comparison. Toolchains: go 1.24.7 (local), plus 1.22.12 and 1.26.8 from the golang.org/toolchain module on proxy.golang.org. Linux only. 1.18 couldn't be fetched: dl.google.com is blocked by the sandbox proxy, and the toolchain module only exists for 1.21+.

Re-triage

• Go apply and vendor break every build in projects with a committed vendor/ directory (modules.txt not synced), while apply --check and VEX report success #343: still reproduces on 2463257. Also confirmed on a go work vendor workspace vendor dir (go 1.22+). Commented: Go apply and vendor break every build in projects with a committed vendor/ directory (modules.txt not synced), while apply --check and VEX report success #343 (comment)
• Agent-mode Go apply writes a go-patches replace for a module version the build graph doesn't select, reports it applied, and on a go 1.16 go.mod apply --check and vex also report it as patched #392: still reproduces on 2463257 (the unrelated-project variant). Commented: Agent-mode Go apply writes a go-patches replace for a module version the build graph doesn't select, reports it applied, and on a go 1.16 go.mod apply --check and vex also report it as patched #392 (comment)

Cells

• go.work that doesn't use the root module (use ./svc only), agent apply: fail Go apply writes its replace into a root go.mod that go.work doesn't use, so the workspace build links the unpatched module while apply, apply --check and VEX all report it patched #458 on 1.22.12, 1.24.7 and 1.26.8, with or without a root require. It's on 4.0.0 too, so not a regression. The replace goes into the ignored root go.mod, the member builds PRISTINE, and apply --check (in sync) and vex (not_affected) both pass it.
• The same shape with use . added (control): pass (member builds PATCHED).
• go.work root with no root go.mod: pass (loud). apply exits 1 "matched no installed package" and writes nothing. --cwd svc (a member) works and builds PATCHED. Recorded as a limitation.
• go work vendor + committed vendor/ + agent apply: fail Go apply and vendor break every build in projects with a committed vendor/ directory (modules.txt not synced), while apply --check and VEX report success #343 (same root cause; commented, not filed).
• Vendored vendor on any shape: blocked. v5 vendor only supports --vendor-source=service ("Local artifact building is no longer supported"), and the sandbox can't reach the patch service. The vendored cells need the wiremock harness from now on.

Issues

• Filed Go apply writes its replace into a root go.mod that go.work doesn't use, so the workspace build links the unpatched module while apply, apply --check and VEX all report it patched #458: Go apply writes its replace into a root go.mod that go.work doesn't use, so the workspace build links the unpatched module while apply, apply --check and VEX all report it patched #458
• Commented Go apply and vendor break every build in projects with a committed vendor/ directory (modules.txt not synced), while apply --check and VEX report success #343, Agent-mode Go apply writes a go-patches replace for a module version the build graph doesn't select, reports it applied, and on a go 1.16 go.mod apply --check and vex also report it as patched #392.

False positives ruled out

• A one-line use ( . ./svc ) in go.work is a go parse error ("usage: use local/dir"): a fixture mistake, not a product bug.

Probe branches

None pushed. git push origin --delete bughunt/go/20260930-goenv-vendor still fails ("unexpected disconnect while reading sideband packet"). The three stale run-1 branches are still there and need a maintainer to delete them.

Next

1. Global -g on macOS/Windows and on go 1.21/1.26 (maintainer request). Linux 1.22.12 / 1.26.8 toolchains can be fetched from proxy.golang.org, so the Linux part of the version axis is doable next run.
2. Vendored and hosted cells via a local wiremock-style mock of the patch service (vendored now needs --vendor-source=service): go.work non-member root (Go apply writes its replace into a root go.mod that go.work doesn't use, so the workspace build links the unpatched module while apply, apply --check and VEX all report it patched #458 in vendored/hosted), upgrade drift, /v2, +incompatible, CRLF/BOM go.sum, go.work.sum.
3. --global-prefix shapes: GOPATH root, multi-entry GOPATH, empty or relative GOMODCACHE.
4. GOWORK env var pointing at a go.work outside the root, and GOWORK=off with a root go.work present (socket-patch doesn't read GOWORK).
5. Nested module (apply run from a subdirectory with its own go.mod inside a parent module).

[github-actions[bot]]

[agent] 2026-10-01 (run 5): Go modules bug-hunt run

Tested: main 6e7ef74. Four commits landed since 2463257 (#322, #337, #330, #345), none of them in Go code. CLI 4.0.0. Latest release 4.0.0 (linux musl binary) for comparison. Linux only, go 1.24.7.

Re-triage

• Agent-mode Go vex attests not_affected after go get upgrades the patched module, although the go-patches replace no longer applies and the build links the unpatched code #391: still reproduces on 6e7ef74. After go get @v1.0.1 the build is PRISTINE and apply --check exits 1, but vex still writes not_affected. No comment posted (no new information).
• Go apply writes its replace into a root go.mod that go.work doesn't use, so the workspace build links the unpatched module while apply, apply --check and VEX all report it patched #458: still reproduces on 6e7ef74. go.work use ./svc only: the member builds PRISTINE and apply --check exits 0. No comment posted.

Cells

• +incompatible module with no go.mod in its zip, manifest key %2Bincompatible (the form the API serves), agent mode: apply pass (go.mod is synthesized in the copy, builds PATCHED, go mod verify OK). apply --check pass, rollback pass. vex fail Agent-mode Go vex omits an applied patch for a +incompatible module (not_applied, exit 1) because it looks up the manifest with a literal "+" while the API key spells it %2B #484: it omits the patch as not_applied and exits 1.
  • Controls: the same fixture with a literal + manifest key passes vex, and a no-go.mod module at plain v1.0.0 passes vex.
  • 4.0.0 can't apply the %2B key at all (fixed by Stop hosted Go redirects claiming unpatched deps #252), so this isn't a regression.
• Uppercase module path (example.com/MyOrg/Lib), agent apply + vex: pass.
• CRLF go.mod + go.sum, agent apply / --check / vex / rollback: pass (CRLF preserved).

Issues

• Filed Agent-mode Go vex omits an applied patch for a +incompatible module (not_applied, exit 1) because it looks up the manifest with a literal "+" while the API key spells it %2B #484: Agent-mode Go vex omits an applied patch for a +incompatible module (not_applied, exit 1) because it looks up the manifest with a literal "+" while the API key spells it %2B #484

False positives ruled out

• remove <purl> after rollback reports "No patch found": rollback already drops the manifest entry in v5, so this is expected.

Probe branches

None pushed. git push origin --delete bughunt/go/20260930-goenv-vendor still fails ("the remote end hung up unexpectedly"). The three stale run-1 branches are still there.

Next

1. Global -g on macOS/Windows and on go 1.22 / 1.26 (maintainer request). The Linux toolchains come from the golang.org/toolchain module on proxy.golang.org.
2. A local mock patch service for the vendored and hosted cells. That includes Agent-mode Go vex omits an applied patch for a +incompatible module (not_applied, exit 1) because it looks up the manifest with a literal "+" while the API key spells it %2B #484 in vendored mode: lookup_entry(entries, &purl) in synthesize_go_patches has the same + vs %2B exposure.
3. Other %XX spellings in Go PURLs: the %2B key in hosted mode, vex -g with a +incompatible global module, and get/scan JSON output for +incompatible.
4. --global-prefix shapes: GOPATH root, multi-entry GOPATH, empty or relative GOMODCACHE.
5. GOWORK=<path> / GOWORK=off, and a nested module inside a parent module.

[github-actions[bot]]

[agent] 2026-10-01 (run 6): Go modules bug-hunt run

Tested: main 61cfb9b. 16 commits landed since 6e7ef74, none of them in Go code (#446 scoped -g away from the project's hosted/vendor state). The CLI reports 4.0.0. Linux only, go 1.24.7.

New this run: a local mock patch API (Python http.server):

• Hosted: the view/<uuid> and /patches/package responses with a goproxy registryOverride, the same shape e2e_golang_hosted_build.rs uses.
• Vendored (--vendor-source=service): a granted tarball with sha512 integrity, the same shape as vendor/golang.rs mount_go_granted.

The module proxy is served over http:// because hosted rollback refuses file:// upstream URLs. Hosted and vendored cells are now testable from the sandbox.

Re-triage

• A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393: still reproduces on 61cfb9b in agent mode. I put that in the hosted comment on the issue.
• Agent-mode Go apply writes a go-patches replace for a module version the build graph doesn't select, reports it applied, and on a go 1.16 go.mod apply --check and vex also report it as patched #392: still reproduces with the go 1.16 variant: apply 0, build PRISTINE, --check 0, vex not_affected. My first attempt showed --check 1, but that was a fixture artifact: the upstream go.mod said go 1.21, so tidy bumped the consumer to 1.21.

Cells

• Agent, go.mod with godebug ( … ) and tool directives (go 1.24): apply, --check, idempotent re-run, and rollback all pass. go tool still works.
• Agent, nested module paths (example.com/upstream and example.com/upstream/sub, both patched): apply, --check, vex, and scoped rollback of one module all pass.
• Agent, patch that adds new files (helper.go, internal/x/helper.go): apply, build, go mod verify, --check, and vex all pass. Deleting the new file from the copy is caught by --check ("stale copy … found ") and by vex.
• Agent, running from a package subdirectory (cwd has no go.mod): fails closed (exit 1, "matched no installed package", points at --cwd). Not a bug: it's the root-only discovery already listed under Known non-bugs.
• Hosted, plain get <uuid> --mode hosted: pass. A fresh day-2 machine builds PATCHED (GOSUMDB=bogus), the re-run is idempotent (byte-identical), and rollback is byte-identical with -mod=readonly OK.
• Hosted, upgrade drift (go get M@v1.0.1 after redirect): pass. vex exits 2 (patched_ref_invalid). Rollback refuses loudly and points at git checkout -- go.mod.
• Hosted, CRLF go.mod and go.sum: get, build, vex and rollback pass, and CRLF is kept when go.sum lists other modules. Minor, not filed: when go.sum holds only the patched module, rollback writes the restored lines as LF (cosmetic; go accepts either).
• Hosted, go.work use ./svc only: fail Go apply writes its replace into a root go.mod that go.work doesn't use, so the workspace build links the unpatched module while apply, apply --check and VEX all report it patched #458 (new mode, commented).
• Hosted, user replace in go.work: fail A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393 (new mode, commented).
• Hosted, committed vendor/: fail Go apply and vendor break every build in projects with a committed vendor/ directory (modules.txt not synced), while apply --check and VEX report success #343 (new mode, commented).
• Hosted, go 1.16 graph where the patched version isn't selected: fail Hosted Go redirect's not_in_module_graph gate counts a go.sum /go.mod-only line as "in the graph", so on a go 1.16 module it writes an inert replace for an unselected version and VEX attests not_affected #509 (new). The redirect_golang_not_in_module_graph gate accepts a go.sum /go.mod-only line.
• Vendored, plain: pass.
• Vendored, +incompatible with a %2B key (and with a literal + key): pass.
• Vendored, agent→vendored takeover of a %2B redirect: pass. So Agent-mode Go vex omits an applied patch for a +incompatible module (not_applied, exit 1) because it looks up the manifest with a literal "+" while the API key spells it %2B #484 is agent-only (commented).
• Vendored, go.work use ./svc only: fail Go apply writes its replace into a root go.mod that go.work doesn't use, so the workspace build links the unpatched module while apply, apply --check and VEX all report it patched #458 (folded into the same comment).
• Vendored, go 1.16 unselected version: fail Agent-mode Go apply writes a go-patches replace for a module version the build graph doesn't select, reports it applied, and on a go 1.16 go.mod apply --check and vex also report it as patched #392 (new mode, commented).
• Hosted, +incompatible: blocked. The gopatch version spelling for +incompatible depends on the patch-service contract, and v2.0.0+incompatible-socketpatch.N isn't valid semver. Needs a maintainer answer.

Issues

• Filed Hosted Go redirect's not_in_module_graph gate counts a go.sum /go.mod-only line as "in the graph", so on a go 1.16 module it writes an inert replace for an unselected version and VEX attests not_affected #509: Hosted Go redirect's not_in_module_graph gate counts a go.sum /go.mod-only line as "in the graph", so on a go 1.16 module it writes an inert replace for an unselected version and VEX attests not_affected #509
• Commented:
  • Go apply writes its replace into a root go.mod that go.work doesn't use, so the workspace build links the unpatched module while apply, apply --check and VEX all report it patched #458 (hosted + vendored)
  • A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393 (hosted; agent re-check)
  • Go apply and vendor break every build in projects with a committed vendor/ directory (modules.txt not synced), while apply --check and VEX report success #343 (hosted)
  • Agent-mode Go apply writes a go-patches replace for a module version the build graph doesn't select, reports it applied, and on a go 1.16 go.mod apply --check and vex also report it as patched #392 (vendored; agent re-check)
  • Agent-mode Go vex omits an applied patch for a +incompatible module (not_applied, exit 1) because it looks up the manifest with a literal "+" while the API key spells it %2B #484 (narrowed to agent-only)

False positives ruled out

• The hosted vex hash_mismatch came from my mock: its view record had placeholder before/after hashes. Vex checks the cached gopatch module against them once it's downloaded. With real hashes, vex passes.
• Hosted rollback refusing non-http(s) artifact URL file://…: fixture artifact. Serve the proxy over http.

Probe branches

None pushed. git push origin --delete was denied again this run (the sandbox's permission classifier). The three stale run-1 branches are still there, so a maintainer needs to delete them before more probe branches can be pushed.

Next

1. Global -g on macOS/Windows (maintainer request). Blocked until probe branches can be cleaned up. Also -g on Linux go 1.22 / 1.26 using the proxy toolchains.
2. Hosted +incompatible and /v2+ major-version modules, once the gopatch version spelling for +incompatible is known. Also scan --mode hosted (crawl-driven, not get <uuid>) with a %2B purl.
3. Vendored and hosted with GOPRIVATE / GONOSUMDB / GOFLAGS=-mod=vendor, a go.work.sum, and a CRLF go.sum in vendored mode.
4. --global-prefix shapes: GOPATH root, multi-entry GOPATH, empty or relative GOMODCACHE.
5. GOWORK=<path> / GOWORK=off.

[github-actions[bot]]

[agent] 2026-10-02 (run 7): Go modules bug-hunt run

Tested: main 61cfb9b (unchanged since run 6), CLI 4.0.0. The comparison release is 4.0.0 (npm @socketsecurity/socket-patch-linux-x64-gnu). Linux only. go 1.24.7 for most cells, plus 1.22.12 and 1.26.8 toolchains from proxy.golang.org (golang.org/toolchain module; chmod u+x bin/ pkg/tool/ after copying out of the cache).

Re-triage

• Go settings written with go env -w are ignored: GOPRIVATE modules are requested from proxy.golang.org, a GOPROXY mirror is bypassed, and a GOMODCACHE cache is not found #344: still reproduces on 61cfb9b. With go env -w GOMODCACHE=… (GOENV file) and GOMODCACHE unset, apply reports "matched no installed package" (exit 1) and the build stays PRISTINE. No comment (no new information).
• Every other open pm:go issue was re-checked in run 6 on this same SHA, and no Go code has changed since, so I skipped them.

Cells (agent mode unless noted)

• go.mod with no trailing newline and a trailing // comment on require: apply, build PATCHED and --check pass.
• Consumer path containing a space and é: apply, build, --check, vex not_affected and rollback pass.
• Four concurrent apply runs: pass. One wins and three fail fast on .socket/apply.lock; go.mod has a single replace and the build is PATCHED.
• Patch update (new uuid + afterHash in the manifest): --check flags the stale copy (exit 1), re-apply refreshes it (PATCHED2), and vex not_affected: pass.
• remove <purl>: rolls back, drops the replace, copy and blobs, and the build is PRISTINE: pass.
• User ran go mod edit -dropreplace: --check exits 1 (missing replace), vex omits the patch as not_applied (exit 1), and re-apply restores it: pass.
• go.work with two members that each have their own manifest, applied per member with --cwd: fail Running Go apply in a second go.work member writes a second replace for the same module@version, so every workspace build fails with "conflicting replacements" while apply, apply --check and VEX all report success #531 (new). The second apply writes a second relative replace, and every workspace build fails with "conflicting replacements". apply, --check and vex all exit 0. Reproduced 2× on go 1.24.7, once each on 1.22.12 and 1.26.8, and 2× in the root . + ./tools variant. 4.0.0 behaves the same, so it's not a regression.

Issues

• Filed Running Go apply in a second go.work member writes a second replace for the same module@version, so every workspace build fails with "conflicting replacements" while apply, apply --check and VEX all report success #531: Running Go apply in a second go.work member writes a second replace for the same module@version, so every workspace build fails with "conflicting replacements" while apply, apply --check and VEX all report success #531

False positives ruled out

• GOPROXY=file://<path with a space> makes go mod download fail. That's a fixture problem, not socket-patch: keep the proxy and cache on plain paths and move only the consumer.
• apply in a directory with no .socket/manifest.json exits 0 with "No patch manifest found; nothing to apply." Intended.
• scan --offline refuses (strict airgap, needs the patch API). By design.

Probe branches

None pushed. The three stale run-1 bughunt/go/20260930-* branches still exist, so probe branches stay blocked until a maintainer deletes them.

Next

1. Running Go apply in a second go.work member writes a second replace for the same module@version, so every workspace build fails with "conflicting replacements" while apply, apply --check and VEX all report success #531 in vendored mode (needs the run-6 mock patch service; per-member ./.socket/vendor/golang/<uuid>/… paths should conflict too) and in hosted mode (identical module-path replaces, which Go should accept).
2. Global -g on macOS/Windows (maintainer request; blocked on probe branches) and on Linux 1.22 / 1.26.
3. Hosted +incompatible and /v2+, and scan --mode hosted with a %2B purl.
4. GOPRIVATE / GONOSUMDB / GOFLAGS=-mod=vendor in vendored and hosted mode, plus go.work.sum.
5. GOWORK=<path> / GOWORK=off, and --global-prefix shapes.

[github-actions[bot]]

[agent] 2026-10-02 (run 8): Go modules bug-hunt run

Tested: main 61cfb9b (unchanged since run 6; no Go code changes), CLI 4.0.0, latest release 4.0.0. Linux only. go 1.24.7, plus 1.22.12 and 1.26.8 toolchains from proxy.golang.org.

Re-triage

Skipped this run. Main hasn't moved since runs 6–7, which re-checked #344, #392, #393, #343 and #458 on this same SHA.

Cells (agent mode, hermetic file GOPROXY + hand-staged manifest)

• go.mod with a quoted module path and quoted require path: apply, build PATCHED and --check pass.
• require ( M v1.0.0//indirect ) (comment with no space): pass.
• Backtick-quoted require path: go itself rejects it ("invalid quoted string"), so this isn't a socket-patch bug. Apply still writes a replace and exits 0. Not filed.
• apply → rollback with no tidy: pass on 1.22, 1.24 and 1.26.
• apply → go mod tidy → rollback, and → remove <purl>: fail Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549 (new). Tidy drops the module's go.sum lines (supported per docs). Rollback/remove drop the replace but don't restore those lines, so the next default go build fails with "missing go.sum entry". Rollback exits 0 with warnings: []. Reproduced 2× on 1.24.7 and 1× each on 1.22.12 and 1.26.8.
• GOWORK=off with a root go.work that doesn't use .: apply, build PATCHED and --check pass.
• GOWORK=<external path> that uses the consumer: pass.
• GOWORK=<external path> with a user replace for the patched module: build PRISTINE, --check 0, vex not_affected. Commented on A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393 (new variant: socket-patch never reads GOWORK).
• GOMODCACHE unset, cache derived from GOPATH (single-entry and multi-entry a:b): apply and build PATCHED pass.

Issues

• Filed Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549: Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549
• Commented on A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393: A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393 (comment)

False positives ruled out

• Backtick-quoted module paths in go.mod: go itself rejects them, so there's nothing for socket-patch to get right.

Probe branches

None pushed. git push origin --delete bughunt/go/20260930-goenv-vendor failed again ("unexpected disconnect while reading sideband packet"). The three stale run-1 branches still need a maintainer to delete them.

Next

1. Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549 in vendored mode (vendor --revert after tidy; needs the run-6 mock patch service) and on go 1.21.
2. Running Go apply in a second go.work member writes a second replace for the same module@version, so every workspace build fails with "conflicting replacements" while apply, apply --check and VEX all report success #531 in vendored and hosted mode.
3. Global -g on macOS/Windows (maintainer request; blocked on probe branches) and on Linux 1.22 / 1.26.
4. Hosted +incompatible / /v2+, and scan --mode hosted with a %2B purl.
5. GOPRIVATE / GONOSUMDB / GOFLAGS=-mod=vendor in vendored and hosted mode, plus go.work.sum; empty or relative GOMODCACHE.

[github-actions[bot]]

[agent] 2026-10-02 (run 9): Go modules bug-hunt run

Tested: main bf0e0d1. 21 commits landed since 61cfb9b, none of them in Go code. #486 added a shared-store guard to agent apply and rollback, but it only matches pnpm GVS and PDM cache markers, so Go is unaffected. The CLI reports 4.0.0, latest release 4.0.0. Linux only, go 1.24.7.

New this run: a reusable vendored mock. A Python http.server answers POST */patch/package with {"results":{<uuid>:{"status":"granted","purl":…,"url":…,"artifacts":[{"kind":"tarball","url":…,"integrity":{"sha512":"sha512-<b64>"}}]}}} and serves the patched module zip (entries <module>@<version>/…, built with zip -D) on GET. Point the CLI at it with SOCKET_VENDOR_URL=http://127.0.0.1:<port>; no token is needed.

Re-triage

• Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549: still reproduces on bf0e0d1, 2/2.
• Running Go apply in a second go.work member writes a second replace for the same module@version, so every workspace build fails with "conflicting replacements" while apply, apply --check and VEX all report success #531: still reproduces on bf0e0d1, 2/2.

Cells

• Vendored, vendor → go mod tidy → vendor --revert: fail Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549. Revert exits 0 with no warnings, then the build fails with "missing go.sum entry". Reproduced 2/2. The no-tidy control passes. Commented on Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549.
• Vendored, go.work with 2 members, each vendored: fail Running Go apply in a second go.work member writes a second replace for the same module@version, so every workspace build fails with "conflicting replacements" while apply, apply --check and VEX all report success #531. "conflicting replacements"; vendor and vendor --check both exit 0. Reproduced 2/2. Commented on Running Go apply in a second go.work member writes a second replace for the same module@version, so every workspace build fails with "conflicting replacements" while apply, apply --check and VEX all report success #531.
• Vendored re-run and vendor --check after tidy: pass (skipped, go.mod unchanged).
• Agent re-apply and --check after tidy: pass.
• Agent, two patched modules, scoped rollback <purl> of one: pass (the other replace stays; --check 0).
• Agent, --cwd through a symlinked project dir: apply, --check and rollback pass.
• Agent, unicode and space-containing project path: pass.
• Agent, GOMODCACHE= (empty) with GOPATH: pass.
• Agent, go.mod without a trailing newline: pass. Rollback adds a trailing newline (cosmetic, not filed).
• Agent, go.mod ending in a replace ( … ) block for another module: apply and rollback pass.
• Agent, cold module cache: fails loudly with exit 1 and package_not_installed. Correct.
• Agent, patch updated (new afterHash, same version) then re-apply: pass. --check flags the drift first (exit 1), the re-apply refreshes the copy, and rollback passes.

Issues

• Commented on Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549: Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549 (comment)
• Commented on Running Go apply in a second go.work member writes a second replace for the same module@version, so every workspace build fails with "conflicting replacements" while apply, apply --check and VEX all report success #531: Running Go apply in a second go.work member writes a second replace for the same module@version, so every workspace build fails with "conflicting replacements" while apply, apply --check and VEX all report success #531 (comment)
• No new issues.

False positives ruled out

• apply --check exits 0 when a file NOT in the patch is edited, or a new .go file is added inside .socket/go-patches/<m>@<v>/, and the build runs the injected code. This is by design: verify_go_redirect_state hashes only the manifest's files, and docs/ecosystems.md says to commit and review the copy like vendored code. Added to Known non-bugs.
• Vendored vex with "No applied patches with vulnerability metadata": a fixture artifact (empty vulnerabilities).

Probe branches

None pushed. The three stale run-1 branches still need a maintainer to delete them.

Next

1. Running Go apply in a second go.work member writes a second replace for the same module@version, so every workspace build fails with "conflicting replacements" while apply, apply --check and VEX all report success #531 in hosted mode; hosted mock (view/<uuid> + goproxy override), as in run 6.
2. Global -g on Linux 1.22 / 1.26 via proxy toolchains; macOS/Windows still blocked on probe branches.
3. Hosted +incompatible / /v2+, and scan --mode hosted with a %2B purl.
4. GOPRIVATE / GONOSUMDB / GOFLAGS=-mod=vendor in hosted mode; go.work.sum in hosted workspace mode.
5. A patch that edits the module's own go.mod (changes requirements): what the agent copy does to the consumer graph and go.sum.

[github-actions[bot]]

[agent] 2026-10-02 (run 10): Go modules bug-hunt run

Tested: main 045d7ec (main was force-updated, but bf0e0d1 is still an ancestor; 14 commits since then). The only change that touches Go is #516/#517, which makes agent VEX check every installed copy. Go agent records are judged through synthesize_go_patches (the copy directory), so Go is unaffected. The CLI reports 4.0.0, latest release 4.0.0. Linux. go 1.24.7, plus 1.21.13, 1.22.12 and 1.26.8 toolchains from proxy.golang.org.

Re-triage

• Agent-mode Go vex omits an applied patch for a +incompatible module (not_applied, exit 1) because it looks up the manifest with a literal "+" while the API key spells it %2B #484 (+incompatible agent VEX): still reproduces on 045d7ec, 2/2. The build is PATCHED and --check passes, but VEX skips it ("patched files still hold the original content") and reports no_applicable_patches. No comment posted (nothing new).
• Go apply and vendor break every build in projects with a committed vendor/ directory (modules.txt not synced), while apply --check and VEX report success #343 (committed vendor/): still reproduces. Apply exits 0, then the default build fails with "inconsistent vendoring", and --check exits 0. No comment posted.

Cells

• Agent, a patch that bumps a requirement in the patched module's own go.mod (dep v1.0.0 → v1.1.0): fail Go apply and vendor wire in a patched module whose go.mod raises or adds a requirement without syncing the consumer go.mod/go.sum, so every default go build fails while apply, --check and VEX report success #618 (new). Apply exits 0 with no warnings, then the default go build fails with "updates to go.mod needed". --check exits 0 and VEX gives not_affected. Reproduced 2/2 on 1.24.7 and 1/1 each on 1.21.13, 1.22.12 and 1.26.8.
• Agent, a patch that adds a new require (and imports it): fail Go apply and vendor wire in a patched module whose go.mod raises or adds a requirement without syncing the consumer go.mod/go.sum, so every default go build fails while apply, --check and VEX report success #618. The default build fails with "missing go.sum entry".
• Vendored, the same bump patch served as a granted tarball from the run-9 mock: fail Go apply and vendor wire in a patched module whose go.mod raises or adds a requirement without syncing the consumer go.mod/go.sum, so every default go build fails while apply, --check and VEX report success #618, 2/2. vendor exits 0 and vendor --check exits 0.
• Hosted, the same shape: untested (needs the hosted mock).

Issues

• Filed Go apply and vendor wire in a patched module whose go.mod raises or adds a requirement without syncing the consumer go.mod/go.sum, so every default go build fails while apply, --check and VEX report success #618: Go apply and vendor wire in a patched module whose go.mod raises or adds a requirement without syncing the consumer go.mod/go.sum, so every default go build fails while apply, --check and VEX report success #618

False positives ruled out

• None this run. The yarn sibling's Yarn classic: a patch that adds a dependency to the package's own package.json leaves vendored yarn.lock with a dangling dependency (offline frozen install fails, lock churns), and hosted silently installs without it #591 is the same class of bug for yarn (package.json deps), so it isn't a Go duplicate.

Notes

• GitHub search/issues returned 403 ("sessions are bound to their configured repositories") partway through the run. To dedupe, fetch repos/SocketDev/socket-patch/issues?state=all&per_page=100&page=N page by page and grep it locally.

Probe branches

None pushed. The three stale run-1 branches still exist (git ls-remote) and still need a maintainer to delete them.

Next

1. Go apply and vendor wire in a patched module whose go.mod raises or adds a requirement without syncing the consumer go.mod/go.sum, so every default go build fails while apply, --check and VEX report success #618 in hosted mode (hosted mock from run 6, with a service zip whose go.mod bumps a requirement).
2. Running Go apply in a second go.work member writes a second replace for the same module@version, so every workspace build fails with "conflicting replacements" while apply, apply --check and VEX all report success #531 in hosted mode.
3. Global -g on Linux 1.22 / 1.26 via proxy toolchains (downloads work: GOTOOLCHAIN=go1.26.8 GOPROXY=https://proxy.golang.org go version).
4. Hosted +incompatible / /v2+, and scan --mode hosted with a %2B purl.
5. GOPRIVATE / GONOSUMDB / GOFLAGS=-mod=vendor in hosted mode; go.work.sum in hosted workspace mode.

[github-actions[bot]]

[agent] 2026-10-03 (run 11): Go modules bug-hunt run

Tested: main 045d7ec, which hasn't changed since run 10. The CLI reports 4.0.0, latest release 4.0.0. Linux only: go 1.24.7, plus 1.21.13, 1.22.12 and 1.26.8 toolchains from proxy.golang.org (stored in a dedicated GOMODCACHE and called by path).

Re-triage

Skipped this run. Main hasn't moved since run 10, which re-confirmed #484 and #343, and no Go code has changed since. Nothing new to report on open issues beyond the #618 comment below.

Cells

• Hosted, the gopatch module's go.mod bumps a requirement (dep v1.0.0 → v1.1.0): fail Go apply and vendor wire in a patched module whose go.mod raises or adds a requirement without syncing the consumer go.mod/go.sum, so every default go build fails while apply, --check and VEX report success #618. get <uuid> --mode hosted exits 0 with redirected: 1 and no warnings. The day-2 go build then fails with "updates to go.mod needed" on 1.21.13, 1.22.12, 1.24.7 (2/2) and 1.26.8, and vex still attests not_affected (redirected). Commented on Go apply and vendor wire in a patched module whose go.mod raises or adds a requirement without syncing the consumer go.mod/go.sum, so every default go build fails while apply, --check and VEX report success #618.
• Hosted, go.work with 2 members, get --mode hosted run in each: pass. Both members get the identical module-path replace, so Go accepts it (unlike agent and vendored, Running Go apply in a second go.work member writes a second replace for the same module@version, so every workspace build fails with "conflicting replacements" while apply, apply --check and VEX all report success #531). The workspace builds PATCHED from either member, and GOWORK=off does too.
• Hosted, go.sum that also holds an older /go.mod-only line for the same module (upstream v0.9.0/go.mod): get, then rollback pass, restored byte for byte. Rollback needs the upstream hashes. If sum.golang.org can't serve them (a private or fixture module), it exits 1 loudly and points at git checkout, which is correct. With GOSUMDB=off and a reachable GOPROXY, it restores.
• Hosted, user replace already in go.mod (versionless => ./fork, and versioned v1.0.0 => ./fork): pass. Writes nothing, warns redirect_golang_replace_conflict, and the build keeps the fork.
• Global -g, Linux go 1.22.12 and 1.26.8 (a real go install example.com/tool@v1.0.0 into an isolated GOPATH, with a mock view that inlines blobs):
  • scan -g --json crawls the Go module exactly once, alongside the machine's other global ecosystems. Its status: error came from my mock, which has no /patches/batch endpoint (a fixture limit).
  • get <uuid> -g patches the cache: pass. go run tool@v1.0.0 and a re-go install are PATCHED.
  • The binary that was already installed stays stale: fail Global Go patching (-g) reports success and VEX attests not_affected, but tools already built with go install keep running the unpatched code, and nothing tells the user to reinstall them #422 (as on 1.24/1.25).
  • vex -g gives not_affected, and rollback -g --offline restores PRISTINE: pass.
  • Ran as root, so the unwritable-prefix cell wasn't re-tested.

Issues

• Commented on Go apply and vendor wire in a patched module whose go.mod raises or adds a requirement without syncing the consumer go.mod/go.sum, so every default go build fails while apply, --check and VEX report success #618 (hosted mode, 4 toolchains): Go apply and vendor wire in a patched module whose go.mod raises or adds a requirement without syncing the consumer go.mod/go.sum, so every default go build fails while apply, --check and VEX report success #618 (comment)
• No new issues and no closures.

False positives ruled out

• Hosted rollback "Cannot restore … sum.golang.org/lookup … 404" (exit 1): the fixture module doesn't exist on sum.golang.org. It fails loudly by design, and with GOSUMDB=off it restores byte for byte.
• scan -g status: error "POST …/patches/batch not found": my mock doesn't implement the batch endpoint.

Probe branches

None pushed. git push origin --delete bughunt/go/20260930-goenv-vendor was denied again by the sandbox permission classifier. The three stale run-1 branches still exist and need a maintainer to delete them.

Next

1. Hosted +incompatible / /v2+ (blocked on the service's gopatch spelling for these). Also scan --mode hosted with a %2B purl; this needs /patches/batch added to the mock.
2. scan -g against a mock with /patches/batch, to check the report and JSON fields for a Go global hit.
3. Global -g as non-root on 1.22 / 1.26 (unwritable prefix), and the --global-prefix shapes (GOPATH root, multi-entry GOPATH).
4. GOPRIVATE / GONOSUMDB / GOFLAGS=-mod=vendor in hosted mode, and go.work.sum in hosted workspace mode.
5. The toolchain matrix (1.22 / 1.26) for Agent-mode Go vex attests not_affected after go get upgrades the patched module, although the go-patches replace no longer applies and the build links the unpatched code #391, Agent-mode Go apply writes a go-patches replace for a module version the build graph doesn't select, reports it applied, and on a go 1.16 go.mod apply --check and vex also report it as patched #392, A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393 and Hosted Go redirect's not_in_module_graph gate counts a go.sum /go.mod-only line as "in the graph", so on a go 1.16 module it writes an inert replace for an unselected version and VEX attests not_affected #509.

[github-actions[bot]]

[agent] 2026-10-03 (run 12): Go modules bug-hunt run

Tested: main 045d7ec (unchanged since run 10). The CLI reports 4.0.0, latest release 4.0.0 (previous 3.3.0). Linux only: go 1.24.7, plus 1.21.13 and 1.26.8 toolchains from proxy.golang.org. Hosted cells use a local Python mock (view/<uuid> + POST /patches/package with a goproxy override) and an HTTP module proxy served by the same mock.

Re-triage

• Agent-mode Go vex attests not_affected after go get upgrades the patched module, although the go-patches replace no longer applies and the build links the unpatched code #391 (agent vex after upgrade drift): still reproduces on 1.21.13, 1.24.7 and 1.26.8. Commented with the new toolchains: Agent-mode Go vex attests not_affected after go get upgrades the patched module, although the go-patches replace no longer applies and the build links the unpatched code #391 (comment)
• A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393 (user replace in go.work): still reproduces on 1.21.13, 1.24.7 and 1.26.8. Commented: A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393 (comment)

Cells

• Hosted /v2 module (example.com/up/v2 v2.1.0 → patch.socket.dev/gopatch/<uuid>/v2 v2.1.0-socketpatch.1): get, day-2 build (bogus GOSUMDB), tidy no-op, vex not_affected (redirected), and byte-identical rollback all pass on 1.21.13, 1.24.7 and 1.26.8.
• Hosted +incompatible (a no-go.mod module example.com/old v2.0.0+incompatible, %2B purl → patch.socket.dev/gopatch/<uuid> v2.0.0-socketpatch.1+incompatible): the same chain passes on all 3 toolchains. Caveat: that version spelling is my assumption; the service contract isn't confirmed.
• Hosted pseudo-version (v0.0.0-20240101000000-abcdefabcdef → …-socketpatch.1): pass (1.24.7).
• Hosted indirect dep through an intermediate module (go 1.21 pruned graph, // indirect require): get, build, tidy no-op, go mod verify, vex and rollback all pass.
• Hosted patch update over an existing hosted redirect (new uuid, or same uuid republished as socketpatch.2): fail Hosted Go redirect leaves the superseded gopatch module's go.sum lines behind when a newer patch replaces an existing redirect, so go mod tidy is no longer a no-op #682 (new). go.mod is retargeted correctly, but the superseded gopatch module's 2 go.sum lines are left behind, so go mod tidy -diff exits 1. Reproduced on 1.21.13, 1.24.7 (3×) and 1.26.8. The 4.0.0 release does the same, so it isn't a regression.

Issues

• Filed Hosted Go redirect leaves the superseded gopatch module's go.sum lines behind when a newer patch replaces an existing redirect, so go mod tidy is no longer a no-op #682: Hosted Go redirect leaves the superseded gopatch module's go.sum lines behind when a newer patch replaces an existing redirect, so go mod tidy is no longer a no-op #682
• Commented on Agent-mode Go vex attests not_affected after go get upgrades the patched module, although the go-patches replace no longer applies and the build links the unpatched code #391 and A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393 (new toolchains).

False positives ruled out

• None this run.

Notes

• Not tested yet: in go_crawler.rs::get_gomodcache, $HOME is preferred over %USERPROFILE%. On Windows, Go's os.UserHomeDir uses only USERPROFILE, so an MSYS or Cygwin HOME could point the crawl at the wrong cache. That needs a Windows probe and is blocked by On Windows, Go apply and vendor always fail with "Access is denied. (os error 5)" because the copied module-cache files keep their read-only attribute #346 and the stale branches.
• gosumdb_base treats any GOSUMDB value other than off as sum.golang.org, so a custom or mirror GOSUMDB is ignored by hosted rollback. Low impact; not tested.

Probe branches

None pushed. The three stale run-1 branches still exist and need a maintainer to delete them.

Next

1. Hosted takeovers: agent→hosted and hosted→agent/vendored, including the go.sum state after each.
2. scan --mode hosted (crawl-driven) with /patches/batch added to the mock; also check whether its refresh path hits Hosted Go redirect leaves the superseded gopatch module's go.sum lines behind when a newer patch replaces an existing redirect, so go mod tidy is no longer a no-op #682.
3. Global -g as non-root (unwritable prefix), and the --global-prefix shapes.
4. GOPRIVATE / GONOSUMDB / custom GOSUMDB in hosted rollback; go.work.sum in hosted workspace mode.
5. Toolchain matrix (1.22 / 1.26) for Agent-mode Go apply writes a go-patches replace for a module version the build graph doesn't select, reports it applied, and on a go 1.16 go.mod apply --check and vex also report it as patched #392 and Hosted Go redirect's not_in_module_graph gate counts a go.sum /go.mod-only line as "in the graph", so on a go 1.16 module it writes an inert replace for an unselected version and VEX attests not_affected #509.

[github-actions[bot]]

[agent] Janitor: drift. The 1.21.13 row still says fail #682 (superseded gopatch go.sum lines after a hosted patch update). #682 closed as completed on 2026-10-08 05:51Z (#1035). Please re-verify on main 9472be4f. This ledger has no runs since 2026-10-03.

---

Generated by Claude Code

[github-actions[bot]]

[agent] Janitor: ledger drift. These issues are now closed but this ledger still lists them as fail or open: #343 (completed 2026-10-10), #344 (completed 2026-10-09), #346 (completed 2026-10-09), #618 (completed 2026-10-10). Please re-verify them on current main and update the matrix.

---

Generated by Claude Code

[github-actions[bot]]

[agent] Janitor: ledger drift on main 675fec19. The ledger still lists these issues as open failures (fail #N cells or re-verify to-do items), but they were closed in the 2026-10-26/27 merge wave:

• Global Go patching (-g) reports success and VEX attests not_affected, but tools already built with go install keep running the unpatched code, and nothing tells the user to reinstall them #422: closed as completed, fixed by Fix global Go apply leaving installed tools stale (#422) #1717 (a1cbc791)

Please re-verify them on the next run and update the cells.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-27 (run 13): Go modules bug-hunt run

Tested: main b787454 (5.0.1+171; 593 commits since run 12's 045d7ec), latest release v5.0.1. Linux only: go 1.24.7, plus the 1.22.12 and 1.26.8 toolchains from proxy.golang.org. Hermetic file GOPROXY and a hand-staged manifest (the e2e_golang_build.rs shape).

Since run 12, these issues were closed by fixes on main: #343 and #618 (#1357), #344 (#1356), #346 (#1351), #391, #392 and #509 (#1403), #393, #458 and #531 (#1393), #422 (#1717), #484 (#1427), and #682. Only #549 is still open.

Re-triage

• Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549 (rollback/remove after go mod tidy leaves go.sum empty): still reproduces 2/2 on 1.24.7. Commented: Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549 (comment). Open PR Fix Go patch delivery, audits, and reinstalls #1698 claims a fix.

Cells

• go.work, members requiring different versions of the patched module (a → v1.0.0, b → v1.1.0, no go work sync), agent apply in a: fail In a go.work workspace where another member requires a newer version, Go apply writes an inert replace for the member's older version, and apply --check and VEX report it patched while the workspace build links the unpatched module #1751 (new). The workspace selects v1.1.0, but apply writes an inert v1.0.0 replace (exit 0), apply --check says in sync, and vex says not_affected. Reproduced on 1.22.12, 1.24.7 (2×) and 1.26.8. After go work sync, apply refuses correctly.
• Plain agent apply → build PATCHED → --check → rollback, with a CRLF go.sum and with CRLF go.mod + go.sum: pass (also exercises the Scope the project-mode Go crawl to the modules go.sum records (#1207) #1209 go.sum-scoped crawl).
• A BOM in go.mod: go itself rejects it, so the cell doesn't apply.
• Global -g (Global Go patching (-g) reports success and VEX attests not_affected, but tools already built with go install keep running the unpatched code, and nothing tells the user to reinstall them #422 fix), go-installed tool: apply warns go_installed_tool_stale and vex omits the patch; after go install the tool prints PATCHED and vex attests. pass. The check is by mtime, so touching the binary older brings the warning back, which is the conservative direction.
• A relative GOWORK that points at a go.work with a user replace: go rejects relative GOWORK paths, and apply still refuses on the replace. Fails closed, pass.

Issues

• Filed In a go.work workspace where another member requires a newer version, Go apply writes an inert replace for the member's older version, and apply --check and VEX report it patched while the workspace build links the unpatched module #1751: In a go.work workspace where another member requires a newer version, Go apply writes an inert replace for the member's older version, and apply --check and VEX report it patched while the workspace build links the unpatched module #1751
• Commented on Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549.

False positives ruled out

• BOM go.mod (go rejects it). Relative GOWORK (go rejects it).
• A -mod=vendor tool built after the patch time would slip past the mtime-based Global Go patching (-g) reports success and VEX attests not_affected, but tools already built with go install keep running the unpatched code, and nothing tells the user to reinstall them #422 check, but such a tool isn't built from the patched cache, so it's out of scope for -g. Not filed.

Probe branches

None pushed. git push --delete of the three stale run-1 branches was denied again by the permission classifier. A maintainer still needs to delete them.

Next

1. In a go.work workspace where another member requires a newer version, Go apply writes an inert replace for the member's older version, and apply --check and VEX report it patched while the workspace build links the unpatched module #1751 in vendored and hosted mode (both call go_build_list), and a go.work-level require-free variant (go.work replace of another version).
2. Re-verify the closed fixes (Go apply and vendor break every build in projects with a committed vendor/ directory (modules.txt not synced), while apply --check and VEX report success #343/Go apply and vendor wire in a patched module whose go.mod raises or adds a requirement without syncing the consumer go.mod/go.sum, so every default go build fails while apply, --check and VEX report success #618 warnings, Go settings written with go env -w are ignored: GOPRIVATE modules are requested from proxy.golang.org, a GOPROXY mirror is bypassed, and a GOMODCACHE cache is not found #344 go env -w, A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393/Go apply writes its replace into a root go.mod that go.work doesn't use, so the workspace build links the unpatched module while apply, apply --check and VEX all report it patched #458/Running Go apply in a second go.work member writes a second replace for the same module@version, so every workspace build fails with "conflicting replacements" while apply, apply --check and VEX all report success #531 refusals) on 1.21 and 1.26, looking for regressions.
3. Once Fix Go patch delivery, audits, and reinstalls #1698 merges: Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549 re-check and its native-vendor audit (go_vendor_content_mismatch).
4. Hosted takeovers (agent↔hosted↔vendored) and their go.sum state; scan --mode hosted with /patches/batch in the mock.
5. Windows and macOS cells now that On Windows, Go apply and vendor always fail with "Access is denied. (os error 5)" because the copied module-cache files keep their read-only attribute #346 is closed (blocked on the stale probe branches).

[github-actions[bot]]

[agent] 2026-10-28 (run 14): Go modules bug-hunt run

Tested: main b787454 (5.0.1+171, the same commit as run 13), latest release v5.0.1. Linux only: go 1.24.7, plus the 1.22.12 and 1.26.8 toolchains. Hermetic file GOPROXY and a hand-staged manifest. I also built the head of the open PR stack #1764/#1765 to check whether it already fixes the bug below.

Re-triage

• Main hasn't changed since run 13, so Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549 and In a go.work workspace where another member requires a newer version, Go apply writes an inert replace for the member's older version, and apply --check and VEX report it patched while the workspace build links the unpatched module #1751 weren't re-run. In a go.work workspace where another member requires a newer version, Go apply writes an inert replace for the member's older version, and apply --check and VEX report it patched while the workspace build links the unpatched module #1751 has a fix in draft PR Fix Go version gate ignoring go.work members (#1751) #1752. Its hosted-scan half was split out by a maintainer as Hosted Go scan in a go.work member pins a version another member outranks #1753, which covers backlog item "In a go.work workspace where another member requires a newer version, Go apply writes an inert replace for the member's older version, and apply --check and VEX report it patched while the workspace build links the unpatched module #1751 in hosted mode".

Cells

• go work vendor (workspace vendor dir), agent apply in a non-root member (use ./a): apply warns go_vendor_modules_txt_out_of_sync and --check fails until go work vendor; then the build is PATCHED and --check is in sync. pass.
• The same workspace, then rollback / remove in the member: fail Go rollback and remove in a go.work member stay silent about a stale go work vendor modules.txt, so every workspace build fails with "inconsistent vendoring" #1766 (new). Both exit 0 with no warning, and --check says "No patches to check", but every workspace build fails with "inconsistent vendoring". The recorded ./a/.socket/go-patches/… target isn't recognised as socket-owned. Reproduced on 1.22.12, 1.24.7 (3×, rollback and remove) and 1.26.8, and also on the Test Go workspace vendoring and GOWORK #1765 PR head. Control: with a use . root module, rollback warns (pass).
• go.work use spellings for the Go apply writes its replace into a root go.mod that go.work doesn't use, so the workspace build links the unpatched module while apply, apply --check and VEX all report it patched #458 member check: a, ./a/, ./b/../a, "./a", an absolute path: all pass (apply, build PATCHED).
• A symlinked use member (ws/a -> real/a), applying from the link path or from the real path: pass.

Issues

• Filed Go rollback and remove in a go.work member stay silent about a stale go work vendor modules.txt, so every workspace build fails with "inconsistent vendoring" #1766: Go rollback and remove in a go.work member stay silent about a stale go work vendor modules.txt, so every workspace build fails with "inconsistent vendoring" #1766

False positives ruled out

• A "PRISTINE after re-apply" in the symlink cell came from my own loop: rollback had removed the manifest entry (a v5 known non-bug). After re-staging, it passes.

Probe branches

None pushed. git push --delete of the three stale run-1 branches was denied by the permission classifier again (run 14).

Next

1. Go rollback and remove in a go.work member stay silent about a stale go work vendor modules.txt, so every workspace build fails with "inconsistent vendoring" #1766 in vendored mode (.socket/vendor/golang/, which needs the mock), and with multiple members.
2. Re-check In a go.work workspace where another member requires a newer version, Go apply writes an inert replace for the member's older version, and apply --check and VEX report it patched while the workspace build links the unpatched module #1751/Hosted Go scan in a go.work member pins a version another member outranks #1753/Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549 once Fix Go version gate ignoring go.work members (#1751) #1752/Fix Go patch delivery, audits, and reinstalls #1698 merge; re-check go.work writes once Write shared Go patch replaces into go.work #1764 merges (go.work.sum, rollback byte-for-byte, go work vendor).
3. Hosted takeovers (agent↔hosted↔vendored) and their go.sum state; scan --mode hosted with /patches/batch in the mock.
4. Regression re-checks of the Go apply and vendor break every build in projects with a committed vendor/ directory (modules.txt not synced), while apply --check and VEX report success #343/Go settings written with go env -w are ignored: GOPRIVATE modules are requested from proxy.golang.org, a GOPROXY mirror is bypassed, and a GOMODCACHE cache is not found #344/A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393/Go apply writes its replace into a root go.mod that go.work doesn't use, so the workspace build links the unpatched module while apply, apply --check and VEX all report it patched #458/Running Go apply in a second go.work member writes a second replace for the same module@version, so every workspace build fails with "conflicting replacements" while apply, apply --check and VEX all report success #531 fixes on 1.21 and 1.26.
5. Windows and macOS cells (blocked on the stale probe branches).

[github-actions[bot]]

[agent] 2026-10-28 (run 15): Go modules bug-hunt run

Tested: main b787454 (5.0.1+171, unchanged since run 13), latest release v5.0.1, plus the v5.0.1 npm binary for comparison. Linux only: go 1.24.7, plus the 1.22.12 and 1.26.8 toolchains. Hermetic HTTP GOPROXY and a local Python mock of the patch API (view/<uuid>, plus /patches/package returning either a hosted goproxy override or a vendored granted tarball with sha512).

Re-triage

• Main is unchanged, so nothing was re-run. Go rollback and remove in a go.work member stay silent about a stale go work vendor modules.txt, so every workspace build fails with "inconsistent vendoring" #1766 has draft fix PR Fix stale go.work vendor warning for members (#1766) #1767, In a go.work workspace where another member requires a newer version, Go apply writes an inert replace for the member's older version, and apply --check and VEX report it patched while the workspace build links the unpatched module #1751 has Fix Go version gate ignoring go.work members (#1751) #1752 and Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549 has Fix Go patch delivery, audits, and reinstalls #1698; none has merged yet.

Cells

• agent → hosted (get --mode hosted over a go-patches replace): go.mod/go.sum rewritten, PATCHED on a fresh cache, tidy -diff clean. The agent manifest entry and copy are left behind, so later apply exits 1. The docs say to rollback first, so this is a known non-bug.
• hosted → agent: apply refuses (intended). pass
• hosted → vendored (vendor eject, GOSUMDB=off): PATCHED, vendor --check pass, and vendor --revert restores the upstream go.mod/go.sum byte for byte. Also with a CRLF go.mod/go.sum. pass
• Vendored mode + committed vendor/ (go mod vendor), then vendor --revert, rollback or remove: fail Vendored Go undo (vendor --revert, rollback, remove) stays silent about a stale vendor/modules.txt, so every build fails with "inconsistent vendoring" #1777 (new). All exit 0 with no go_vendor_modules_txt_out_of_sync warning, vendor --check and apply --check exit 0, and the next build fails "inconsistent vendoring". Reproduced on 1.22.12, 1.24.7 (3×) and 1.26.8, and also in go.work (use . and use ./a). The agent-mode control warns correctly. v5.0.1 does the same, so it isn't a regression.

Issues

• Filed Vendored Go undo (vendor --revert, rollback, remove) stays silent about a stale vendor/modules.txt, so every build fails with "inconsistent vendoring" #1777: Vendored Go undo (vendor --revert, rollback, remove) stays silent about a stale vendor/modules.txt, so every build fails with "inconsistent vendoring" #1777

False positives ruled out

• An early "notFound" from get came from my mock caching an empty config, not from the CLI.
• Agent → hosted leftovers: documented to roll back first.

Probe branches

None pushed. The stale run-1 branches are still waiting on a maintainer.

Next

1. Agent → vendored takeover (get --mode vendored over a go-patches replace) and vendored → hosted.
2. Re-check Vendored Go undo (vendor --revert, rollback, remove) stays silent about a stale vendor/modules.txt, so every build fails with "inconsistent vendoring" #1777, Go rollback and remove in a go.work member stay silent about a stale go work vendor modules.txt, so every workspace build fails with "inconsistent vendoring" #1766, In a go.work workspace where another member requires a newer version, Go apply writes an inert replace for the member's older version, and apply --check and VEX report it patched while the workspace build links the unpatched module #1751 and Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549 once Fix stale go.work vendor warning for members (#1766) #1767, Fix Go version gate ignoring go.work members (#1751) #1752 and Fix Go patch delivery, audits, and reinstalls #1698 merge.
3. scan --mode hosted with /patches/batch in the mock, and a %2B purl.
4. Regression re-checks of the Go apply and vendor break every build in projects with a committed vendor/ directory (modules.txt not synced), while apply --check and VEX report success #343/Go settings written with go env -w are ignored: GOPRIVATE modules are requested from proxy.golang.org, a GOPROXY mirror is bypassed, and a GOMODCACHE cache is not found #344/A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393/Go apply writes its replace into a root go.mod that go.work doesn't use, so the workspace build links the unpatched module while apply, apply --check and VEX all report it patched #458/Running Go apply in a second go.work member writes a second replace for the same module@version, so every workspace build fails with "conflicting replacements" while apply, apply --check and VEX all report success #531 fixes on 1.21 and 1.26.
5. Windows and macOS cells (blocked on the stale probe branches).

[github-actions[bot]]

[agent] 2026-10-28 (run 16): Go modules bug-hunt run

Tested: main 103a664 (5.0.1+191), latest release v5.0.1 (npm binary used for comparison). Linux only: go 1.24.7, plus the 1.21.13, 1.22.12 and 1.26.8 toolchains. Hermetic file/HTTP GOPROXY, hand-staged manifest, and a local Python mock of the patch API (hosted view/<uuid> + /patches/package goproxy override; vendored granted tarball with sha512). I also built the head of open PR #1763 (5a2720f) to check one finding against it.

Re-triage

• Since run 15, main merged the fixes for In a go.work workspace where another member requires a newer version, Go apply writes an inert replace for the member's older version, and apply --check and VEX report it patched while the workspace build links the unpatched module #1751 (Fix Go version gate ignoring go.work members (#1751) #1752), Hosted Go scan in a go.work member pins a version another member outranks #1753 (Fix hosted Go pins outranked by go.work members (#1753) #1755), Go rollback and remove in a go.work member stay silent about a stale go work vendor modules.txt, so every workspace build fails with "inconsistent vendoring" #1766 (Fix stale go.work vendor warning for members (#1766) #1767) and Vendored Go undo (vendor --revert, rollback, remove) stays silent about a stale vendor/modules.txt, so every build fails with "inconsistent vendoring" #1777 (Fix vendored Go undo missing modules.txt warning (#1777) #1778). All four issues are closed.
• Go rollback and remove in a go.work member stay silent about a stale go work vendor modules.txt, so every workspace build fails with "inconsistent vendoring" #1766 re-verified on main with two use members (both requiring the patched module, go work vendor): apply in b warns go_vendor_modules_txt_out_of_sync, and rollback in b now warns too. pass
• Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549 is still open. Fix PR Fix Go patch delivery, audits, and reinstalls #1698 hasn't merged, so I didn't re-run it.

Cells

• go.work, another member pulls a newer version transitively (member b requires x, whose go.mod requires upstream v1.1.0; member a requires upstream v1.0.0 directly): on main, apply in a exits 0, --check says in sync and vex attests not_affected, but the workspace build links upstream v1.1.0 (PRISTINE-1.1). b's go.mod/go.sum never mention upstream; only x's go.mod and go.work.sum do. Reproduced on 1.22.12, 1.24.7 (2×) and 1.26.8; v5.0.1 does the same. Control: when b requires upstream v1.1.0 directly, main refuses (the In a go.work workspace where another member requires a newer version, Go apply writes an inert replace for the member's older version, and apply --check and VEX report it patched while the workspace build links the unpatched module #1751 fix works). Not filed: open PR Read Go workspaces the way go builds them #1763 names exactly this case ("Another use member, or a dependency of one, can raise M"), and its head 5a2720f refuses here (apply exits 1, --check fails, VEX withholds). Re-check once Read Go workspaces the way go builds them #1763 merges.
• Agent patch update (re-apply with a new after-blob over an existing go-patches copy): links the new bytes, --check in sync. pass (1.21.13, 1.24.7)
• go 1.21.13 and 1.26.8: plain agent apply; /v2 module and +incompatible (%2B purl) apply, --check, vex, idempotent re-apply, rollback and remove (go.mod/go.sum byte for byte). pass
• Hosted get → rollback with GOSUMDB=off: byte for byte. pass
• Hosted rollback with GONOSUMDB=example.com (env, and via go env -w), with GONOSUMCHECK=1, and with go env -w GOSUMDB=off: restores byte for byte. pass
• Hosted rollback with GOPRIVATE (env or go env -w), GONOPROXY, GOPROXY=off or GOPROXY=direct: exits 1 with a clear reason and a SOCKET_GOPROXY hint, and writes nothing. GOPRIVATE + SOCKET_GOPROXY restores byte for byte. Fails closed: pass
• Agent → vendored takeover (vendor over a go-patches replace): warns about the takeover, PATCHED, vendor --check verified, VEX not_affected, apply reports "1 vendored". vendor --revert restores go.mod/go.sum byte for byte and warns to re-run apply, which restores the agent redirect. pass
• go 1.16.15: blocked. go.dev and dl.google.com are denied by the sandbox proxy, and toolchain modules only exist for 1.21+.

Issues

None filed or commented on. The one failing cell is already covered by open PR #1763.

False positives ruled out

• "Re-apply after rollback does nothing" was my fixture: rollback also removes the blob, and I had restored only the manifest (apply --offline says so). Re-staging the blob passes.
• Transitive go.work selection: a real gap on main, but covered by PR Read Go workspaces the way go builds them #1763 (bar d).

Probe branches

None pushed. git push --delete of the three stale run-1 branches was denied by the permission classifier again (run 16).

Next

1. Once Read Go workspaces the way go builds them #1763 merges: re-run the transitive go.work cell, go.work roots without go.mod, a use member that is the patched module, and hosted go.work/go.work.sum rollback.
2. Re-check Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549 once Fix Go patch delivery, audits, and reinstalls #1698 merges, and hosted pins after tidy once Keep Go hosted pins after go mod tidy drops the zip line #1748 merges.
3. Vendored → hosted takeover. scan --mode hosted with /patches/batch in the mock and a %2B purl.
4. Vendored mode on go 1.21.13 and 1.26.8 (the mock from this run works for both modes).
5. Windows and macOS cells (blocked on the stale probe branches).

[github-actions[bot]]

[agent] 2026-10-28 (run 17): Go modules bug-hunt run

Tested: main a9d2312 (no tag reachable on main; latest release v5.0.1). Linux only, with go 1.24.7 and the 1.21.13 and 1.26.8 toolchains. Hermetic file GOPROXY, hand-staged manifest and blob, and real go run for every cell.

Re-triage

• Read Go workspaces the way go builds them #1763 (the go.work workspace model) and Keep Go hosted pins after go mod tidy drops the zip line #1748 (hosted pins after tidy) have merged.
• The run-16 transitive go.work cell (member b requires x, x requires upstream v1.1.0, member a requires v1.0.0): apply now refuses ("the build selects … v1.1.0 … nothing written"), and --check and vex exit 1. pass
• Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549 is still open (Fix Go patch delivery, audits, and reinstalls #1698 hasn't merged), so I didn't re-run it.

Cells

• GOFLAGS=-modfile=go.alt.mod (env or go env -w): apply exits 0 and writes only go.mod, --check says in sync, and VEX attests not_affected, while go run links PRISTINE. fail Go apply, apply --check and vex ignore GOFLAGS=-modfile, so they report a patch as applied while go builds from another go.mod and links the unpatched module #1799 (1.21.13, 1.24.7 ×2, 1.26.8).
• go.work drift: apply in a, then add member b whose dependency chain (go 1.16, unpruned, two levels deep) raises upstream. --check reports OUT OF SYNC, VEX omits it (go_version_not_selected) and re-apply refuses. pass
• Same chain with x at go 1.21 (pruned): go builds PATCHED, and socket-patch agrees (in sync, not_affected). pass
• go.work replace example.com/x v1.0.0 => example.com/x v1.1.0, where x v1.1.0 raises upstream: apply refuses. pass

Issues

• Filed Go apply, apply --check and vex ignore GOFLAGS=-modfile, so they report a patch as applied while go builds from another go.mod and links the unpatched module #1799 (GOFLAGS -modfile ignored).

False positives ruled out

• None this run. Fixture note: GOFLAGS=-mod=mod must be unset for workspace builds (already a known non-bug).

Next

1. -modfile in hosted and vendored modes (confirm the scope of Go apply, apply --check and vex ignore GOFLAGS=-modfile, so they report a patch as applied while go builds from another go.mod and links the unpatched module #1799 there too), and other GOFLAGS such as -overlay.
2. Hosted go.work rollback and go.work.sum on the new workspace model, and go.work roots without go.mod.
3. Member exclude directives against a transitive raise (go honours members' excludes in workspace mode).
4. Re-check Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549 once Fix Go patch delivery, audits, and reinstalls #1698 merges. Vendored → hosted takeover. Vendored mode on 1.21.13 and 1.26.8.
5. Windows and macOS (blocked on the stale probe branches).

[github-actions[bot]]

[agent] 2026-10-29 (run 18): Go modules bug-hunt run

Tested: main ecd4924 (latest release v5.0.1; npm v5.0.1 binary and a build of 86457da used to bisect). Linux only: go 1.24.7, plus the 1.21.13 and 1.26.8 toolchains. Hermetic file GOPROXY, hand-staged manifest and blob, and real go run in every member.

Re-triage

• Go apply, apply --check and vex ignore GOFLAGS=-modfile, so they report a patch as applied while go builds from another go.mod and links the unpatched module #1799 (GOFLAGS=-modfile) still reproduces on ecd4924 (apply exit 0, --check in sync, go run PRISTINE). Fix PR Fix Go patches ignoring GOFLAGS=-modfile (#1799) #1800 is open. No new information, so I didn't comment.
• Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549: PR Fix Go patch delivery, audits, and reinstalls #1698 is still open. Not re-run.

New on main

#1764 (eb75d20) moves a shared module's replace into go.work when run at the workspace root, and #1765 adds tests for it.

Cells (agent mode, go.work shared replace)

• Root module . + member ./b: apply writes the replace into go.work and mirrors it into the root go.mod; both members build PATCHED; --check in sync; VEX not_affected. pass
• go.work root without go.mod (members ./a, ./b), CRLF go.work with an existing replace ( … // comment ) block: apply appends a CRLF line, both build PATCHED, re-run stable, rollback restores go.work and the members' go.mod/go.sum byte for byte. pass
• remove of the go.work replace (root-module shape): go.work and go.mod are restored byte for byte. pass
• GOWORK=<root>/ci.work beside a different <root>/go.work: apply writes the replace into ./go.work, exits 0 "1 of 1 applied", and both members build PRISTINE. --check and vex fail closed. fail Go apply writes the shared replace into ./go.work when GOWORK names another file in the same directory, reports success, and the workspace builds unpatched #1810 (1.21.13, 1.24.7 ×3, 1.26.8). With only ci.work present, apply fails with "read ./go.work: No such file". v5.0.1 and 86457da refuse, so the first bad commit is eb75d20 (Write shared Go patch replaces into go.work #1764).

Issues

• Filed Go apply writes the shared replace into ./go.work when GOWORK names another file in the same directory, reports success, and the workspace builds unpatched #1810.

False positives ruled out

• With a root go.mod that is a use member, the same GOWORK case builds PATCHED through the mirrored go.mod replace (go reads member replaces). It's only a stray write to the unused go.work, so the issue is filed on the no-root-go.mod shape.

Probe branches

None. The stale run-1 branches are still waiting for a maintainer to delete them.

Next

1. Go apply writes the shared replace into ./go.work when GOWORK names another file in the same directory, reports success, and the workspace builds unpatched #1810 in vendor and hosted modes, and rollback/remove with a GOWORK-named file (drop_replace_entry hardcodes go.work).
2. -modfile (Go apply, apply --check and vex ignore GOFLAGS=-modfile, so they report a patch as applied while go builds from another go.mod and links the unpatched module #1799) in hosted and vendored modes, plus -overlay.
3. Shared go.work replace: apply from a member after the root wrote a go.work replace; a vendored ↔ agent takeover in go.work; go.work.sum under hosted shared pins.
4. Re-check Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549 once Fix Go patch delivery, audits, and reinstalls #1698 merges. Vendored mode on 1.21.13 and 1.26.8.
5. Windows and macOS (blocked on the stale probe branches).

[github-actions[bot]]

[agent] 2026-10-29 (run 19): Go modules bug-hunt run

Tested: main ecd4924 (unchanged since run 18; latest release v5.0.1, npm binary used as the release comparison). Linux only: go 1.24.7, plus the 1.21.13 and 1.26.8 toolchains. Hermetic file GOPROXY, hand-staged manifest and blob, and real go run / go build -mod=readonly.

Re-triage

Main hasn't moved since run 18, so nothing to re-check. #1810 (fix PR #1812), #1799 (PR #1800) and #549 (PR #1698) are still open. I read #1812's diff: it makes a GOWORK file not named go.work fall back to the go.mod host and refuses a root with no go.mod, so I didn't re-probe GOWORK cells this run.

Cells

• Patched module reached only as a replace target (replace other.com/fork [v1.0.0] => example.com/upstream v1.0.0, module mode): apply exits 0 and writes replace example.com/upstream v1.0.0 => ./.socket/go-patches/…, which go ignores (replaces don't chain). apply --check says in sync and vex says not_affected, while the build is PRISTINE. fail Go apply, apply --check and vex treat a module that is only another module's replace target as built, so the patch is reported applied and attested while go builds the unpatched code #1823: go directive 1.16 and 1.21, versioned and versionless replace, go 1.21.13 / 1.24.7 / 1.26.8, and v5.0.1 too (not a regression). Cause: go_build_list::select counts the target's go.sum zip line as "selected".
• Same shape as a go.work member (apply from the member or from the root): refuses with "not in this project's build graph". pass

Issues

• Filed Go apply, apply --check and vex treat a module that is only another module's replace target as built, so the patch is reported applied and attested while go builds the unpatched code #1823.

False positives ruled out

• None new.

Probe branches

None. git push --delete of the stale run-1 branches was denied by the permission classifier again.

Next

1. Go apply, apply --check and vex treat a module that is only another module's replace target as built, so the patch is reported applied and attested while go builds the unpatched code #1823 in vendored and hosted modes (both share go_build_list::select); re-check once a fix lands.
2. GOWORK=<dir>/ci.work: go reads ci.work.sum, but go_workspace::load and the hosted engine always read go.work.sum. Check whether hosted/vex pin reading is affected after Fix Go replace written to unused go.work (#1810) #1812 merges.
3. -modfile (Go apply, apply --check and vex ignore GOFLAGS=-modfile, so they report a patch as applied while go builds from another go.mod and links the unpatched module #1799) in hosted and vendored modes, plus -overlay.
4. Re-check Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549 once Fix Go patch delivery, audits, and reinstalls #1698 merges. Vendored mode on 1.21.13 and 1.26.8.
5. Windows and macOS (blocked on the stale probe branches).

[github-actions[bot]]

[agent] Janitor: ledger drift. #1810 was closed as completed at 2026-10-29 13:31Z by #1812 (dad6408: the shared replace goes to the file GOWORK names), and #1823 was closed as completed at 13:31Z by #1824 (d3d3154: a module that is only a replace target is no longer treated as built). The 1.21.13 and 1.26.3 rows still mark GOWORK=<other root file> fail #1810, and to-do item 2 (#1823 in vendored/hosted, #1810 rollback/remove) is now due for a re-check.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-10-29 (run 20): Go modules bug-hunt run

Tested: main c07af61 (no tag reachable; latest release v5.0.1, npm v5.0.1 binary used as the release comparison). Since run 19, #1800 (-modfile, #1799), #1812 (GOWORK file, #1810) and #1824 (replace target, #1823) have merged. Linux only: go 1.24.7, plus the 1.21.13 and 1.26.8 toolchains. Hermetic file GOPROXY, hand-staged manifest and blob, and real go run / go build -mod=readonly.

Re-triage

• Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549 is still open and still reproduces on c07af61: apply, then go mod tidy, then rollback exits 0 with no warning, and the next -mod=readonly build fails with "missing go.sum entry". The fix PR Fix Go patch delivery, audits, and reinstalls #1698 is still open and doesn't conflict with this. No comment posted (nothing new).
• No other open pm:go issues.

Cells

• Go apply, apply --check and vex treat a module that is only another module's replace target as built, so the patch is reported applied and attested while go builds the unpatched code #1823 shape with the fork required only transitively (go 1.16 directive, mid requires other.com/fork, root replace other.com/fork [v1.0.0] => example.com/upstream v1.0.0): apply exit 0 and writes an inert replace, --check exit 0, vex not_affected, build PRISTINE. fail Go apply, apply --check and vex still treat a replace-target module as built when the replaced fork is required only by a dependency (go 1.16 module), so the patch is attested while the build stays unpatched #1840 on go 1.21.13, 1.24.7 and 1.26.8, versionless and versioned replace. v5.0.1 does the same (it's a gap in Fix Go replace-target patches reported applied (#1823) #1824, not a regression). Cause: replaced_module (go_build_list.rs:156) only honours a fork replace when the root go.mod requires the fork.
• Same transitive shape with go.work use .: apply refuses (pass; the message says "no go.sum has a zip line", which is slightly off, but it fails closed).
• Fork replace in go.work (replace other.com/fork => upstream v1.0.0): apply refuses. pass
• -modfile via go env -w GOFLAGS (GOENV file): apply refuses with a go env -u hint. After an earlier apply, --check exits 1 and vex omits the patch. pass (Go apply, apply --check and vex ignore GOFLAGS=-modfile, so they report a patch as applied while go builds from another go.mod and links the unpatched module #1799 fix verified)
• GOWORK=<root>/ci.work (use .): apply writes go.mod, PATCHED, check/vex OK, rollback and remove restore go.mod byte for byte. pass (Go apply writes the shared replace into ./go.work when GOWORK names another file in the same directory, reports success, and the workspace builds unpatched #1810 fix verified)
• ci.work user replace for the patched module: apply refuses, and a replace added after apply makes --check exit 1. pass
• Repo e2e suites (e2e_golang_build, e2e_golang_hosted_build, e2e_vendor_golang_build; agent, hosted and vendored, including the Go apply, apply --check and vex treat a module that is only another module's replace target as built, so the patch is reported applied and attested while go builds the unpatched code #1823/Go apply, apply --check and vex ignore GOFLAGS=-modfile, so they report a patch as applied while go builds from another go.mod and links the unpatched module #1799 regressions) under go 1.21.13 and 1.26.8: all pass, except three *_needs_go_work_vendor_in_workspace tests on 1.21.13. Those fail in fixture setup because go work vendor is go ≥ 1.22. Not a product bug.

Issues

• Filed Go apply, apply --check and vex still treat a replace-target module as built when the replaced fork is required only by a dependency (go 1.16 module), so the patch is attested while the build stays unpatched #1840.

False positives ruled out

• The 1.21.13 go work vendor test failures above (a toolchain limit).

Probe branches

None. git push --delete of the three stale run-1 branches was denied by the permission classifier again, so no new probes.

Next

1. Go apply, apply --check and vex still treat a replace-target module as built when the replaced fork is required only by a dependency (go 1.16 module), so the patch is attested while the build stays unpatched #1840 in hosted (get --mode hosted) and vendored modes with the mock API (they share select).
2. Re-check Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549 once Fix Go patch delivery, audits, and reinstalls #1698 merges.
3. Unpruned (go 1.16) graphs elsewhere in go_build_list: exclude, and versioned fork replaces at a version MVS raises above the root's.
4. -overlay in GOFLAGS, plus hosted/vendored -modfile.
5. Windows and macOS (blocked on the stale probe branches).

[github-actions[bot]]

[agent] 2026-10-29 (run 21): Go modules bug-hunt run

Tested: main c8e26f6 (only a CI change since run 20's c07af61; no tag reachable; latest release v5.0.1, npm binary used for comparison). Linux only: go 1.24.7, plus the 1.21.13 and 1.26.8 toolchains. Hermetic file GOPROXY, hand-staged manifest and blob, and real go run / go list -m with -mod=readonly.

Re-triage

• Go apply, apply --check and vex still treat a replace-target module as built when the replaced fork is required only by a dependency (go 1.16 module), so the patch is attested while the build stays unpatched #1840: the fix PR Fix Go replace target missed in go 1.16 graphs (#1840) #1843 is open and not merged. Nothing new, no comment.
• Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549: still open, and the fix PR Fix Go patch delivery, audits, and reinstalls #1698 is still open. Main has had no Go change since run 20, so no re-run.

Cells

• Unpruned graph (go 1.16 directive), stale go.sum zip line after a go get downgrade below the patched version (require v1.0.0 → go get @v0.9.0, patch for v1.0.0): apply exit 0 applied, inert replace, --check 0, vex not_affected, build OLDER (v0.9.0). fail On a go 1.16 go.mod, Go apply, apply --check and vex trust a stale go.sum zip line left by a downgrade, so they report an inert replace as applied (or refuse a selected version) #1862 on go 1.21.13, 1.24.7 and 1.26.8, on main and v5.0.1, and on the Fix Go replace target missed in go 1.16 graphs (#1840) #1843 head too.
• Same, downgrade to the patched version (require v1.1.0 → go get @v1.0.0): apply exit 1, falsely claiming the build selects v1.1.0. fail On a go 1.16 go.mod, Go apply, apply --check and vex trust a stale go.sum zip line left by a downgrade, so they report an inert replace as applied (or refuse a selected version) #1862 (same root cause: go_build_list.rs:123, highest zip line wins).
• Same two shapes with a go 1.21 directive: correct (it refuses, or trusts require). pass

Issues

• Filed On a go 1.16 go.mod, Go apply, apply --check and vex trust a stale go.sum zip line left by a downgrade, so they report an inert replace as applied (or refuse a selected version) #1862.

False positives ruled out

• None new. After go mod tidy, both On a go 1.16 go.mod, Go apply, apply --check and vex trust a stale go.sum zip line left by a downgrade, so they report an inert replace as applied (or refuse a selected version) #1862 shapes behave correctly, which is expected.

Probe branches

None (the stale run-1 branches still block new probes; see backlog item 1).

Next

1. On a go 1.16 go.mod, Go apply, apply --check and vex trust a stale go.sum zip line left by a downgrade, so they report an inert replace as applied (or refuse a selected version) #1862 in hosted (get --mode hosted) and vendored modes (same select).
2. Unpruned exclude shapes, and a versioned fork replace at a version MVS raises.
3. Go apply, apply --check and vex still treat a replace-target module as built when the replaced fork is required only by a dependency (go 1.16 module), so the patch is attested while the build stays unpatched #1840 hosted/vendored, then re-check once Fix Go replace target missed in go 1.16 graphs (#1840) #1843 merges; re-check Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549 once Fix Go patch delivery, audits, and reinstalls #1698 merges.
4. -overlay in GOFLAGS; hosted/vendored -modfile.
5. Windows and macOS (blocked on the stale probe branches).

[github-actions[bot]]

[agent] 2026-10-30 (run 22): Go modules bug-hunt run

Tested: main 5ca5623 (the only change since run 21's c8e26f6 is a Gradle fix; no Go change). Latest release v5.0.1. Linux only, go 1.24.7. Hermetic file GOPROXY, hand-staged manifest and blob, real go run / go list -m all with -mod=readonly. Hosted cells ran the rewriter (rewrite_registry_redirect) in-process from a scratch test (not committed), and the #1843 head 4e9eebf was built for comparison.

Re-triage

• Go apply, apply --check and vex still treat a replace-target module as built when the replaced fork is required only by a dependency (go 1.16 module), so the patch is attested while the build stays unpatched #1840, On a go 1.16 go.mod, Go apply, apply --check and vex trust a stale go.sum zip line left by a downgrade, so they report an inert replace as applied (or refuse a selected version) #1862 and Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549: no fix merged (Fix Go replace target missed in go 1.16 graphs (#1840) #1843 and Fix Go patch delivery, audits, and reinstalls #1698 are still open), and main has no Go change. No re-run and no comment beyond the Go apply, apply --check and vex still treat a replace-target module as built when the replaced fork is required only by a dependency (go 1.16 module), so the patch is attested while the build stays unpatched #1840 note below.

Cells

• Go apply, apply --check and vex still treat a replace-target module as built when the replaced fork is required only by a dependency (go 1.16 module), so the patch is attested while the build stays unpatched #1840 shape in hosted mode (go 1.16 directive, fork required only by a dependency, replace fork => upstream v1.0.0): the rewriter confirms the redirect with no warning, writes an inert replace upstream v1.0.0 => gopatch…, and prunes the upstream go.sum pair that the fork replacement needs. Day-1 go run then fails ("missing go.sum entry"). After go mod tidy the build links PRISTINE while hosted mode still counts the redirect as landed. fail Go apply, apply --check and vex still treat a replace-target module as built when the replaced fork is required only by a dependency (go 1.16 module), so the patch is attested while the build stays unpatched #1840 (hosted; reproduced twice on main). A go 1.21 directive refuses (pass). The Fix Go replace target missed in go 1.16 graphs (#1840) #1843 head refuses (fixed there). Commented on Go apply, apply --check and vex still treat a replace-target module as built when the replaced fork is required only by a dependency (go 1.16 module), so the patch is attested while the build stays unpatched #1840.
• On a go 1.16 go.mod, Go apply, apply --check and vex trust a stale go.sum zip line left by a downgrade, so they report an inert replace as applied (or refuse a selected version) #1862 in hosted mode (go 1.16, go get downgrade below the patched version): pass. The hosted rewrite prunes upstream's go.sum pair, so go get @v0.9.0 leaves no stale v1.0.0 zip line, and select sees v0.9.0 → inert. (Checked against the real go.sum after the downgrade.)
• No go.sum (only local directory replaces), shared cache with other modules: scan sends every cached module to /patch/batch (scannedPackages: 2 for 2 unrelated versions). go 1.21: apply refuses (partialFailure). go 1.16: apply reports applied, apply --check says in sync, and vex attests not_affected for a module that's absent from the build. The same go 1.16 result follows from dropping the dependency and tidying. Covered by tracking issue Tracking: scope project-mode cache crawls to what the project resolves #595; commented there. Not filed separately (nothing unpatched ships).
• Duplicate require lines for one module (pruned graph): go refuses under -mod=readonly ("updates to go.mod needed"). Not reachable, so known non-bug.
• Unpruned exclude after go mod tidy (dep requires an excluded higher version): go.sum holds only the selected version, so select is correct. pass. Without a tidy, a stale zip line for the excluded version is the On a go 1.16 go.mod, Go apply, apply --check and vex trust a stale go.sum zip line left by a downgrade, so they report an inert replace as applied (or refuse a selected version) #1862 mechanism (false refusal direction).
• User directory replace of a different version (replace upstream v1.1.0 => ./local, require v1.0.0): apply writes its own versioned replace, PATCHED. pass

Issues

• Commented: Go apply, apply --check and vex still treat a replace-target module as built when the replaced fork is required only by a dependency (go 1.16 module), so the patch is attested while the build stays unpatched #1840 (hosted mode + build break), Tracking: scope project-mode cache crawls to what the project resolves #595 (Go no-go.sum crawl).
• Filed: none.

False positives ruled out

• Duplicate require lines (go refuses them itself).
• Hosted On a go 1.16 go.mod, Go apply, apply --check and vex trust a stale go.sum zip line left by a downgrade, so they report an inert replace as applied (or refuse a selected version) #1862 (the rewriter's go.sum pruning removes the stale evidence).

Probe branches

None. git push --delete of the three stale run-1 probe branches was denied by the permission classifier again, so no new probes.

Next

1. Go apply, apply --check and vex still treat a replace-target module as built when the replaced fork is required only by a dependency (go 1.16 module), so the patch is attested while the build stays unpatched #1840 / On a go 1.16 go.mod, Go apply, apply --check and vex trust a stale go.sum zip line left by a downgrade, so they report an inert replace as applied (or refuse a selected version) #1862 in vendored mode (same select), and re-check Go apply, apply --check and vex still treat a replace-target module as built when the replaced fork is required only by a dependency (go 1.16 module), so the patch is attested while the build stays unpatched #1840 (agent + hosted) once Fix Go replace target missed in go 1.16 graphs (#1840) #1843 merges.
2. Unpruned versioned fork replace at a version MVS raises; -overlay in GOFLAGS; hosted/vendored -modfile.
3. Re-check Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549 once Fix Go patch delivery, audits, and reinstalls #1698 merges.
4. macOS/Windows: blocked until a maintainer deletes the stale probe branches.