Bug hunt ledger: Go modules #317

Mikola Lysenko (mikolalysenko) · 2026-09-30T14:23:52Z

Mikola Lysenko (mikolalysenko)
Sep 30, 2026
Maintainer

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

Last updated: 2026-10-28 (run 16), main 103a664 (5.0.1+191), latest release v5.0.1. Main has merged the fixes for #1751, #1753, #1766 and #1777 (all closed); #1766 was re-verified with two members in run 16. Run 16 found that in a go.work, a member that pulls a newer version transitively (through a dependency's go.mod) still makes apply/--check/VEX report an inert replace as patched. Not filed: open PR #1763 covers it, and its head refuses correctly. Re-check when it merges. #549 is still open (PR #1698 pending). Runs 14 and 15 filed #1766 and #1777 (both now fixed). Between runs 12 and 13, fixes closed #343, #344, #346, #391, #392, #393, #422, #458, #484, #509, #531, #618 and #682. Cells marked "fixed #N" haven't been re-verified unless they say "pass (run N)".

Coverage matrix

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

OS	go	Agent `apply` (plain)	Agent edge shapes (uppercase, /v2, pseudo, gopkg.in, CRLF, replace block/exclude/retract/toolchain, godebug/tool, nested module paths, new-file patches, tidy, idempotent, rollback, remove)	`+incompatible` / no-go.mod module (`%2B` key)	Vendored `vendor` (plain)	Committed `vendor/` dir	`go env -w` settings	Upgrade drift → VEX	Transitive / unselected version	go.work user replace	go.work without `use .`	go.work, 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	go.work members require different versions	`go work vendor` (non-root member)
Linux	1.16.15	blocked (no 1.16 download: go.dev/dl.google.com denied)	blocked	blocked	untested	fixed #343	fixed #344	untested	untested	n/a (no go.work)	n/a	n/a (no go.work)	untested	untested	n/a	n/a (no proxy toolchain)	untested	untested	n/a (no go.work)	n/a
Linux	1.21.13	pass (run 16; + patch update)	/v2, rollback, remove pass (run 16); rest untested	pass (run 16: apply/check/vex/rollback/remove)	pass (probe)	fixed #343	fixed #344	fixed #391 (agent)	untested	fixed #393 (agent)	untested	untested	untested	untested	untested	fixed #618 (agent)	fixed #682	pass	untested	n/a (go < 1.22)
Linux	1.24.7 (+1.22.12)	pass (run 13; CRLF go.mod/go.sum pass)	pass	apply/check/rollback pass; vex fixed #484 (agent only; vendored + takeover pass)	pass	fixed #343 (agent, vendored, hosted apply/rollback); vendored undo fixed #1777 (not re-run)	fixed #344	fixed #391 (agent) / vendored pass / hosted pass (vex exits 2)	fixed #392 (agent + vendored), fixed #509 (hosted, go 1.16)	fixed #393 (agent, vendored, hosted)	fixed #458 (agent, vendored, hosted)	fixed #531 (agent, 1.22 + 1.24; vendored 1.24); hosted pass (identical module-path replaces)	plain get/day-2/idempotent/rollback/CRLF pass; `+incompatible` blocked (server contract)	fail #549 (agent, 1.22 + 1.24; vendored 1.24); hosted pass	off pass; `<path>` pass; `<path>` + user replace fixed #393	fixed #618 (agent 1.22 + 1.24, vendored 1.24, hosted 1.21/1.22/1.24/1.26)	fixed #682	pass	fixed #1751 (direct require, run 16); transitive (via a dep's go.mod) fail on main, covered by open PR #1763 (1.22.12, 1.24.7, 1.26.8)	apply pass; rollback/remove fixed #1766 (pass run 16, 2 members, 1.24.7)
Linux	1.26.3	pass (probe)	/v2, rollback, remove pass (1.26.8, run 16)	pass (1.26.8, run 16)	pass (probe)	fixed #343	fixed #344	fixed #391 (agent (1.26.8))	untested	fixed #393 (agent (1.26.8))	fixed #458 (agent, 1.26.8)	fixed #531 (agent, 1.26.8)	untested	fail #549 (agent, 1.26.8)	untested	fixed #618 (agent, 1.26.8)	fixed #682 (1.26.8)	pass (1.26.8)	fixed #1751; transitive fail, PR #1763 (1.26.8)	rollback/remove fixed #1766 (not re-run on 1.26)
macOS	1.24.13 / 1.26.3	untested (plain; the vendor/-dir cell got as far as apply exit 0)	untested	untested	untested	fixed #343	fixed #344	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested
Windows	1.16.15 / 1.21.13 / 1.26.3	fixed #346	untested (#346 fixed)	untested (#346 fixed)	fixed #346	untested (#346 fixed)	fixed #344	untested (#346 fixed)	untested (#346 fixed)	untested (#346 fixed)	untested (#346 fixed)	untested (#346 fixed)	untested	untested (#346 fixed)	untested	untested (#346 fixed)	untested	untested	untested	untested

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

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

Backlog

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

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

Maintainer request (partly covered, keep it on top): global (-g) mode on macOS and Windows. Linux is done (Global Go patching (-g) reports success and VEX attests not_affected, but tools already built with go install keep running the unpatched code, and nothing tells the user to reinstall them #422 is fixed; its warning passed in run 13). The full checklist is in the 20261001T040000Z entry.
Needs a maintainer: delete the stale probe branches bughunt/go/20260930-goenv-vendor, bughunt/go/20260930-windows-apply and bughunt/go/20260930-windows-bisect. git push --delete from the sandbox was denied by the permission classifier again in run 16. Until they're gone, no new probe branches get pushed.
Once Read Go workspaces the way go builds them #1763 (go.work model) merges: the transitive go.work cell (run 16 repro: member b requires x, x requires upstream v1.1.0, member a requires v1.0.0), go.work roots without go.mod, a use member that is the patched module, and hosted go.work/go.work.sum rollback.
Re-check Agent-mode Go rollback and remove after go mod tidy drop the replace but not restore the module's go.sum lines, so the next default go build fails with "missing go.sum entry" while rollback exits 0 with no warning #549 once Fix Go patch delivery, audits, and reinstalls #1698 merges, and hosted pins after tidy once Keep Go hosted pins after go mod tidy drops the zip line #1748 merges.
Vendored → hosted takeover. scan --mode hosted with /patches/batch in the mock and a %2B purl. Vendored mode on 1.21.13 and 1.26.8.
Regression re-checks of the Go apply and vendor break every build in projects with a committed vendor/ directory (modules.txt not synced), while apply --check and VEX report success #343/Go settings written with go env -w are ignored: GOPRIVATE modules are requested from proxy.golang.org, a GOPROXY mirror is bypassed, and a GOMODCACHE cache is not found #344/A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393/Go apply writes its replace into a root go.mod that go.work doesn't use, so the workspace build links the unpatched module while apply, apply --check and VEX all report it patched #458/Running Go apply in a second go.work member writes a second replace for the same module@version, so every workspace build fails with "conflicting replacements" while apply, apply --check and VEX all report success #531 fixes on 1.21 and 1.26, and of Vendored Go undo (vendor --revert, rollback, remove) stays silent about a stale vendor/modules.txt, so every build fails with "inconsistent vendoring" #1777 on 1.26.
go.work.sum in hosted workspace mode; a CRLF go.sum in vendored mode.
Windows HOME vs USERPROFILE mismatch (go_crawler.rs::get_gomodcache).

Known non-bugs

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

2026-09-30T17:26:37Z

github-actions[bot]
Bot Sep 30, 2026

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

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.
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").
Hosted mode (wiremock harness from e2e_golang_hosted_build.rs) × committed vendor/, +incompatible, /v2 originals, and CRLF / BOM go.sum.
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.
GOFLAGS=-mod=vendor / -mod=readonly in the env or GOENV, and retracted versions.

0 replies

2026-09-30T22:51:36Z

github-actions[bot]
Bot Sep 30, 2026

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

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.
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.
GOFLAGS=-mod=vendor in the env or GOENV, and a committed vendor/ together with go.work (go work vendor, 1.22+).
go.work root without a root go.mod: decide whether it's a limitation or a bug (still "matched no installed package").
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.

0 replies

2026-10-01T03:26:51Z

github-actions[bot]
Bot Oct 1, 2026

[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):

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

0 replies

2026-10-01T04:55:48Z

github-actions[bot]
Bot Oct 1, 2026

[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

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.

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).
--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).
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.
GOFLAGS=-mod=vendor in env/GOENV, and go work vendor with a committed vendor/.
go.work root without a root go.mod (still "matched no installed package"): limitation or bug.

0 replies

2026-10-01T10:53:46Z

github-actions[bot]
Bot Oct 1, 2026

[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

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.

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.
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.
--global-prefix shapes: GOPATH root, multi-entry GOPATH, empty or relative GOMODCACHE.
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).
Nested module (apply run from a subdirectory with its own go.mod inside a parent module).

0 replies

2026-10-01T16:52:21Z

github-actions[bot]
Bot Oct 1, 2026

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

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.
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.
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.
--global-prefix shapes: GOPATH root, multi-entry GOPATH, empty or relative GOMODCACHE.
GOWORK=<path> / GOWORK=off, and a nested module inside a parent module.

0 replies

2026-10-01T23:00:54Z

github-actions[bot]
Bot Oct 1, 2026

[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

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.

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.
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.
Vendored and hosted with GOPRIVATE / GONOSUMDB / GOFLAGS=-mod=vendor, a go.work.sum, and a CRLF go.sum in vendored mode.
--global-prefix shapes: GOPATH root, multi-entry GOPATH, empty or relative GOMODCACHE.
GOWORK=<path> / GOWORK=off.

0 replies

2026-10-02T04:53:07Z

github-actions[bot]
Bot Oct 2, 2026

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

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).
Global -g on macOS/Windows (maintainer request; blocked on probe branches) and on Linux 1.22 / 1.26.
Hosted +incompatible and /v2+, and scan --mode hosted with a %2B purl.
GOPRIVATE / GONOSUMDB / GOFLAGS=-mod=vendor in vendored and hosted mode, plus go.work.sum.
GOWORK=<path> / GOWORK=off, and --global-prefix shapes.

0 replies

2026-10-02T10:53:25Z

github-actions[bot]
Bot Oct 2, 2026

[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

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.

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.
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.
Global -g on macOS/Windows (maintainer request; blocked on probe branches) and on Linux 1.22 / 1.26.
Hosted +incompatible / /v2+, and scan --mode hosted with a %2B purl.
GOPRIVATE / GONOSUMDB / GOFLAGS=-mod=vendor in vendored and hosted mode, plus go.work.sum; empty or relative GOMODCACHE.

0 replies

2026-10-02T16:52:39Z

github-actions[bot]
Bot Oct 2, 2026

[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

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

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.

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.
Global -g on Linux 1.22 / 1.26 via proxy toolchains; macOS/Windows still blocked on probe branches.
Hosted +incompatible / /v2+, and scan --mode hosted with a %2B purl.
GOPRIVATE / GONOSUMDB / GOFLAGS=-mod=vendor in hosted mode; go.work.sum in hosted workspace mode.
A patch that edits the module's own go.mod (changes requirements): what the agent copy does to the consumer graph and go.sum.

0 replies

2026-10-02T22:54:43Z

github-actions[bot]
Bot Oct 2, 2026

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

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).
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.
Global -g on Linux 1.22 / 1.26 via proxy toolchains (downloads work: GOTOOLCHAIN=go1.26.8 GOPROXY=https://proxy.golang.org go version).
Hosted +incompatible / /v2+, and scan --mode hosted with a %2B purl.
GOPRIVATE / GONOSUMDB / GOFLAGS=-mod=vendor in hosted mode; go.work.sum in hosted workspace mode.

0 replies

2026-10-03T04:53:28Z

github-actions[bot]
Bot Oct 3, 2026

[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

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.

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.
scan -g against a mock with /patches/batch, to check the report and JSON fields for a Go global hit.
Global -g as non-root on 1.22 / 1.26 (unwritable prefix), and the --global-prefix shapes (GOPATH root, multi-entry GOPATH).
GOPRIVATE / GONOSUMDB / GOFLAGS=-mod=vendor in hosted mode, and go.work.sum in hosted workspace mode.
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.

0 replies

2026-10-03T11:06:04Z

github-actions[bot]
Bot Oct 3, 2026

[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

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.

Hosted takeovers: agent→hosted and hosted→agent/vendored, including the go.sum state after each.
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.
Global -g as non-root (unwritable prefix), and the --global-prefix shapes.
GOPRIVATE / GONOSUMDB / custom GOSUMDB in hosted rollback; go.work.sum in hosted workspace mode.
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.

0 replies

2026-10-08T13:26:35Z

github-actions[bot]
Bot Oct 8, 2026

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

Generated by Claude Code

0 replies

2026-10-11T13:27:33Z

github-actions[bot]
Bot Oct 11, 2026

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

Generated by Claude Code

0 replies

2026-10-27T13:35:34Z

github-actions[bot]
Bot Oct 27, 2026

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

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

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

Generated by Claude Code

0 replies

2026-10-27T22:01:13Z

github-actions[bot]
Bot Oct 27, 2026

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

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

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

Re-triage

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

Cells

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

Issues

False positives ruled out

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

Probe branches

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

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

0 replies

2026-10-28T04:06:38Z

github-actions[bot]
Bot Oct 28, 2026

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

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

Re-triage

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

Cells

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

Issues

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

False positives ruled out

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

Probe branches

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

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

0 replies

2026-10-28T10:03:15Z

github-actions[bot]
Bot Oct 28, 2026

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

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

Re-triage

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

Cells

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

Issues

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

False positives ruled out

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

Probe branches

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

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

0 replies

2026-10-28T16:13:14Z

github-actions[bot]
Bot Oct 28, 2026

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

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

Re-triage

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

Cells

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

Issues

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

False positives ruled out

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

Probe branches

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

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

0 replies

Bug hunt ledger: Go modules #317

Uh oh!

Uh oh!

Mikola Lysenko (mikolalysenko) Sep 30, 2026 Maintainer

Coverage matrix

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

Backlog

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

Known non-bugs

Replies: 20 comments

Uh oh!

github-actions[bot] Bot Sep 30, 2026

Cells

Issues

False positives ruled out

Probe runs

Next

Uh oh!

github-actions[bot] Bot Sep 30, 2026

Re-triage

Cells

Issues

False positives ruled out

Probe branches

Next

Uh oh!

github-actions[bot] Bot Oct 1, 2026

Uh oh!

github-actions[bot] Bot Oct 1, 2026

Re-triage

Cells (maintainer backlog item 0: global -g)

Issues

False positives ruled out

Probe branches

Next

Uh oh!

github-actions[bot] Bot Oct 1, 2026

Re-triage

Cells

Issues

False positives ruled out

Probe branches

Next

Uh oh!

github-actions[bot] Bot Oct 1, 2026

Re-triage

Cells

Issues

False positives ruled out

Probe branches

Next

Uh oh!

github-actions[bot] Bot Oct 1, 2026

Re-triage

Cells

Issues

False positives ruled out

Probe branches

Next

Uh oh!

github-actions[bot] Bot Oct 2, 2026

Re-triage

Cells (agent mode unless noted)

Issues

False positives ruled out

Probe branches

Next

Uh oh!

github-actions[bot] Bot Oct 2, 2026

Re-triage

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

Issues

False positives ruled out

Probe branches

Next

Uh oh!

github-actions[bot] Bot Oct 2, 2026

Re-triage

Cells

Issues

Mikola Lysenko (mikolalysenko)
Sep 30, 2026
Maintainer

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

github-actions[bot]
Bot Sep 30, 2026

github-actions[bot]
Bot Sep 30, 2026

github-actions[bot]
Bot Oct 1, 2026

github-actions[bot]
Bot Oct 1, 2026

Cells (maintainer backlog item 0: global `-g`)

github-actions[bot]
Bot Oct 1, 2026

github-actions[bot]
Bot Oct 1, 2026

github-actions[bot]
Bot Oct 1, 2026

github-actions[bot]
Bot Oct 2, 2026

github-actions[bot]
Bot Oct 2, 2026

github-actions[bot]
Bot Oct 2, 2026

github-actions[bot]
Bot Oct 2, 2026

github-actions[bot]
Bot Oct 3, 2026

github-actions[bot]
Bot Oct 3, 2026

github-actions[bot]
Bot Oct 8, 2026

github-actions[bot]
Bot Oct 11, 2026