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

[mikolalysenko]

[agent] Found by the scheduled Cargo bug-hunt routine (ledger #315).

Summary

Take a cargo workspace whose Cargo.lock lives at the root, and run socket-patch scan --mode hosted (or a bare scan) with --cwd pointing at a member directory. Hosted mode treats the member as a standalone lockless project, because there is no Cargo.lock beside it and its only dependency is the patched crate. So it:

• adds registry = "socket-patch-<uuid>" to the member's Cargo.toml,
• writes the [registries.socket-patch-<uuid>] block to the member's .cargo/config.toml,
• leaves the workspace root's Cargo.lock untouched (rewrittenFiles is [".cargo/config.toml", "Cargo.toml"], both relative to the member),
• exits 0 with redirected: 1 and no warnings.

The workspace is then broken whichever directory you build from:

• From the workspace root, cargo doesn't read the member's .cargo/config.toml, so the manifest no longer parses: failed to parse manifest at …/direct/Cargo.toml … registry index was not found in any configuration: socket-patch-c1f90104-….
• From the member, the root lock still pins crates.io, so cargo fetch --locked fails with cannot update the lock file …/Cargo.lock because --locked was passed.

Any other member that inherits the crate through [workspace.dependencies] stays unpatched as well.

Impact

A "successful" scan leaves a workspace that can't build at all from the root, and can't build --locked anywhere. A fresh checkout in CI fails, and so does any cargo build a developer runs from the workspace root. Running socket-patch from inside a crate directory of a monorepo is an easy mistake to make, and it produces no warning.

Repro

This uses the shape cargo_hosted_workspace_member_declaration_is_pinned from crates/socket-patch-cli/tests/e2e_redirect_cargo_shapes.rs, with the scan's --cwd set to <proj>/direct instead of <proj>. That's a one-line local change; everything else, including the wiremock patch API and the sparse registry, is unchanged.

proj/Cargo.toml          [workspace] members = ["inherits", "direct"]
                         [workspace.dependencies] cfg-if = "1.0.4"
proj/inherits/Cargo.toml cfg-if = { workspace = true }
proj/direct/Cargo.toml   cfg-if = "1.0.4"
proj/Cargo.lock          (generated at the root, cfg-if 1.0.4 from crates.io)

$ socket-patch scan --mode hosted --json --yes --cwd proj/direct --api-url <mock> --org test-org --api-token fake
  -> exit 0, redirect.redirected = 1, warnings = [], rewrittenFiles = [".cargo/config.toml", "Cargo.toml"]
$ git -C proj status --porcelain
  M direct/Cargo.toml          # cfg-if = { version = "1.0.4", registry = "socket-patch-c1f9…" }
  ?? direct/.cargo/config.toml # [registries.socket-patch-c1f9…] index = "sparse+…"
  (Cargo.lock unchanged)
$ (cd proj && cargo fetch --locked)
  error: failed to load manifest for workspace member `…/proj/direct`
  Caused by: registry index was not found in any configuration: `socket-patch-c1f90104-5a0c-4e7a-9c0d-1a2b3c4d5e01`
$ (cd proj/direct && cargo fetch --locked)
  error: cannot update the lock file …/proj/Cargo.lock because --locked was passed to prevent this

It reproduced on every run (4 of 4).

Expected vs actual

• Expected: CLI_CONTRACT.md: "A workspace member that shares its root's lockfile is part of that root's project." Hosted mode should either resolve the workspace root (the directory holding the Cargo.lock that the member's [workspace] points to) and rewrite there, or refuse loudly with nothing written. Vendored mode already refuses this case with cargo_manifest_not_workspace_root ("run from the workspace root"). ecosystems.md's lockless rule ("with no Cargo.lock the graph is unknown, so only a project whose sole dependency is the patched crate is redirected") assumes the directory really has no lock. A member whose workspace root has one isn't lockless.
• Actual: success, redirected: 1, and a workspace that no longer builds.

Matrix

OS	cargo	Lock	Reproduces
Linux	1.93.1 (repo toolchain)	v4	yes
Linux	1.97.0 (stable)	v4	yes
macOS / Windows	any	any	not run. The cause is in which directory the rewriter treats as the project root, which is OS-independent.

I didn't bisect it. It's present on main 2463257 (after #277).

Suspect code

• crates/socket-patch-core/src/patch/redirect/mod.rs:1062 (rewrite_cargo): it plans against the candidate files of --cwd only, so with no Cargo.lock in files it takes the lockless path, even though the member's manifest is part of a workspace. That shows as a parent Cargo.toml with [workspace] listing it, or a package.workspace key.
• There's no hosted counterpart to crates/socket-patch-core/src/vendor/cargo.rs:1506 (NOT_WORKSPACE_ROOT), the vendored-mode guard for this exact situation.

Related, but a different mode: #338 (agent mode run from a workspace member patches the wrong copy).

[mikolalysenko]

[agent] Triaged: priority:p2 (Cargo). Not a duplicate. Related to #338 (agent mode from a workspace member) but in a different code path (hosted rewrite_cargo vs. the agent crawler), so it isn't clustered with it. No open PR covers it.

---

Generated by Claude Code

[mikolalysenko]

[agent] Shares root cause with #590: the hosted engine's read_candidate_files (hosted/engine.rs:404) reads lock candidates only relative to --cwd, so the workspace root's governing lock is never consulted when run from a member. Will be fixed together.

---

Generated by Claude Code

[mikolalysenko]

[agent] Claiming this issue (with #590; shared root cause: hosted mode only reads lock candidates in --cwd and never detects that the cwd is a member of a workspace whose governing lock lives in an ancestor). Branch: agent/fix-hosted-ancestor-workspace-lock. Claim-ID: 2026-10-02T19:21:15Z-2c64aa

---

Generated by Claude Code

[mikolalysenko]

[agent] Draft PR: #598

---

Generated by Claude Code