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-03 (run 12), main 045d7ec (unchanged since run 10; CLI 4.0.0), latest release 4.0.0 (previous 3.3.0). Run 12 filed #682 (a hosted patch update leaves the superseded gopatch go.sum lines behind, so tidy isn't a no-op), passed hosted /v2, +incompatible, pseudo-version and indirect-dep cells on 1.21/1.24/1.26, and re-confirmed #391 and #393 on 1.21.13 and 1.26.8. Run 11 confirmed #618 in hosted mode (1.21/1.22/1.24/1.26), passed #531's shape in hosted mode, and covered global -g on Linux 1.22/1.26. Run 10 filed #618 (a patch that edits the module's own go.mod breaks the default build) and re-confirmed #484 and #343. Run 9: #549 and #531 confirmed in vendored mode; a reusable vendored mock is described in the run-9 entry.

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, 2 members each patched	Hosted	tidy → rollback/remove (go.sum)	GOWORK=off / GOWORK=	Patch edits module's own go.mod (bump/add require)	Hosted patch update (new uuid / republish)	Hosted /v2, +incompatible, pseudo, indirect
Linux	1.16.15	untested	untested	untested	untested	fail #343	fail #344	untested	untested	n/a (no go.work)	n/a	n/a (no go.work)	untested	untested	n/a	n/a (no proxy toolchain)	untested	untested
Linux	1.21.13	pass (probe)	untested	untested	pass (probe)	fail #343	fail #344	fail #391 (agent)	untested	fail #393 (agent)	untested	untested	untested	untested	untested	fail #618 (agent)	fail #682	pass
Linux	1.24.7 (+1.22.12)	pass	pass	apply/check/rollback pass; vex fail #484 (agent only; vendored + takeover pass)	pass	fail #343 (agent, vendored, hosted)	fail #344	fail #391 (agent) / vendored pass / hosted pass (vex exits 2)	fail #392 (agent + vendored), fail #509 (hosted, go 1.16)	fail #393 (agent, vendored, hosted)	fail #458 (agent, vendored, hosted)	fail #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 fail #393	fail #618 (agent 1.22 + 1.24, vendored 1.24, hosted 1.21/1.22/1.24/1.26)	fail #682	pass
Linux	1.26.3	pass (probe)	untested	untested	pass (probe)	fail #343	fail #344	fail #391 (agent (1.26.8))	untested	fail #393 (agent (1.26.8))	fail #458 (agent, 1.26.8)	fail #531 (agent, 1.26.8)	untested	fail #549 (agent, 1.26.8)	untested	fail #618 (agent, 1.26.8)	fail #682 (1.26.8)	pass (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	fail #343	fail #344	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested
Windows	1.16.15 / 1.21.13 / 1.26.3	fail #346	blocked by #346	blocked by #346	fail #346	blocked by #346	fail #344	blocked by #346	blocked by #346	blocked by #346	blocked by #346	blocked by #346	untested	blocked by #346	untested	blocked by #346	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)	fail #422	pass	fail #422 (attests stale binary); pass after cache revert	pass (loud)	fail #344 (silent 0 packages)
Linux	1.25.1	untested	untested	pass (cache)	fail #422	untested	fail #422	untested	untested
Linux	1.22.12 / 1.26.8	Go hit crawled (report fields untested: mock lacks /patches/batch)	untested	pass (cache)	fail #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 blocked by #346	untested	untested	untested	untested	untested

Backlog

0. Maintainer request (partly covered, keep it on top): global (-g) mode on macOS and Windows. Linux 1.22 / 1.24 / 1.25 / 1.26 is done (see the table and 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). 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 is denied by the permission classifier (runs 6 and 11). Until they're gone, no new probe branches get pushed.
2. Hosted takeovers (agent→hosted, hosted→agent/vendored) and their go.sum state. Also scan --mode hosted (crawl-driven, with /patches/batch added to the mock) with a %2B purl, and 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. Hosted /v2 and +incompatible passed in run 12, but the +incompatible spelling vX-socketpatch.N+incompatible is still unconfirmed against the service.
3. Global as non-root on 1.22 / 1.26 (unwritable prefix); --global-prefix shapes (GOPATH root, multi-entry GOPATH).
4. Hosted with GOPRIVATE / GONOSUMDB / GOFLAGS=-mod=vendor, go.work.sum in hosted workspace mode, and a CRLF go.sum in vendored mode.
5. 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 on Linux via the proxy toolchains.
6. 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, including a HOME vs USERPROFILE mismatch (go_crawler.rs::get_gomodcache prefers HOME, but Go on Windows uses USERPROFILE).
7. A custom GOSUMDB (a mirror or private sumdb) in hosted rollback: gosumdb_base treats any value other than off as sum.golang.org.

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.

[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.