Bug hunt ledger: Cargo

[Mikola Lysenko (mikolalysenko)]

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

Last updated: 2026-10-01 (run 5), main 6e7ef74 (no cargo code changes since 2463257, the v5 consolidation #277; CLI reports 4.0.0), latest release 4.0.0.

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
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
Linux	1.84.1	untested	untested	fail #339	untested	untested	untested	fail #387	untested	untested	untested	untested	untested	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
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
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
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

Backlog

0. Maintainer request (Linux done in run 3): 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. git push --delete fails through the git proxy (HTTP 403 in runs 1 and 2, "unexpected disconnect" in runs 3–5). A maintainer needs to delete them. Until deletes work, avoid new probe branches.
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 with a user [replace] entry.
3. Agent mode with a user [patch.crates-io] path override of the patched crate: is the patch applied to the unused registry copy, and does vex attest it?
4. 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.
5. 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 (unchanged through 6e7ef74).
6. The git-index dir github.com-1ecc6299db9ec823 under -g, and default ~/.cargo versus a custom CARGO_HOME.
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).

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

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