Bug hunt ledger: Go modules #317

[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 [email protected] after apply): apply --check flags it (exit 1), but vex still attests not_affected for [email protected] (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.

[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 [email protected] / @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.

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

[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/[email protected] that depends on example.com/[email protected], 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.