Repository navigation
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
Description
Activity
[agent] Triaged:
priority:p2(Go modules). Not a duplicate, and no open or merged PR fixes it. On mainf6b7fb9, nothing undercrates/reads or writesvendor/modules.txt:apply_go_redirectandvendor_go_moduleboth go only throughgo_mod_edit::ensure_replace_entry, andverify_go_redirect_statedoesn't look atvendor/. This is a different cause from #344 (Go settings read only from the process env).
Generated by Claude Code
[agent] Re-triage from the Go modules bug-hunt (ledger #317): this still reproduces on main
2463257(v5 consolidation, #277), Linux, go 1.24.7. Aftergo mod vendor,apply --offlineexits 0 andgo buildfails with "is replaced in go.mod, but not marked as replaced in vendor/modules.txt".apply --checkstill reports "in sync".New shape with the same root cause: a workspace vendor directory (
go work vendor, go 1.22+;go.work=go 1.22/use .).applyexits 0, andgo build ./...fails with the same inconsistent-vendoring error, this time suggestinggo work vendor.apply --checkstill exits 0. So a fix that syncsvendor/modules.txtneeds to handle thego work vendorlayout as well asgo mod vendor.
Generated by Claude Code
- added a commit that references this issue
on Oct 1, 2026 [agent] New information: hosted mode is affected too. Reproduced 2× on main
61cfb9b(Linux, go 1.24.7).The fixture is the shape of
e2e_golang_hosted_build.rs(get <uuid> --mode hostedagainst a local mock ofview/<uuid>+/patches/packagewith agoproxyoverride). The consumer isgo 1.21, with a committedvendor/fromgo mod vendor, andgo build ./...passes before the patch.socket-patch get $UUID --mode hosted --yes --json … # exit 0, "redirected": 1, "rewrittenFiles": ["go.mod","go.sum"], "warnings": [] go build ./... # go: inconsistent vendoring … # example.com/upstream@v1.0.0: is replaced in go.mod, but not marked as replaced in vendor/modules.txt # (same failure on a fresh day-2 machine) socket-patch vex … --product pkg:golang/example.com/consumer # exit 0, "status": "not_affected" (redirected)So all three Go modes (agent, vendored, hosted) leave a committed-
vendor/project unbuildable with no warning, and VEX attests in all three.
Generated by Claude Code
v5 release blocker (P1). A normal Go project with committed vendor/ stops building after patching. Synchronize the required Go files, or give an actionable regeneration step before claiming the workflow is complete.
This follows the maintainer's release scope: one normally completing CLI instance, prioritizing valid-lockfile patch/install behavior, compatibility, and actionable CLI UX.
[agent] Claiming for v5 blocker burn-down (shared root cause: Go redirect wiring edits only the consumer go.mod replace; vendor/modules.txt and the consumer requirement graph/go.sum are never synced or checked). Branch: agent/v5-go-consumer-sync. Claim-ID: 2026-10-09T16:41:32Z-61a8f8
- added a commit that references this issue
on Oct 10, 2026 - added a commit that references this issue
on Oct 10, 2026
[agent] Found by the scheduled Go modules bug-hunt routine (ledger #317).
Summary
In a Go project with a committed
vendor/directory (go mod vendor), both agent-modeapplyand vendored-modevendoradd ago.modreplaceand exit 0. Neither touchesvendor/modules.txt. From then on, everygo build/go run/go testfails:With a
vendor/directory andgo ≥ 1.14ingo.mod, go defaults to-mod=vendorand checks thatmodules.txtrecords everygo.modreplace.apply --checkstill saysPatch redirects are in sync(exit 0).vexattestsnot_affected. Nothing tells the user to re-rungo mod vendor.rollbackthen breaks the build a second time, the other way round ("is marked as replaced in vendor/modules.txt, but not replaced in go.mod").Impact
Committing
vendor/is common in large Go repos (Kubernetes-style monorepos, air-gapped CI). There, a successfulsocket-patch applyorvendorleaves the default build broken on every machine and in CI. That's "a rewrite that makes the next frozen install fail", and the CLI's own audit (apply --check) and VEX both call the state healthy. Runninggo mod vendorafterwards does produce a correct patched build (it copies the patched tree intovendor/), so the fix is to either do that sync (or itsmodules.txtequivalent) or refuse or warn up front.Repro (hermetic file GOPROXY, the same fixture shape as
tests/e2e_golang_build.rs)socket-patch vendor --offline --ecosystems golangin place ofapplybehaves the same: exit 0, thereplace => ./.socket/vendor/golang/<uuid>/…is written, the build fails with the same error, andvexattestsnot_affected.Expected vs actual
docs/ecosystems.md("Go: directory replaces and go.sum") describes thereplaceas the complete mechanism ("the committed patched tree itself is the protection … the wiring survivesgo mod tidy").docs/design/golang-hosted.mdsays "go mod vendorvendors the PATCHED bytes … the vendored escape hatch composes". So a project that usesvendor/should keep building afterapply/vendor: eithervendor/modules.txt(andvendor/<module>) get synced, or the command refuses or at least warns (go mod vendorrequired) andapply --checkreports the inconsistency.apply --checkin sync, and VEX attests.vendor/modules.txtis never read or written anywhere incrates/(README: "vendor/modules.txtis not read").Matrix (probe run https://github.com/SocketDev/socket-patch/actions/runs/36746894687, plus local)
applyvendorAccess is denied. (os error 5), to be filed separatelyRelease 4.0.0 behaves the same (checked locally). I couldn't compare 3.3.0 because it doesn't accept the hand-staged manifest. A
go 1.13go.modwith an explicit-mod=vendorfails the same way on go 1.24.Suspect code
crates/socket-patch-core/src/patch/redirect/golang_local.rs:170apply_go_redirect→go_mod_edit::ensure_replace_entry(crates/socket-patch-core/src/vendor/go_mod_edit.rs:175): onlygo.modis edited.crates/socket-patch-core/src/vendor/golang.rs:209vendor_go_module: same.golang_local::verify_go_redirect_state(apply --check) doesn't look atvendor/modules.txt.