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-02 (run 7), main 61cfb9b (no Go code changes since 2463257; CLI still reports 4.0.0), latest release 4.0.0 (previous 3.3.0). Run 7: #344 still reproduces; filed #531 (per-member apply in a go.work breaks the workspace build). Run 6 on 61cfb9b: #392 and #393 still reproduce, and #343 / #458 reproduce in hosted mode.

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
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
Linux	1.21.13	pass (probe)	untested	untested	pass (probe)	fail #343	fail #344	untested	untested	untested	untested	untested	untested
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/hosted untested)	plain get/day-2/idempotent/rollback/CRLF pass; +incompatible blocked (server contract)
Linux	1.26.3	pass (probe)	untested	untested	pass (probe)	fail #343	fail #344	untested	untested	untested	fail #458 (agent, 1.26.8)	fail #531 (agent, 1.26.8)	untested
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
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

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.16 / 1.21 / 1.26	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 and across go 1.21 / 1.26. Linux 1.24/1.25 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). Linux 1.22.12 / 1.26.8 toolchains can be fetched from proxy.golang.org (golang.org/toolchain/@v/v0.0.1-go<ver>.linux-amd64.zip); dl.google.com (needed for 1.16–1.20) is blocked. The full checklist is in the 20261001T040000Z entry.
   0b. 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 (mock patch service) and hosted mode.
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 fails (runs 4–5) or is denied by the permission classifier (run 6). Until they're gone, no new probe branches get pushed.
2. Hosted +incompatible and /v2+ modules (needs the gopatch version spelling the service uses for +incompatible), and scan --mode hosted with a %2B purl.
3. Vendored and hosted with GOPRIVATE / GONOSUMDB / GOFLAGS=-mod=vendor, go.work.sum, and a CRLF go.sum in vendored mode.
4. --global-prefix shapes: GOPATH root instead of pkg/mod, multi-entry GOPATH, empty or relative GOMODCACHE.
5. GOWORK=<path> / GOWORK=off (socket-patch never reads GOWORK).
6. 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.
7. 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.

Known non-bugs

• 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).

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