Bug hunt ledger: Cargo

[Mikola Lysenko (mikolalysenko)]

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

Last updated: 2026-09-30 (run 2), main f6b7fb9 (CLI 4.0.0), latest release 4.0.0 (previous 3.3.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 is a hand-staged .socket/manifest.json plus blobs for agent and vendored mode (the same shape tests/e2e_vendor_cargo_build.rs uses). Hosted mode uses the wiremock sparse-registry harness from tests/e2e_redirect_cargo_shapes.rs, with extra shapes added locally and not committed. The existing test suites and the cargo_e2e_matrix already cover the plain shapes, lock v1–v4 and the old toolchains. This ledger tracks what they don't.

OS	cargo	Agent vendor/ (source replacement)	Agent custom vendor dir / member cwd / unwired vendor/	Agent two registry index dirs (1.84 + ≥1.85 on one CARGO_HOME)	Agent→vendored takeover + rollback	Vendored (CRLF, BOM, no-EOL, rename, virtual ws, existing [patch], dotted patch.crates-io, idempotent re-run, repair, cargo update)	Hosted extra shapes	Agent apply/rollback after a prior build (target/ cache)	Hosted explicit registry = "crates-io"	Vendored user [patch] in config files / renamed key / custom source replacement
Linux	1.56.1	pass (probe)	fail #338 (probe)	n/a	untested	untested	untested	fail #387	untested	untested
Linux	1.84.1	untested	untested	fail #339	untested	untested	untested	fail #387	untested	untested
Linux	1.93.1	pass	fail #338	fail #339 (order-dependent: sandbox fails the 1.84 project, the GH runner fails the 1.93 project)	fail #336	pass (all listed)	pass (target-specific, [dependencies.x] table, trailing comment, cfg_if rename, build-deps, [workspace.dependencies.x] table + x.workspace = true, member→member path chain, excluded non-member path dep, direct + transitive other version, optional + features/dep:, default-features = false, "1" caret, ws members plain + renamed, idempotent re-scan, cargo vendor after redirect)	fail #387 (registry, vendor/, rollback)	fail #386	pass
Linux	1.97.0 (stable)	untested	untested	untested	untested	untested	untested	fail #387	untested	untested
macOS	1.56.1 / 1.84.1 / 1.93.1 / stable	pass (probe)	fail #338 (probe, 1.56.1 + stable)	fail #339 (1.93 project unpatched)	untested	untested	untested	untested (cargo-core behaviour, expected same)	untested	untested
Windows	1.56.1 / 1.84.1 / 1.93.1 / stable	pass (probe, stable; 1.56.1 not captured)	fail #338 (probe, 1.56.1 + stable)	fail #339 (1.84 project unpatched)	untested	untested	untested	untested (cargo-core behaviour, expected same)	untested	untested

Backlog

0. The stale probe branches bughunt/cargo/20260930-vendor-dir and bughunt/cargo/20260930-index-dirs still exist: the git proxy refused git push --delete with HTTP 403 in runs 1 and 2. A maintainer needs to delete them. Until deletes work, avoid new probe branches.
1. .cargo-checksum.json formatting: agent rollback restores a cargo vendor checksum file semantically but not byte-for-byte (compact JSON is re-emitted pretty-printed; sidecars/cargo.rs uses to_vec_pretty). Check whether the contract promises byte-exact rollback for sidecars before filing. It's low severity.
2. Hosted: registry-index = … deps; a project with [registries] / [registry] default config; hosted plus existing [source.crates-io] replace-with on a fresh --locked checkout; Windows fresh-checkout --locked.
3. Vendored mode on Windows and macOS (CRLF checkouts, long paths under .socket/vendor/cargo/<uuid>/), and vendored builds on cargo +1.41 / +1.45.
4. Agent --global / --global-prefix against a CARGO_HOME with several index dirs, plus the git-index dir github.com-1ecc6299db9ec823 (both the 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).
5. repair in agent mode for a deleted vendored file; agent vex against a hand-edited .cargo-checksum.json.

Known non-bugs

• patches-api.socket.dev is blocked by the sandbox proxy (403). Stage .socket/manifest.json plus blobs locally, or use 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 ("declared with dotted keys this rewriter does not edit"), with nothing rewritten. It's a loud, documented-by-warning limitation, not a silent failure.
• vendor / --mode vendored refuses already_vendored_in_tree when vendor/<crate> exists: intended ("patch it in place with apply instead"). What's wrong is only that the detection is hard-coded to vendor/ (see 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 (a fixture pitfall).
• Release 3.3.0's apply doesn't accept the hand-staged manifest used here (partialFailure, no events), so 3.3.0 can't be compared for these cells.
• apply --check is Go-only (CLI_CONTRACT), so it returns success with no events for cargo even when patched files were reset.
• Agent-mode vex omits cargo with ecosystem_not_setup unless the manifest has setup.manual: ["cargo"], because cargo has no install hook (setup → no_files). It's documented.
• [patch."sparse+https://index.crates.io/"] isn't treated as crates.io by cargo 1.93 (the build ignores it), so socket-patch 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), not a socket-patch rewrite failure. Run cargo clean -p <crate> before judging a cell.

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