Bug hunt ledger: Cargo

[Mikola Lysenko (mikolalysenko)]

[agent] Progress ledger for the scheduled Cargo bug-hunt routine (label pm:cargo).

Last updated: 2026-10-03 (run 11), main 045d7ec (unchanged since run 10; no cargo-specific code changes since 61cfb9b; shared #555 lockfile-only apply skip regressed cargo cold caches as #616 and silences the #338 non-cargo vendor/ shape), CLI 4.0.0, latest release 4.0.0.

Run 11 added these cells (Linux; not yet in the table): agent with a non-cargo vendor/ dir: fail #338 (comment); agent cargo vendor --versioned-dirs: pass (1.93.1); -g with default ~/.cargo: pass (stable); vendored multi-version with rust-version.workspace = true: fail #651; hosted on cargo 1.67.1: fail #653 (1.68.2 passes); stale [[patch.unused]] with --locked: pass on 1.56.1, 1.84.1 and 1.93.1.

Coverage matrix

Cells are "pass", "fail #N" or "untested". Every cell uses a real cargo build (--locked/--frozen/--offline) plus a compile oracle: the patch appends pub fn socket_patched() to cfg-if, and main.rs calls it. Patch data comes from a local public-proxy stand-in (--proxy-url, serving /patch/batch, /patch/view/<uuid> and /patch/blob/<hash>) for agent and global mode. Hosted mode uses the wiremock sparse-registry harness in tests/e2e_redirect_cargo_shapes.rs, with extra shapes added locally and not committed. The repo suites and cargo_e2e_matrix already cover the plain shapes, lock v1–v4 and the old toolchains. All of them passed on 2463257 in run 3. Since v5, vendored cells need the repo's tests/prebuilt_common fixture server (SOCKET_VENDOR_URL), because vendor downloads artifacts from the service.

Cells marked (pre-v5) were last verified on f6b7fb9 and need a re-check on v5.

OS	cargo	Agent vendor/ (source replacement)	Agent custom vendor dir / member cwd	Agent two index dirs (#339 family)	Agent→vendored takeover + rollback	Vendored (CRLF, BOM, ws, existing [patch], re-run, repair)	Hosted extra shapes	Agent after prior build (target/ cache)	Hosted registry = "crates-io"	Agent rollback of cargo vendor .cargo-checksum.json	Hosted --cwd = workspace member	Global -g: scan report / hosted refusal / apply / rollback / vex	Hosted in a cargo vendor project (source replacement)	Vendored BOM+CRLF workspace / member refusal / exclude	Hosted with user [patch.crates-io] (same crate / unrelated used / unrelated unused) / path dep refusal	Hosted URL-spelled [patch] / [replace] of the patched crate	Agent with user [patch.crates-io] override of the patched crate	Agent re-run after a registry-copy reset (#454)	Agent .cargo/config.toml [patch] / git dep (#506 family)	Hosted config-file / git [patch] (#480 family) / git direct dep	-g legacy git-index dir / -g inside a cargo vendor project	Agent / hosted +build version (wasi 0.11.0+wasi-snapshot-preview1)	Agent / hosted [source.crates-io] replace-with sparse mirror	Hosted manifest spellings (target tables, inline comment, dep: optional, range req, quoted key, table form, build+normal)	Vendored rescan / --prune after the dep is removed or bumped (warm / clean cache), sibling project	vendor -g refusal	Agent apply on a cold / pruned registry cache (#555 lockfile-only skip)
Linux	1.56.1	pass (probe, pre-v5)	fail #338 (probe)	n/a	untested	untested	untested	fail #387	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested / blocked (harness uses name@ver pkgid; cargo 1.56 rejects it)	untested	blocked (same harness limit)	untested	untested	untested
Linux	1.84.1	untested	untested	fail #339	untested	untested	untested	fail #387	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	fail #573 / untested, fail #573	untested	untested
Linux	1.93.1	pass	fail #338	fail #339 (re-confirmed on v5, also under -g)	fail #336 (re-confirmed on v5)	pass (pre-v5; repo suites pass on v5)	pass (pre-v5 list, plus v5: [registries.other] config, CRLF config, dead-index remove fails loudly)	fail #387 (pre-v5)	fail #386 (re-confirmed on v5)	fail #416	fail #417	pass / pass / pass / pass / pass (plus unicode path, unwritable dir, SOCKET_GLOBAL, --global-prefix); multi-index fail #339	fail #455	untested	fail #480 / pass / pass / pass	fail #480 / pass (refused)	fail #506	pass	fail #506 / fail #506	fail #480 / fail #480 / pass (refused)	pass / pass	pass / pass (lock v1–v4)	pass / pass	pass (lock v1–v4); single-quoted value refused loudly (non-bug)	fail #573 / pass, fail #573	pass	fail #616 / fail #616
Linux	1.97.0 (stable)	pass (v5)	fail #338 (v5)	untested	fail #336 (v5)	pass (repo suites, lock v1–v3)	pass (repo shapes, lock v1–v3)	fail #387	untested	fail #416	fail #417	untested (the CLI path is the same as on 1.93.1)	fail #455	pass / pass / pass	fail #480 / untested / untested / untested	fail #480 / pass (refused)	fail #506	pass	untested	fail #480 / fail #480 / pass (refused)	untested	untested / pass	untested / untested	pass	fail #573 / untested, fail #573	untested	fail #616 / untested
macOS	1.56.1 / 1.84.1 / 1.93.1 / stable	pass (probe, pre-v5)	fail #338 (probe)	fail #339	untested	untested	untested	untested	untested	untested (expected same)	untested	untested (needs a probe)	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested
Windows	1.56.1 / 1.84.1 / 1.93.1 / stable	pass (probe, stable, pre-v5)	fail #338 (probe)	fail #339	untested	untested	untested	untested	untested	untested (expected same)	untested	untested (needs a probe)	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested

Backlog

0. Maintainer request (Linux done in runs 3 and 11): global -g mode on macOS and Windows across the Cargo majors: scan report, hosted refusal, apply, rollback and vex. The full checklist is in the 20261001T040000Z entry.
1. The stale probe branches bughunt/cargo/20260930-vendor-dir and bughunt/cargo/20260930-index-dirs still exist. Deleting them failed through the git proxy or was denied by policy in runs 1–10. A maintainer needs to delete them. Until then, avoid new probe branches.
2. Hosted on cargo 1.68–1.81 (lock v3), between the sparse floor (Hosted cargo redirect writes a sparse+ registry even when the project declares rust-version < 1.68, so every build on that cargo fails with "usage of sparse registries requires -Z sparse-registry" while scan reports success #653) and the CI leg (1.82).
   2b. Hosted with a [patch] override in $CARGO_HOME/config.toml or an ancestor config: same root cause as Hosted cargo scan redirects a crate the user overrides with [patch.crates-io], silently dropping the override and breaking --locked #480, so only worth a live check once Hosted cargo scan redirects a crate the user overrides with [patch.crates-io], silently dropping the override and breaking --locked #480 is fixed.
3. Vendored on old cargo (+1.41 / +1.45) with a BOM/CRLF root manifest, plus v1/v2 lock re-encodes of the vendored workspace shape. Also vendored on Windows and macOS.
4. Re-triage Agent-mode cargo apply/rollback has no effect on an already-built project: cargo reuses the cached rlib from target/, while apply reports success and VEX attests not_affected #387 and Agent-mode cargo apply patches only the first of several registry/src index dirs (cargo 1.84 vs 1.85+ hashes), so one cargo keeps building the unpatched crate while apply and VEX report success #339 live once cargo code changes on main.
5. Cargo apply on a cold or pruned registry cache now exits 0 as "lockfile-only", then the next cargo build downloads and compiles the unpatched crate (regression from #555) #616: a target-gated crate (cfg(windows) dependency on Linux) should stay a calm skip once the fix lands. Verify that.
6. -g default ~/.cargo on macOS and Windows (Linux passed in run 11).
7. Maintainer call needed: a local agent scan patches registry-cache crates that the project's Cargo.lock doesn't contain, and vex --product <project> lists them (see Known non-bugs; Agent-mode cargo patches the unused registry copy of a crate the user overrides with [patch.crates-io], and VEX attests not_affected while the build links the user's unpatched fork #506 is the narrower, filed case).

Known non-bugs

• patches-api.socket.dev is blocked by the sandbox proxy (403). Use a local --proxy-url stand-in or the repo's wiremock harnesses.
• A hosted dependency declared with dotted keys (cfg-if.version = "1.0.4") is skipped with redirect_cargo_toml_dep_unrewritable, with nothing rewritten. It's a loud, documented-by-warning limitation.
• vendor / --mode vendored refuses already_vendored_in_tree when vendor/<crate> exists: intended. What's wrong is only the hard-coded vendor/ detection (Agent-mode cargo apply patches the wrong copy when cargo vendor uses a custom directory (or apply runs from a workspace member), yet reports success and VEX attests not_affected #338).
• cargo vendor -q DIR prints no source-replacement snippet, so write .cargo/config.toml by hand in fixtures.
• Release 3.3.0's apply doesn't accept the hand-staged manifest (partialFailure), so it can't be compared.
• apply --check is Go-only (CLI_CONTRACT).
• (v5) setup was removed, and agent-mode vex attests cargo patches without any setup.manual declaration. The old ecosystem_not_setup note no longer applies.
• [patch."sparse+https://index.crates.io/"] isn't honoured by cargo 1.93, so ignoring it is correct. The git-URL alias is refused (cargo_manifest_patch_source_alias), which is also correct.
• An "unpatched" build right after cargo vendor re-runs or re-applies is usually cargo's rlib cache (Agent-mode cargo apply/rollback has no effect on an already-built project: cargo reuses the cached rlib from target/, while apply reports success and VEX attests not_affected #387). Run cargo clean -p <crate> before judging.
• vex -g without --product exits 2 ("Could not auto-detect a top-level product PURL"): expected, since a global scope has no project PURL.
• scan -g --mode hosted / --global-prefix … --mode hosted / SOCKET_GLOBAL=1 scan --mode hosted exit 2 by design.
• Hosted remove / rollback with the crates.io index unreachable fails with hosted_revert_failed and leaves the files intact: correct, loud behaviour.
• -g patches $CARGO_HOME/registry/src, not binaries already built by cargo install. That's inherent to cargo.
• A local agent scan crawls the whole shared registry cache (the crawler's documented fallback), so it can patch and attest crates outside the project's Cargo.lock. It isn't filed: it's documented as "wherever the crawler finds it" and is pending a maintainer call (backlog 7).
• (v5) vendor --offline with no committed artifact refuses vendor_service_offline_conflict: artifacts come from the service (--vendor-source service is the default, and local building was removed). Use the tests/prebuilt_common fixture server for vendored cells.
• repair / GC deletes local beforeHash blobs, so a later rollback --offline fails loudly with "Before blob not found". That's by design: cleanup_unused_blobs keeps only afterHash blobs, and before-blobs are fetched on demand.
• Hosted cfg-if = { path = …, version = "1.0.4" } (a path dependency with a version) is refused with redirect_cargo_toml_dep_unrewritable: correct.
• Hosted with a legacy [replace] "cfg-if:1.0.4" = { path = … } is refused with redirect_cargo_lock_pkg_ambiguous, with nothing rewritten: correct (run 6).
• scan -g / apply -g write .socket/manifest.json at --cwd: by design, since the manifest lives at --cwd and rollback -g drops those records (run 7).
• Vendored with a URL-spelled [patch] or an ancestor/config [patch] of the patched crate is already covered by repo e2e tests (cargo_url_spelled_crates_io_patch_table_is_refused, cargo_ancestor_config_patch_cannot_silently_shadow_the_vendored_copy).
• A hosted git direct dependency is refused with redirect_cargo_toml_dep_unrewritable: correct.
• Hosted remove turns a user's cfg-if = { version = "1.0.4" } (an inline table holding only version) into the shorthand cfg-if = "1.0.4". That's by design: v5 keeps no ledger, and CLI_CONTRACT ("Hosted unwind coverage", cargo) says the shorthand the rewriter produced collapses back. The two spellings mean the same thing to cargo (run 8).
• A hosted dependency spelled with a single-quoted literal (cfg-if = '1.0.4') is refused loudly with redirect_cargo_toml_dep_unrewritable ("unsupported dependency-entry spelling"), with nothing rewritten. It's a loud limitation, like the dotted-key spelling (run 8).
• Hosted remove in a mirror-only environment: the upstream restore always queries index.crates.io (or SOCKET_CRATES_INDEX) and doesn't follow [source] replacement. An unreachable index fails loudly with hosted_revert_failed and changes nothing, as documented (run 9).
• vendor -g / --revert -g / --check -g exit 2 with global_scope_unsupported by design (vendor -g and vendor --revert -g still rewire the current project: on vlt, --revert -g silently unpatches a vendored project (the #446 fix skipped vendor.rs) #498/Fix vendor -g rewiring the cwd project (#498) #499, run 9).
• A stale [[patch.unused]] left in Cargo.lock after a [patch] entry is removed is tolerated by --locked on cargo 1.56.1, 1.84.1 and 1.93.1. The next plain build drops it, which is cargo normalising its own lock. Cosmetic (run 11).
• An agent apply on a cargo vendor --versioned-dirs tree finds vendor/<name>-<version> correctly (run 11).

[github-actions[bot]]

[agent] 2026-09-30: Cargo bug-hunt run

This is the first run, so the ledger started empty and there were no pm:cargo issues to re-triage.

Tested: main f6b7fb9 (CLI reports 4.0.0), latest release 4.0.0, previous release 3.3.0 (both from GitHub release binaries). Toolchains: repo 1.93.1, 1.84.1, and 1.56.1 plus stable on the probes.

Setup: the sandbox can't reach the Socket patch API (proxy 403). Agent and vendored cells used a hand-staged .socket/manifest.json plus blobs built from the real crates.io cfg-if 1.0.0 sources. The patch appends pub fn socket_patched(), and main.rs calls it, so the real cargo build --locked/--frozen --offline is the oracle. Hosted cells reused the wiremock sparse-registry harness from tests/e2e_redirect_cargo_shapes.rs, with extra shapes added locally and not committed.

Cells

• Agent, cargo vendor vendor + source replacement: pass on Linux, macOS and Windows (cargo 1.56.1 and stable), plus multi-version vendor/cfg-if + vendor/cfg-if-0.1.10, and apply → apply → rollback (builds each time).
• Agent, custom vendor dir (third_party/), apply from a workspace member, unwired vendor/: fail on every OS and toolchain → Agent-mode cargo apply patches the wrong copy when cargo vendor uses a custom directory (or apply runs from a workspace member), yet reports success and VEX attests not_affected #338.
• Agent, two registry index dirs (1.84 6f17d2… + ≥1.85 1949cf…) on one CARGO_HOME: fail → Agent-mode cargo apply patches only the first of several registry/src index dirs (cargo 1.84 vs 1.85+ hashes), so one cargo keeps building the unpatched crate while apply and VEX report success #339 on Linux, macOS and Windows. Which toolchain ends up unpatched depends on the listing order.
• Agent→vendored takeover, then rollback: fail → Cargo rollback after an agent→vendored takeover leaves the shared registry cache patched, reports success, and deletes the revert blobs #336. The shared cache stays patched, exit 0, and the manifest entry and blobs are GC'd. Main only; 4.0.0 keeps the blobs.
• Vendored: pass for LF, CRLF, BOM Cargo.toml, no trailing newline, renamed dep, virtual workspace, existing [patch.crates-io] entry, dotted top-level patch.crates-io.x, idempotent re-run, repair, and cargo update after vendoring. Every case checked --locked --offline build + byte-exact --revert.
• Hosted (real cargo, wiremock registry): pass for target-specific deps, [dependencies.x] table, trailing comment, cfg_if = { package = "cfg-if" }, build-dependencies, [workspace.dependencies.x] table with x.workspace = true, a member→member path chain, an excluded non-member path dep, and direct 1.0.4 + transitive 0.1.10 (no false refusal).
• Agent apply after deleting a patched file in vendor/: fails loudly (apply_failed). OK.

Issues

• Filed Cargo rollback after an agent→vendored takeover leaves the shared registry cache patched, reports success, and deletes the revert blobs #336: Cargo rollback after an agent→vendored takeover leaves the shared registry cache patched, reports success, and deletes the revert blobs #336 (rollback after agent→vendored leaves the shared cache patched and deletes the blobs)
• Filed Agent-mode cargo apply patches the wrong copy when cargo vendor uses a custom directory (or apply runs from a workspace member), yet reports success and VEX attests not_affected #338: Agent-mode cargo apply patches the wrong copy when cargo vendor uses a custom directory (or apply runs from a workspace member), yet reports success and VEX attests not_affected #338 (custom cargo vendor dir / member cwd / unwired vendor/)
• Filed Agent-mode cargo apply patches only the first of several registry/src index dirs (cargo 1.84 vs 1.85+ hashes), so one cargo keeps building the unpatched crate while apply and VEX report success #339: Agent-mode cargo apply patches only the first of several registry/src index dirs (cargo 1.84 vs 1.85+ hashes), so one cargo keeps building the unpatched crate while apply and VEX report success #339 (first-wins across registry index dirs)

False positives ruled out

• Hosted dotted-key declaration: a loud redirect_cargo_toml_dep_unrewritable skip, not silent.
• already_vendored_in_tree for --mode vendored with vendor/: intended.
• 3.3.0 partialFailure: it doesn't accept the hand-staged manifest shape, so it's not comparable.
• An early rollback missing_blob: my fixture lacked the before-blob.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/36742276728 (vendor dir; run 36742252162 is a superseded first attempt)
• https://github.com/SocketDev/socket-patch/actions/runs/36742610070 (index dirs)

I couldn't delete either probe branch: git push --delete got HTTP 403 from the git proxy. A maintainer needs to delete bughunt/cargo/20260930-vendor-dir and bughunt/cargo/20260930-index-dirs.

Next

1. .cargo-checksum.json is rewritten pretty-printed, so a rollback isn't byte-exact for a committed vendor/. Check the contract, then decide whether to file.
2. The git index dir (github.com-1ecc6299db9ec823) with sparse dirs: extend Agent-mode cargo apply patches only the first of several registry/src index dirs (cargo 1.84 vs 1.85+ hashes), so one cargo keeps building the unpatched crate while apply and VEX report success #339.
3. Vendored mode on Windows and macOS (CRLF checkout, long paths) and old-cargo builds of the vendored wiring via the probe.
4. Hosted fresh-checkout --locked on Windows; cargo vendor after a hosted redirect.
5. Agent --global with several index dirs.

[github-actions[bot]]

[agent] 2026-09-30 (UTC): Cargo bug-hunt run

This is run 2. Main hasn't moved since run 1: f6b7fb9, CLI 4.0.0, latest release 4.0.0. Toolchains: 1.56.1, 1.84.1, 1.93.1 (repo) and stable 1.97.0, all local rustup on Linux.

Re-triage

#338 and #339 have the same main SHA as when they were filed and no fixing PR, so their status is unchanged. I didn't comment. #336 is also unchanged.

Cells

• Agent, build cache: apply after a prior cargo build doesn't take effect. Cargo reuses the unpatched rlib, while apply reports success and VEX says not_affected. Fail → Agent-mode cargo apply/rollback has no effect on an already-built project: cargo reuses the cached rlib from target/, while apply reports success and VEX attests not_affected #387 on 1.56.1, 1.84.1, 1.93.1 and 1.97.0, in both the registry-cache and cargo vendor directory-source layouts. Rollback fails the same way in reverse (1.93.1).
• Hosted (wiremock harness, uncommitted shapes): pass for optional = true with a [features] reference (both "cfg-if" and "dep:cfg-if"), default-features = false, features = [], a "1" caret requirement, a workspace whose two members use the plain and renamed spellings, an idempotent re-scan (byte-identical), and cargo vendor --locked --offline after the redirect (the vendored build links the patch with an empty CARGO_HOME).
• Hosted, explicit registry = "crates-io" (inline and [dependencies.x] table): falsely refused as "pinned to another registry". Fail → Hosted cargo redirect refuses a crates.io dependency declared with an explicit registry = "crates-io", treating crates.io as "another registry" #386. Vendored mode on the same declaration: pass.
• Vendored, user [patch] detection: pass for user_authored_patch_entry from a renamed key (mine = { package = "cfg-if" }), from an ancestor .cargo/config.toml and legacy .cargo/config, and from $CARGO_HOME/config.toml and $CARGO_HOME/config. cargo_manifest_patch_source_alias fires for the git-URL alias with a trailing slash. The [patch."sparse+https://index.crates.io/"] alias (with or without the slash) isn't honoured by cargo 1.93 at all, so ignoring it is correct.
• Vendored over an existing custom cargo vendor source replacement (third_party/): pass (build --locked --offline links the patch, lock tagged).
• Agent VEX after the patch was silently reset (cargo vendor re-run, or a registry dir deleted and re-extracted): pass. VEX omits it with not_applied.

Issues

• Filed Agent-mode cargo apply/rollback has no effect on an already-built project: cargo reuses the cached rlib from target/, while apply reports success and VEX attests not_affected #387: Agent-mode cargo apply/rollback has no effect on an already-built project: cargo reuses the cached rlib from target/, while apply reports success and VEX attests not_affected #387 (agent apply/rollback is invisible to cargo's build cache)
• Filed Hosted cargo redirect refuses a crates.io dependency declared with an explicit registry = "crates-io", treating crates.io as "another registry" #386: Hosted cargo redirect refuses a crates.io dependency declared with an explicit registry = "crates-io", treating crates.io as "another registry" #386 (hosted false refusal of registry = "crates-io")

False positives ruled out

• apply --check returns success for a cargo project whose patched files were reset: --check is documented as Go-only.
• vex in agent mode omits cargo with ecosystem_not_setup: documented. Cargo has no install hook, so declare it in setup.manual.
• The stale M:1 after a cargo vendor re-run was cargo's rlib cache, the same root cause as Agent-mode cargo apply/rollback has no effect on an already-built project: cargo reuses the cached rlib from target/, while apply reports success and VEX attests not_affected #387, not a VEX bug.
• An agent-mode rollback missing_blob was my fixture lacking the before-blob (again).

Probes

I didn't run any. git push --delete still gets HTTP 403 from the git proxy, so any new probe branch would be left behind like bughunt/cargo/20260930-index-dirs and -vendor-dir, which still exist. #387 depends on cargo's platform-independent fingerprint policy, so I didn't need a probe for it.

Next

1. Maintainer: delete the two stale probe branches, or allow branch deletes through the proxy.
2. .cargo-checksum.json pretty-print on agent rollback (not byte-exact for a committed vendor/). Check the contract first.
3. Hosted registry-index = … and [registries] / [registry] default configs; hosted plus existing [source.crates-io] replace-with (vendored sources) on a fresh --locked checkout.
4. Vendored mode on Windows and macOS (CRLF checkout, long .socket/vendor/cargo/<uuid>/ paths), once probe branches can be cleaned up.
5. Agent --global / --global-prefix with several index dirs (Agent-mode cargo apply patches only the first of several registry/src index dirs (cargo 1.84 vs 1.85+ hashes), so one cargo keeps building the unpatched crate while apply and VEX report success #339 family), and the git-index dir name github.com-1ecc6299db9ec823.

[github-actions[bot]]

[agent] 2026-10-01: maintainer note: test global (-g) mode for hosted patches

This is a maintainer request, not a run report. Add it to the top of the backlog and keep it there until the cells below are covered.

Ask: make sure we correctly scan global installs when -g / --global is passed, on every major Cargo version and on Linux, macOS and Windows.

Where Cargo puts global installs: cargo install sources under $CARGO_HOME/registry/src (~/.cargo, %USERPROFILE%\.cargo). Cover a custom CARGO_HOME, multiple index hash dirs (see #339), and rustup toolchains.

What to check (prove each with a real global install, not by reading source):

1. socket-patch scan -g (no --mode) is report-only. It must find every globally installed Cargo package that has a hosted patch: none missing, no project packages leaking in, correct versions. Also check --json.
2. scan -g run from inside a Cargo project versus outside one: -g must scan only the global location, and a scan without -g must never touch it.
3. scan -g --mode hosted and scan --global-prefix <dir> --mode hosted must refuse loudly, as designed ("global installs have no project lockfile to redirect"). They must exit non-zero and write nothing.
4. get -g defaults to agent mode. Check scan -g --apply, apply -g, rollback -g and vex -g: the globally installed copy is actually patched (run the installed tool or import it), rollback restores it byte for byte, and vex only attests what's applied.
5. --global-prefix <dir> and SOCKET_GLOBAL=1 behave the same as -g. That covers custom prefixes, version managers, paths with spaces or unicode, and a non-root user's prefix.
6. A global directory you can't write to (root-owned prefix, Windows Program Files) must fail loudly with a clear error, never exit 0 unpatched.

Add OS × Cargo version cells for -g (scan report / apply / rollback) to the coverage matrix, and use probe branches for macOS and Windows.

[github-actions[bot]]

[agent] 2026-10-01 (UTC): Cargo bug-hunt run

This is run 3. Main moved to 2463257 (#277, the v5 consolidation). The CLI still reports 4.0.0, and the latest release is still 4.0.0, which I used for regression comparison. Toolchains: 1.93.1 (repo) and stable 1.97.0 on Linux. Patch data for the agent and global cells came from a local public-proxy stand-in (--proxy-url, serving /patch/batch, /patch/view, /patch/blob). Hosted cells used the wiremock harness in tests/e2e_redirect_cargo_shapes.rs, with local, uncommitted shapes.

Baseline

All of the repo's cargo e2e suites pass on the new main: e2e_cargo, e2e_redirect_cargo_build, e2e_redirect_cargo_shapes, e2e_safety_cargo_build, e2e_vendor_cargo_build and mode_migration_cargo, at lock v4 on 1.93.1. The shapes, vendor and migration suites also pass with SOCKET_PATCH_CARGO_E2E_LOCK_VERSION = 1, 2 and 3 on stable.

Re-triage

• Agent-mode cargo apply patches only the first of several registry/src index dirs (cargo 1.84 vs 1.85+ hashes), so one cargo keeps building the unpatched crate while apply and VEX report success #339: still reproduces on 2463257, now also in -g mode (only the first registry/src index dir gets patched). I commented: Agent-mode cargo apply patches only the first of several registry/src index dirs (cargo 1.84 vs 1.85+ hashes), so one cargo keeps building the unpatched crate while apply and VEX report success #339 (comment)
• Hosted cargo redirect refuses a crates.io dependency declared with an explicit registry = "crates-io", treating crates.io as "another registry" #386: still reproduces (pinned to another registry ("crates-io")). I commented: Hosted cargo redirect refuses a crates.io dependency declared with an explicit registry = "crates-io", treating crates.io as "another registry" #386 (comment)

Cells: global mode (maintainer request, Linux only)

• scan -g report-only (no --mode), from outside a project: pass. It finds exactly the patched global crate. --json is correct.
• scan -g from inside a project: pass. The project's lockfile-only crates don't leak in, so it scans the global location only.
• scan -g --mode hosted, scan --global-prefix <dir> --mode hosted and SOCKET_GLOBAL=1 scan --mode hosted: pass. Each exits 2 with "global installs have no project lockfile to redirect" and writes nothing.
• scan -g --mode agent, get <purl> -g (defaults to agent) and apply -g: pass. The registry-cache copy is patched, and cargo run --locked --offline links the patched symbol.
• rollback -g and --global-prefix: pass. The restore is byte-exact.
• vex -g --product …: pass. It attests only when the patch is applied, and a reset copy is omitted as not_applied. Without --product it exits 2 asking for one, which is correct.
• --global-prefix / SOCKET_GLOBAL_PREFIX with a space-and-unicode CARGO_HOME path: pass.
• Unwritable global dir (root-owned CARGO_HOME, CLI run as nobody via setpriv): pass. It exits 1 with "Permission denied (os error 13)" and partial_failure.
• Several index dirs under -g: fail, Agent-mode cargo apply patches only the first of several registry/src index dirs (cargo 1.84 vs 1.85+ hashes), so one cargo keeps building the unpatched crate while apply and VEX report success #339.

Cells: other

• Agent cargo vendor tree: apply, --frozen --offline build, rollback. Sources are restored exactly, but .cargo-checksum.json comes back pretty-printed instead of cargo's compact bytes, so a committed vendor/ stays dirty. Fail → Agent-mode cargo rollback leaves a committed cargo vendor tree dirty: .cargo-checksum.json comes back pretty-printed instead of cargo's compact bytes #416 (new, low severity). Release 4.0.0 behaves the same, so it isn't a regression.
• Hosted scan with --cwd at a workspace member. It rewrites the member as a lockless project, leaves the root lock alone, and every workspace build breaks while the scan reports success. Fail → Hosted cargo scan run from a workspace member treats it as a lockless project, rewrites only the member, and breaks every build of the workspace while reporting success #417 (new). Reproduced on 1.93.1 and 1.97.0.
• Hosted remove / rollback with the crates.io index unreachable (SOCKET_CRATES_INDEX pointed at a dead port): pass. It fails loudly with hosted_revert_failed, nothing is half-written, and cargo fetch --locked still works.
• Hosted with an unrelated [registries.other] + [net] in .cargo/config.toml, and with a CRLF .cargo/config.toml: pass. That covers the full scan → fresh --locked build → vex → byte-exact remove chain.

Issues

• Filed Agent-mode cargo rollback leaves a committed cargo vendor tree dirty: .cargo-checksum.json comes back pretty-printed instead of cargo's compact bytes #416: Agent-mode cargo rollback leaves a committed cargo vendor tree dirty: .cargo-checksum.json comes back pretty-printed instead of cargo's compact bytes #416
• Filed Hosted cargo scan run from a workspace member treats it as a lockless project, rewrites only the member, and breaks every build of the workspace while reporting success #417: Hosted cargo scan run from a workspace member treats it as a lockless project, rewrites only the member, and breaks every build of the workspace while reporting success #417
• Commented on Agent-mode cargo apply patches only the first of several registry/src index dirs (cargo 1.84 vs 1.85+ hashes), so one cargo keeps building the unpatched crate while apply and VEX report success #339 and Hosted cargo redirect refuses a crates.io dependency declared with an explicit registry = "crates-io", treating crates.io as "another registry" #386 (both still open).

False positives and observations (not filed)

• A local (non--g) agent scan in a Cargo project crawls the whole shared registry/src. It patches crates the project's Cargo.lock doesn't contain, records them in the project manifest, and vex --product <project> then lists them as subcomponents. The crawler doc and CLI_CONTRACT both describe the registry-cache fallback ("wherever the crawler finds it"), so this looks like a design choice, and I didn't file it. It needs a maintainer call on whether agent scope (and VEX) should be intersected with Cargo.lock.
• -g patches the registry source cache, not binaries already built by cargo install in $CARGO_HOME/bin. That's inherent to cargo and undocumented, but not a defect.
• The Known non-bugs entries about setup.manual and ecosystem_not_setup are obsolete in v5 (setup was removed, and agent-mode vex now attests cargo directly). I've rewritten them in the state file.

Probes

None. git push --delete still fails (an "unexpected disconnect" from the git proxy), so the two stale branches from 2026-09-30 remain, and any new probe branch would be stranded. macOS and Windows -g cells stay untested.

Next

1. macOS and Windows -g cells (scan report, apply, rollback) on 1.56.1 / 1.84.1 / 1.93.1 / stable, once probe branches can be deleted.
2. Hosted with an existing [source.crates-io] replace-with (a vendored or mirror source) on a fresh --locked checkout.
3. Re-triage Cargo rollback after an agent→vendored takeover leaves the shared registry cache patched, reports success, and deletes the revert blobs #336, Agent-mode cargo apply patches the wrong copy when cargo vendor uses a custom directory (or apply runs from a workspace member), yet reports success and VEX attests not_affected #338 and Agent-mode cargo apply/rollback has no effect on an already-built project: cargo reuses the cached rlib from target/, while apply reports success and VEX attests not_affected #387 on the v5 main.
4. Vendored mode from a workspace member, with a CRLF or BOM root Cargo.toml, on the v5 main. Check that cargo_manifest_not_workspace_root still fires.
5. Agent repair (v5 artifact restore) for a deleted blob, and agent vex against a hand-edited .cargo-checksum.json.

[github-actions[bot]]

[agent] 2026-10-01 (UTC): Cargo bug-hunt run

This is run 4. Main hasn't moved since run 3: 2463257 (#277, the v5 consolidation). The CLI reports 4.0.0, and the latest release is 4.0.0. Toolchains: 1.93.1 (repo) and stable 1.97.0, on Linux.

v5 vendor downloads its artifacts from the patch service (--vendor-source service is the default, and local builds are gone), so a hand-staged manifest alone now fails with vendor_service_offline_conflict. For the vendored cells I ran the repo's tests/prebuilt_common fixture server as a local helper (SOCKET_VENDOR_URL). Hosted cells used tests/e2e_redirect_cargo_shapes.rs with local shapes. Neither change was committed.

Re-triage

• Cargo rollback after an agent→vendored takeover leaves the shared registry cache patched, reports success, and deletes the revert blobs #336 (agent→vendored takeover, then rollback): still reproduces on v5. Rollback now adds a reinstall_required warning, but for cargo nothing ever re-extracts the crate. The cache stays patched and the blobs are GC'd. Comment: Cargo rollback after an agent→vendored takeover leaves the shared registry cache patched, reports success, and deletes the revert blobs #336 (comment)
• Agent-mode cargo apply patches the wrong copy when cargo vendor uses a custom directory (or apply runs from a workspace member), yet reports success and VEX attests not_affected #338 (custom third_party/ vendor dir): still reproduces on v5 with cargo 1.97.0 (2/2). Comment: Agent-mode cargo apply patches the wrong copy when cargo vendor uses a custom directory (or apply runs from a workspace member), yet reports success and VEX attests not_affected #338 (comment)

Cells

• Hosted in a cargo vendor project ([source.crates-io] replace-with = "vendored-sources"): fail → Hosted cargo scan in a cargo vendor project reports success but breaks every fresh cargo build --frozen --offline, and VEX then omits the patch #455 (new). The scan reports success with no warning, every fresh cargo build --frozen --offline then fails (no matching package named cfg-if … socket-patch-<uuid> index), and vex omits the patch as not_applied even when an online build links it (the crawler reads the stale vendor/, the Agent-mode cargo apply patches the wrong copy when cargo vendor uses a custom directory (or apply runs from a workspace member), yet reports success and VEX attests not_affected #338 root cause). Reproduced 3/3 on 1.93.1 and 1.97.0.
• Hosted, [target.'cfg(unix)'.dependencies]: pass (full chain: scan, fresh --locked build, vex, byte-exact remove).
• Hosted, [target.x86_64-unknown-linux-gnu.dependencies.cfg-if] table: pass.
• Hosted, [build-dependencies] with the oracle in build.rs: pass.
• Hosted, inline table with default-features = false plus a trailing # comment: pass.
• Vendored, virtual workspace whose root Cargo.toml has a BOM and CRLF, with members inheriting through [workspace.dependencies] and declaring the crate directly: pass. CRLF is kept, a fresh clone with an empty CARGO_HOME builds both members --locked --offline, vex attests, and rollback restores Cargo.toml and Cargo.lock byte for byte.
• Vendored, run from a member of that BOM/CRLF workspace: pass (cargo_manifest_not_workspace_root, nothing written).
• Vendored, a crate under the workspace dir but listed in exclude, with its own lock: pass (vendored, builds, not refused).
• Vendored, then the user runs cargo vendor, and then cargo update: pass. The path patch needs no vendoring, --frozen --offline builds, the tag is kept, and vex attests.
• Agent vex after the patched file is hand-reverted (sidecar kept): pass (not_applied, no attestation).
• Agent repair with the after-blob deleted: no defect, see below.

Issues

• Filed Hosted cargo scan in a cargo vendor project reports success but breaks every fresh cargo build --frozen --offline, and VEX then omits the patch #455: Hosted cargo scan in a cargo vendor project reports success but breaks every fresh cargo build --frozen --offline, and VEX then omits the patch #455
• Commented on Cargo rollback after an agent→vendored takeover leaves the shared registry cache patched, reports success, and deletes the revert blobs #336 and Agent-mode cargo apply patches the wrong copy when cargo vendor uses a custom directory (or apply runs from a workspace member), yet reports success and VEX attests not_affected #338 (both still open).

False positives ruled out

• repair (and its GC) deletes the local beforeHash blobs, so a later rollback --offline fails with "Before blob not found … --offline prevents fetching". That's by design: cleanup_unused_blobs keeps only afterHash blobs, and before-blobs are downloaded on demand during rollback. The failure is loud. Not cargo-specific.
• The vendor_service_offline_conflict refusal for vendor --offline with no committed artifact is v5 behaviour, documented in vendor --help.

Probes

None. git push --delete of the stale branches still fails ("unexpected disconnect while reading sideband packet"). The macOS and Windows cells, including the maintainer's -g request, stay blocked.

Next

1. macOS and Windows -g cells, once a maintainer deletes bughunt/cargo/20260930-vendor-dir and bughunt/cargo/20260930-index-dirs and probe deletes work.
2. Re-triage Agent-mode cargo apply/rollback has no effect on an already-built project: cargo reuses the cached rlib from target/, while apply reports success and VEX attests not_affected #387 and Agent-mode cargo apply patches only the first of several registry/src index dirs (cargo 1.84 vs 1.85+ hashes), so one cargo keeps building the unpatched crate while apply and VEX report success #339 on the next main move.
3. Hosted with an existing user [patch.crates-io] entry for an unrelated crate, and with [patch.crates-io] cfg-if = { path = … } (expect a refusal).
4. Vendored on old cargo (+1.41 / +1.45) with a BOM/CRLF root manifest, plus a v1/v2 lock re-encode of the workspace shape.
5. Agent mode with CARGO_HOME set via .cargo/config.toml-adjacent env (CARGO_HOME unset, ~/.cargo default) versus a rustup-proxied toolchain dir.

[github-actions[bot]]

[agent] 2026-10-01 (UTC): Cargo bug-hunt run

This is run 5. Main moved to 6e7ef74 (#345 npm, #330 Poetry, #337 npm VEX, #322 Maven). None of these commits touches cargo code: in crates/, git diff 2463257..6e7ef74 changes only the npm, Python and Maven paths and one line in scan/hosted.rs. The CLI reports 4.0.0, and the latest release is 4.0.0. Toolchains: 1.93.1 (repo) and stable 1.97.0, on Linux. Hosted cells used tests/e2e_redirect_cargo_shapes.rs with local shapes (not committed).

Re-triage

• Agent-mode cargo apply/rollback has no effect on an already-built project: cargo reuses the cached rlib from target/, while apply reports success and VEX attests not_affected #387 and Agent-mode cargo apply patches only the first of several registry/src index dirs (cargo 1.84 vs 1.85+ hashes), so one cargo keeps building the unpatched crate while apply and VEX report success #339: no cargo crawler, apply or rollback code changed between 2463257 (where both were last confirmed) and 6e7ef74. They stay open. I didn't post a comment because there's no new information.

Cells

• Hosted, user [patch.crates-io] cfg-if = { path = … } overriding the patched crate: fail → Hosted cargo scan redirects a crate the user overrides with [patch.crates-io], silently dropping the override and breaking --locked #480 (new). The scan pins the declaration and inserts a patch-registry source into the sourceless lock block, then reports redirected: 1 with no warnings. The user's override becomes unused, and a fresh cargo fetch --locked fails. Reproduced 2/2 on 1.93.1 and 1/1 on 1.97.0.
• Hosted, user [patch.crates-io] itoa = { path = … } for an unrelated crate that's in the graph: pass (full chain: scan, fresh --locked build, oracle, vex, byte-exact remove).
• Hosted, the same override with itoa unused ([[patch.unused]] in the lock): pass.
• Hosted, cfg-if = { path = "…", version = "1.0.4" } path dependency: pass (refused with redirect_cargo_toml_dep_unrewritable, nothing written).

Issues

• Filed Hosted cargo scan redirects a crate the user overrides with [patch.crates-io], silently dropping the override and breaking --locked #480: Hosted cargo scan redirects a crate the user overrides with [patch.crates-io], silently dropping the override and breaking --locked #480. I added a follow-up comment correcting its "Expected" citation.

False positives ruled out

• None new.

Probes

None. git push --delete of bughunt/cargo/20260930-vendor-dir and bughunt/cargo/20260930-index-dirs still fails ("unexpected disconnect while reading sideband packet"). A maintainer needs to delete them.

Next

1. macOS and Windows -g cells (maintainer request), once the stale probe branches are deleted.
2. Hosted with [patch."https://github.com/rust-lang/crates.io-index"] overriding the patched crate (the URL spelling of Hosted cargo scan redirects a crate the user overrides with [patch.crates-io], silently dropping the override and breaking --locked #480), and a user [replace] ("cfg-if:1.0.4" = { path = … }).
3. Vendored on old cargo (+1.41 / +1.45) with a BOM/CRLF root manifest, plus a v1/v2 lock re-encode of the workspace shape.
4. Agent mode with a user [patch.crates-io] path override of the patched crate: does apply patch the registry copy that cargo doesn't build, and does vex attest it?
5. Re-run Agent-mode cargo apply/rollback has no effect on an already-built project: cargo reuses the cached rlib from target/, while apply reports success and VEX attests not_affected #387 and Agent-mode cargo apply patches only the first of several registry/src index dirs (cargo 1.84 vs 1.85+ hashes), so one cargo keeps building the unpatched crate while apply and VEX report success #339 live, once cargo code changes on main.

[github-actions[bot]]

[agent] 2026-10-01 (UTC): Cargo bug-hunt run

This is run 6. Main moved to 61cfb9b (16 commits: npm, pnpm, Python, gem, Composer and vlt fixes, plus two cross-cutting ones: #446, which keeps -g off the project's state, and #456, which re-applies recorded patches on an agent re-run). No cargo crawler, cargo format or cargo VEX code changed (git diff 6e7ef74..61cfb9b over crawlers/cargo_crawler.rs, formats/cargo, vex/discover/cargo.rs is empty). The CLI reports 4.0.0, and the latest release is 4.0.0. Toolchains: 1.93.1 (repo) and stable 1.97.0, on Linux. Hosted cells used tests/e2e_redirect_cargo_shapes.rs with a local post-baseline override hook (not committed). Agent cells used a local --api-url mock (/v0/orgs/<org>/patches/{batch,by-package,view}, the same shape as in_process_agent_reapply.rs).

Re-triage

• Agent-mode cargo apply/rollback has no effect on an already-built project: cargo reuses the cached rlib from target/, while apply reports success and VEX attests not_affected #387 and Agent-mode cargo apply patches only the first of several registry/src index dirs (cargo 1.84 vs 1.85+ hashes), so one cargo keeps building the unpatched crate while apply and VEX report success #339: the cargo code paths are unchanged since they were last confirmed, so I didn't post a comment. They stay open.

Cells

• Hosted, [patch."https://github.com/rust-lang/crates.io-index"] cfg-if = { path = … } (the URL spelling of Hosted cargo scan redirects a crate the user overrides with [patch.crates-io], silently dropping the override and breaking --locked #480): fail, same as Hosted cargo scan redirects a crate the user overrides with [patch.crates-io], silently dropping the override and breaking --locked #480. redirected: 1 with no warnings, the override is dropped, and a fresh cargo fetch --locked fails. Reproduced 2/2 on 1.93.1 and 1/1 on 1.97.0. I commented on Hosted cargo scan redirects a crate the user overrides with [patch.crates-io], silently dropping the override and breaking --locked #480.
• Hosted, legacy [replace] "cfg-if:1.0.4" = { path = … }: pass. It's refused with redirect_cargo_lock_pkg_ambiguous and nothing is rewritten (1.93.1 and 1.97.0).
• Agent, user [patch.crates-io] cfg-if = { path = … } override with the crates.io copy still in registry/src: fail → Agent-mode cargo patches the unused registry copy of a crate the user overrides with [patch.crates-io], and VEX attests not_affected while the build links the user's unpatched fork #506 (new). The scan patches the unused registry copy (applied: 1), the build links the user's fork, and vex attests not_affected for pkg:cargo/cfg-if@1.0.4. Reproduced 3/3 on 1.93.1 and 1/1 on 1.97.0.
• Agent re-run after the registry copy is reset (cargo side of scan --sync / --mode agent never re-applies an already-recorded patch, so after a fresh Hatch env (or any reinstall) it exits 0 with the package unpatched #454/Fix agent scan/get skipping apply for recorded patches (#454) #456): pass. Each re-run of scan --mode agent reports skipped: 1, applied: 1 and the --locked --offline build links the patched symbol. apply and rollback also work, and rollback is byte-exact.

Issues

• Filed Agent-mode cargo patches the unused registry copy of a crate the user overrides with [patch.crates-io], and VEX attests not_affected while the build links the user's unpatched fork #506: Agent-mode cargo patches the unused registry copy of a crate the user overrides with [patch.crates-io], and VEX attests not_affected while the build links the user's unpatched fork #506
• Commented on Hosted cargo scan redirects a crate the user overrides with [patch.crates-io], silently dropping the override and breaking --locked #480 (URL spelling, plus the [replace] control): Hosted cargo scan redirects a crate the user overrides with [patch.crates-io], silently dropping the override and breaking --locked #480 (comment)

False positives ruled out

• The [replace] shape: it's refused loudly and correctly, so I added it to Known non-bugs.

Probes

None. Deleting the stale branches bughunt/cargo/20260930-vendor-dir and bughunt/cargo/20260930-index-dirs was blocked this run by the session's permission policy. A maintainer needs to delete them.

Next

1. macOS and Windows -g cells (maintainer request), once the stale probe branches are gone.
2. Vendored with a user [patch."https://github.com/rust-lang/crates.io-index"] / [replace] of the patched crate. Does user_authored_patch_entry / cargo_manifest_patch_source_alias fire? This needs the tests/prebuilt_common fixture server.
3. Agent with a user override in $CARGO_HOME/config.toml / .cargo/config.toml [patch] (cargo ≥ 1.56), and a git-dependency override ([patch.crates-io] cfg-if = { git = … }): same family as Agent-mode cargo patches the unused registry copy of a crate the user overrides with [patch.crates-io], and VEX attests not_affected while the build links the user's unpatched fork #506.
4. Vendored on old cargo (+1.41 / +1.45) with a BOM/CRLF root manifest, plus v1/v2 lock re-encodes.
5. A -g run started inside a cargo project that has vendored the same crate (the Fix -g touching the cwd project's state (#436, #445) #446 rule on cargo).

[github-actions[bot]]

[agent] 2026-10-02 (UTC): Cargo bug-hunt run

This is run 7. Main is unchanged at 61cfb9b (CLI 4.0.0, latest release 4.0.0). Toolchains: 1.93.1 (repo) and stable 1.97.0, on Linux. Agent and -g cells used a local --api-url mock (/v0/orgs/<org>/patches/{batch,by-package,view,blob}). Hosted cells used tests/e2e_redirect_cargo_shapes.rs with a local post-baseline hook (not committed).

Re-triage

• No cargo code has changed since the issues were last confirmed, so I posted no re-triage comments. All 10 open pm:cargo issues stay open.

Cells

• Agent, user [patch.crates-io] path override in .cargo/config.toml: fail, same as Agent-mode cargo patches the unused registry copy of a crate the user overrides with [patch.crates-io], and VEX attests not_affected while the build links the user's unpatched fork #506 (2/2 on 1.93.1).
• Agent, plain git dependency (cfg-if = { git = … }, no [patch]) with a stale crates.io copy in registry/src: fail, same as Agent-mode cargo patches the unused registry copy of a crate the user overrides with [patch.crates-io], and VEX attests not_affected while the build links the user's unpatched fork #506 (2/2). The registry copy is patched, the build compiles the git checkout, and vex attests not_affected.
• Hosted, .cargo/config.toml path [patch]: fail, same as Hosted cargo scan redirects a crate the user overrides with [patch.crates-io], silently dropping the override and breaking --locked #480 (1.93.1 and 1.97.0, lock v4 and v3).
• Hosted, git [patch.crates-io] cfg-if = { git = … }: fail, same as Hosted cargo scan redirects a crate the user overrides with [patch.crates-io], silently dropping the override and breaking --locked #480, but through the Some(source) arm (formats/cargo/hosted.rs:146 overwrites the git+ source). Same 4 cells.
• Hosted, git direct dependency: pass (refused with redirect_cargo_toml_dep_unrewritable, nothing rewritten).
• -g with only the legacy git-index dir registry/src/github.com-1ecc6299db9ec823: pass (scan report, --apply, rollback byte-exact).
• -g --apply run from inside a project that uses cargo vendor source replacement for the same crate: pass (the global copy is patched, vendor/ is untouched, vex -g --product attests, rollback is exact).
• Vendored with a URL-spelled [patch] / an ancestor .cargo/config.toml [patch]: already covered by repo e2e tests (cargo_url_spelled_crates_io_patch_table_is_refused, cargo_ancestor_config_patch_cannot_silently_shadow_the_vendored_copy), so I didn't re-run them.

Issues

• Commented on Hosted cargo scan redirects a crate the user overrides with [patch.crates-io], silently dropping the override and breaking --locked #480 (config-file and git [patch] shapes): Hosted cargo scan redirects a crate the user overrides with [patch.crates-io], silently dropping the override and breaking --locked #480 (comment)
• Commented on Agent-mode cargo patches the unused registry copy of a crate the user overrides with [patch.crates-io], and VEX attests not_affected while the build links the user's unpatched fork #506 (config-file [patch] and a plain git dependency): Agent-mode cargo patches the unused registry copy of a crate the user overrides with [patch.crates-io], and VEX attests not_affected while the build links the user's unpatched fork #506 (comment)
• No new issues.

False positives ruled out

• scan -g writes ./.socket/manifest.json in the cwd. That's by design: the manifest lives at --cwd, and the contract says rollback -g drops those records. Added to Known non-bugs.
• An agent rollback against a mock that has no blob endpoint fails with missing_blob. That's a mock artifact: before-blobs are fetched on demand.

Probes

None. The stale branches bughunt/cargo/20260930-vendor-dir and bughunt/cargo/20260930-index-dirs still can't be deleted (git push --delete gets a 403 from the git proxy). A maintainer needs to delete them.

Next

1. macOS and Windows -g cells (maintainer request), once the stale probe branches are gone.
2. Vendored on old cargo (+1.41 / +1.45) with a BOM/CRLF root manifest, plus v1/v2 lock re-encodes.
3. Hosted with an override in $CARGO_HOME/config.toml (outside the project): is it refused, or does it fail like Hosted cargo scan redirects a crate the user overrides with [patch.crates-io], silently dropping the override and breaking --locked #480?
4. Agent and hosted with a [source] replacement to a private registry mirror (replace-with = "mirror"). Does the crawler patch the right copy?
5. A custom CARGO_HOME versus the default ~/.cargo under -g, including CARGO_HOME with spaces.

[github-actions[bot]]

[agent] 2026-10-02 (UTC): Cargo bug-hunt run

This is run 8. Main is unchanged at 61cfb9b (CLI 4.0.0, latest release 4.0.0). Toolchains: 1.93.1 (repo) and stable 1.97.0 on Linux, plus 1.56.1 (blocked, see below). Agent and -g cells used a local --api-url mock (/v0/orgs/<org>/patches/{batch,by-package,view,blob}). Hosted cells used tests/e2e_redirect_cargo_shapes.rs with extra shapes added locally (not committed). Every cell ran a real cargo build with a compile oracle that links socket_patched().

Re-triage

• No cargo code has changed since the last run, so I posted no re-triage comments. All 10 open pm:cargo issues stay open.

Cells

• Build-metadata version (wasi 0.11.0+wasi-snapshot-preview1):
  • Agent: pass, 2/2, with the API purl spelled both %2B and +. Apply works, the --offline build links the patched symbol, vex attests not_affected, and rollback is byte-exact.
  • Hosted: pass with the requirement spelled =0.11.0, 0.11.0, =0.11.0+wasi-snapshot-preview1 and { version = "0.11" }. A fresh cargo fetch --locked succeeds, the offline build links, vex attests, and remove is byte-exact. Tested on lock v1–v4 with cargo 1.93.1, and on stable 1.97.0.
• [source.crates-io] replace-with = "mirror" (a local sparse mirror proxying crates.io):
  • Agent: pass, 2/2. The crawler finds registry/src/127.0.0.1-<hash>/.
  • Hosted: pass, lock v1–v4 and 1.97.0. The fresh fetch goes through the mirror plus the per-patch registry.
• Hosted manifest spellings: pass on lock v1–v4, 1.93.1 and 1.97.0 for:
  • [target.'cfg(unix)'.dependencies], [target."cfg(unix)".dependencies] and [target.x86_64-unknown-linux-gnu.dependencies]
  • an inline # comment after the requirement
  • optional = true with a dep:cfg-if default feature
  • a range requirement (">=1.0, <2")
  • the "cfg-if" quoted key
  • the [ dependencies ] spaced header
  • the [dependencies.cfg-if] table form with comments
  • [build-dependencies] plus [dependencies]
• Hosted cfg-if = '1.0.4' (single-quoted): refused loudly with redirect_cargo_toml_dep_unrewritable, with nothing rewritten. It's a limitation, not a bug.
• Hosted cfg-if = { version = "1.0.4" } # keep: the redirect and build pass, but remove returns the shorthand cfg-if = "1.0.4" # keep. That's the documented v5 behaviour (no ledger: "the shorthand the rewriter produced collapses back"), and both spellings mean the same thing to cargo. Not a bug.
• -g with CARGO_HOME="…/my cargo home" (contains spaces): pass, 2/2. Scan report, --mode agent apply, the offline build links, vex -g --product attests, and rollback is byte-exact.
• cargo 1.56.1 hosted shapes: blocked. The harness's pin_patched_versions runs cargo update -p cfg-if@1.0.5, and cargo 1.56 doesn't accept the name@version pkgid. The harness's toolchain check also needs 1.56, not 1.56.1 (cargo 1.56.1 reports itself as cargo 1.56.0). Both are harness artifacts.

Issues

None filed, commented on or closed.

False positives ruled out

• An agent rollback missing_blob error from patches-api.socket.dev: I hadn't passed --api-url to rollback (a mock artifact; before-blobs are fetched on demand).
• An agent build that missed the patched symbol on the mirror project: cargo's cached rlib from the baseline build (Agent-mode cargo apply/rollback has no effect on an already-built project: cargo reuses the cached rlib from target/, while apply reports success and VEX attests not_affected #387). It passes after cargo clean -p cfg-if.

Probes

None. Deleting the stale bughunt/cargo/20260930-* branches failed again ("remote end hung up"). A maintainer needs to delete them.

Next

1. macOS and Windows -g cells (maintainer request), once the stale probe branches are gone.
2. Hosted remove with crates.io unreachable but a [source] mirror configured: does it fail loudly, or restore through the mirror?
3. Vendored on old cargo (+1.41 / +1.45) with a BOM/CRLF root manifest, plus v1/v2 lock re-encodes.
4. Old-toolchain (< 1.58) hosted shapes via a hand-written lock, instead of cargo update -p name@ver.
5. -g with CARGO_HOME unset (default ~/.cargo).

[github-actions[bot]]

[agent] 2026-10-02 (UTC): Cargo bug-hunt run

This is run 9. Main is 1169ae6 (CLI 4.0.0, latest release 4.0.0). No cargo crawler, vendor or redirect code changed since 61cfb9b. The shared changes were #543 (the #541 fix: the vendored rescan filters ledger entries through the lockfile in-use probe), #499 (vendor -g refusal) and a toml_surgery change that only uv uses. Toolchains on Linux: 1.84.1, 1.93.1 and stable 1.97.0. Every cell ran a real cargo build with the socket_patched() compile oracle.

Re-triage

• No cargo code has changed since run 8, so all 10 open pm:cargo issues stay open. I posted no comments.

Cells

• vendor -g / vendor --revert -g / vendor --check -g / SOCKET_GLOBAL=1 vendor in a cargo project: pass. Each exits 2 with global_scope_unsupported, and the project stays byte-identical.
• Vendored dependency removed or bumped, then a rescan (Vendored vlt scan exits 1 after the patched dependency is upgraded or uninstalled, and even scan --prune exits 1 while it reverts the stale entry #541 family on cargo): fail, filed Vendored cargo scan exits 1 permanently after a vendored crate is removed or bumped, even with --prune, because the shared registry cache still holds the old version #573.
  • Setup: real cargo 1.93.1, with vendoring through scan --mode vendored (wiremock patch API, view and prebuilt vendor service; the batch API answers per purl).
  • Uninstall: after the re-lock, the rescan exits 1 (locked_version_mismatch, "cfg-if is not present in Cargo.lock"). --prune reverts the entry but still exits 1, and every later rescan exits 1.
  • Bump to =1.0.0: the same result.
  • A sibling project sharing the same CARGO_HOME, which never used cfg-if: exits 1 too, and --dry-run says would_vendor.
  • Cause: the crawler's shared registry-cache fallback re-discovers cfg-if-1.0.5.
  • Reproduced on 1.84.1 and stable 1.97.0.
  • With a clean CARGO_HOME it passes: exit 0 plus vendor_ledger_entry_unwired.
• Manifest-driven vendor, then uninstall, then scan --prune (API with no patches): pass. The prune reverts the entry and exits 0, and cargo build --locked --offline passes afterwards. One residue: the stale [[patch.unused]] block for the Socket copy stays in Cargo.lock (cargo wrote it during the re-lock, and 1.93.1 --locked tolerates it). It's not filed; see backlog 2.
• Hosted remove in a mirror-only environment (backlog 2 from run 8): resolved by reading the code plus the contract. The restore always queries index.crates.io (or SOCKET_CRATES_INDEX) and ignores [source] replacement. An unreachable index fails loudly with hosted_revert_failed and changes nothing, which CLI_CONTRACT documents ("a registry that does not answer"). Recorded as a known non-bug.

Issues

• Filed Vendored cargo scan exits 1 permanently after a vendored crate is removed or bumped, even with --prune, because the shared registry cache still holds the old version #573: Vendored cargo scan exits 1 permanently after a vendored crate is removed or bumped, even with --prune, because the shared registry cache still holds the old version #573

False positives ruled out

• The first local vendor + rescan showed no unwired warning and exited 0. That was an artifact of the mock: the API returned no patches. With a per-purl batch API the real failure (Vendored cargo scan exits 1 permanently after a vendored crate is removed or bumped, even with --prune, because the shared registry cache still holds the old version #573) shows.
• The bump case's per-package locked_version_mismatch for a cached version different from the locked one is pinned by cargo_refuses_early_only_an_installed_crate. Vendored cargo scan exits 1 permanently after a vendored crate is removed or bumped, even with --prune, because the shared registry cache still holds the old version #573 is about the run exit code and the not-in-lock case, and it flags the bump case for a maintainer call.

Probes

• None. Deleting the stale bughunt/cargo/20260930-* branches was denied again, this time by the session permission policy. A maintainer needs to delete them.

Next

1. macOS and Windows -g cells (maintainer request), once the stale probe branches are gone.
2. Check whether the stale [[patch.unused]] left after a vendored revert/prune makes --locked fail on cargo 1.56 or 1.84, or dirties the lock on the next plain build.
3. Vendored on old cargo (+1.41 / +1.45) with a BOM/CRLF root manifest, plus v1/v2 lock re-encodes.
4. Old-toolchain (< 1.58) hosted shapes via a hand-written lock.
5. -g with CARGO_HOME unset (default ~/.cargo).

[github-actions[bot]]

[agent] 2026-10-02 (UTC): Cargo bug-hunt run

This is run 10. Main is 045d7ec (CLI 4.0.0, latest release 4.0.0). No cargo-specific crawler, vendor or redirect files changed since 1169ae6. The shared changes that touch cargo are #555 (the #403 fix: apply's lockfile-only calm skip) and #517 (the #516 fix: agent vex checks every installed copy). Toolchains on Linux: 1.93.1 and stable 1.97.0. Every cell ran a real cargo build with the socket_patched() compile oracle, using a hand-staged manifest and blobs with apply --offline.

Re-triage

• Agent-mode cargo apply patches only the first of several registry/src index dirs (cargo 1.84 vs 1.85+ hashes), so one cargo keeps building the unpatched crate while apply and VEX report success #339 (several registry/src index dirs): still reproduces after Fix agent vex checking only one installed copy (#516) #517. Apply patches only the -1949cf8c6b5b557f copy and vex still says not_affected. Commented: Agent-mode cargo apply patches only the first of several registry/src index dirs (cargo 1.84 vs 1.85+ hashes), so one cargo keeps building the unpatched crate while apply and VEX report success #339 (comment)
• Hosted cargo scan run from a workspace member treats it as a lockless project, rewrites only the member, and breaks every build of the workspace while reporting success #417: claimed by a maintainer agent (draft PR Fix hosted scan from a workspace member pinning nothing or the wrong files (#590, #417) #598, shared with Hosted scan/get run from a pnpm workspace member (or with lockfile-dir=..) ignores the parent pnpm-lock.yaml and reports success while pinning nothing #590). Left alone.

Cells

• Agent apply with a cold CARGO_HOME (the crate is in Cargo.lock but not downloaded): fail, filed Cargo apply on a cold or pruned registry cache now exits 0 as "lockfile-only", then the next cargo build downloads and compiles the unpatched crate (regression from #555) #616. Main exits 0 with status: success and a lockfile-only package_not_installed skip, then cargo build --locked downloads and compiles the unpatched crate. Reproduced on 1.93.1 and stable.
  • The 4.0.0 release (npm) exits 1 with "no matching packages were found on disk".
  • First bad commit: 3a4883c (Fix apply failing when patched deps are skipped (#403) #555).
• Agent apply with a pruned registry/src (the .crate is kept): fail, Cargo apply on a cold or pruned registry cache now exits 0 as "lockfile-only", then the next cargo build downloads and compiles the unpatched crate (regression from #555) #616. cargo build --offline re-extracts the unpatched source.
• Agent apply with a warm cache (control): pass.
• VEX with a cold cache: pass. The patch is omitted as not_applied.

Issues

• Filed Cargo apply on a cold or pruned registry cache now exits 0 as "lockfile-only", then the next cargo build downloads and compiles the unpatched crate (regression from #555) #616: Cargo apply on a cold or pruned registry cache now exits 0 as "lockfile-only", then the next cargo build downloads and compiles the unpatched crate (regression from #555) #616
• Commented on Agent-mode cargo apply patches only the first of several registry/src index dirs (cargo 1.84 vs 1.85+ hashes), so one cargo keeps building the unpatched crate while apply and VEX report success #339.

False positives ruled out

• The first Agent-mode cargo apply patches only the first of several registry/src index dirs (cargo 1.84 vs 1.85+ hashes), so one cargo keeps building the unpatched crate while apply and VEX report success #339 re-check showed both copies as patched. That was an artifact of my setup: the copied CARGO_HOME had already been patched by the warm control. It reproduced after I reset both copies to the original bytes.

Probes

• None. Deleting the stale bughunt/cargo/20260930-* branches was denied by the session permission policy again. A maintainer needs to delete them.

Next

1. A target-gated crate (cfg(windows) dependency on Linux): confirm that Cargo apply on a cold or pruned registry cache now exits 0 as "lockfile-only", then the next cargo build downloads and compiles the unpatched crate (regression from #555) #616's fix keeps it a calm skip.
2. macOS and Windows -g cells (maintainer request), once the stale probe branches are gone.
3. Stale [[patch.unused]] after a vendored revert/prune on cargo 1.56 and 1.84 (install the toolchains).
4. Vendored on old cargo (+1.41 / +1.45) with a BOM/CRLF root manifest.
5. Old-toolchain (< 1.58) hosted shapes via a hand-written lock.

[github-actions[bot]]

[agent] 2026-10-03 (UTC): Cargo bug-hunt run

This is run 11. Main is unchanged at 045d7ec (CLI 4.0.0, latest release 4.0.0). Toolchains on Linux: 1.93.1, stable 1.97.0, plus 1.56.1, 1.67.1, 1.68.2 and 1.84.1, all installed this run. Agent cells used a hand-staged manifest and blobs with apply --offline and the socket_patched() compile oracle. Vendored and hosted cells used scratch copies of e2e_vendor_cargo_build.rs (with the prebuilt_common server) and e2e_redirect_cargo_build.rs (with the wiremock sparse index). The scratch copies weren't committed.

Re-triage

• Cargo apply on a cold or pruned registry cache now exits 0 as "lockfile-only", then the next cargo build downloads and compiles the unpatched crate (regression from #555) #616 and Vendored cargo scan exits 1 permanently after a vendored crate is removed or bumped, even with --prune, because the shared registry cache still holds the old version #573: main hasn't moved since they were last re-checked on 045d7ec, and no PR addresses them yet. Still open.
• Hosted cargo scan run from a workspace member treats it as a lockless project, rewrites only the member, and breaks every build of the workspace while reporting success #417 is still claimed (PR Fix hosted scan from a workspace member pinning nothing or the wrong files (#590, #417) #598). Left alone.

Cells

• Agent apply with a non-cargo vendor/ (C sources or a Composer tree in a mixed repo) and a warm registry cache: fail (Agent-mode cargo apply patches the wrong copy when cargo vendor uses a custom directory (or apply runs from a workspace member), yet reports success and VEX attests not_affected #338 family). The crawler only looks at vendor/. Main exits 0 with a package_not_installed "lockfile-only" skip, the registry copy stays unpatched, and the build fails with E0425. Release 4.0.0 exits 1 (partialFailure). Reproduced twice. The control (no vendor/) passes. Commented on Agent-mode cargo apply patches the wrong copy when cargo vendor uses a custom directory (or apply runs from a workspace member), yet reports success and VEX attests not_affected #338.
• Agent on a cargo vendor --versioned-dirs tree (two cfg-if versions): pass. Apply, build and vex all pass. Rollback reformats .cargo-checksum.json, which is the known Agent-mode cargo rollback leaves a committed cargo vendor tree dirty: .cargo-checksum.json comes back pretty-printed instead of cargo's compact bytes #416.
• -g with CARGO_HOME unset (default ~/.cargo), stable: pass. Apply, build, vex not_affected, and rollback all pass (backlog 6, Linux).
• Vendored two versions + rust-version.workspace = true ([workspace.package] rust-version = "1.70"): fail, filed Vendored cargo warns cargo_multi_version_old_cargo ("declares no rust-version") when the root package inherits rust-version from [workspace.package] #651. A spurious cargo_multi_version_old_cargo says the project "declares no rust-version". Plain rust-version, a BOM-prefixed manifest and the no-declaration control all behave correctly.
• Hosted on cargo 1.67.1 (the sparse registry needs 1.68): fail, filed Hosted cargo redirect writes a sparse+ registry even when the project declares rust-version < 1.68, so every build on that cargo fails with "usage of sparse registries requires -Z sparse-registry" while scan reports success #653. Scan reports success with no floor warning, even with rust-version = "1.67", then every fresh fetch fails with "usage of sparse registries requires -Z sparse-registry". 1.68.2 passes.
• Stale [[patch.unused]] after a [patch] removal (backlog 2), on 1.56.1, 1.84.1 and 1.93.1: --locked passes on all three. The next plain build rewrites the lock, but that's cargo normalising its own file, so it's cosmetic and wasn't filed.

Issues

• Filed Vendored cargo warns cargo_multi_version_old_cargo ("declares no rust-version") when the root package inherits rust-version from [workspace.package] #651: Vendored cargo warns cargo_multi_version_old_cargo ("declares no rust-version") when the root package inherits rust-version from [workspace.package] #651
• Filed Hosted cargo redirect writes a sparse+ registry even when the project declares rust-version < 1.68, so every build on that cargo fails with "usage of sparse registries requires -Z sparse-registry" while scan reports success #653: Hosted cargo redirect writes a sparse+ registry even when the project declares rust-version < 1.68, so every build on that cargo fails with "usage of sparse registries requires -Z sparse-registry" while scan reports success #653
• Commented on Agent-mode cargo apply patches the wrong copy when cargo vendor uses a custom directory (or apply runs from a workspace member), yet reports success and VEX attests not_affected #338: Agent-mode cargo apply patches the wrong copy when cargo vendor uses a custom directory (or apply runs from a workspace member), yet reports success and VEX attests not_affected #338 (comment)

False positives ruled out

• The first Vendored cargo warns cargo_multi_version_old_cargo ("declares no rust-version") when the root package inherits rust-version from [workspace.package] #651 scratch run showed no warning even for the control, because I was reading code instead of the errorCode key. I fixed the extractor and re-ran twice.

Probes

• None. The stale bughunt/cargo/20260930-* branches still need a maintainer to delete them.

Next

1. Hosted on 1.68–1.81 with lock v3 (between the sparse floor and the CI leg), especially 1.68–1.70, where sparse was new.
2. macOS and Windows -g cells, once the stale probe branches are gone.
3. Cargo apply on a cold or pruned registry cache now exits 0 as "lockfile-only", then the next cargo build downloads and compiles the unpatched crate (regression from #555) #616 fix: target-gated (cfg(windows)) crates should stay a calm skip.
4. Vendored on +1.41 / +1.45 with a BOM/CRLF manifest.
5. Old-toolchain (< 1.58) hosted shapes via a hand-written lock. These are now known to fail on < 1.68 anyway (Hosted cargo redirect writes a sparse+ registry even when the project declares rust-version < 1.68, so every build on that cargo fails with "usage of sparse registries requires -Z sparse-registry" while scan reports success #653).