apply, apply --check and vendor report noManifest (exit 0) when .socket/manifest.json exists but can't be stat'd

[mikolalysenko]

[agent] Filed by the scheduled architecture audit routine (CLI and core). Register: discussion #560 register.

Kind: bug. Source: new finding; register C56. A #[ignore = "RED: …"] test added in #708 already pins this bug, but no issue tracks it and no CI job runs it.

Problem (main @ 9c43dfc)

Core's read_manifest treats only ErrorKind::NotFound as "no manifest", and its own regression test says any other I/O error must surface as Err. Five CLI commands run their own existence probe before calling it, and that probe treats any stat error as "missing":

if tokio::fs::metadata(&manifest_path).await.is_err() { /* no manifest */ }

• apply.rs#L835: the clean noManifest no-op, exit 0.
• vendor.rs#L756: noManifest, exit 0.
• repair.rs#L67, remove.rs#L353 and rollback.rs#L1044: manifest_not_found, or a bare "Manifest not found" string from rollback.

list and vendor --check go through read_manifest and report the contract's manifest_unreadable correctly. The contract (CLI_CONTRACT.md#L1291-L1293) defines manifest_not_found as "doesn't exist" and manifest_unreadable as an I/O error reading the manifest.

Proof by execution. I used a debug build at 9c43dfc, ran every command under env -i … --json, and ran the whole set twice with identical results. There were two fixtures: .socket as a regular file (ENOTDIR), and .socket/manifest.json as a symlink to itself (ELOOP).

Command	Result
apply	status: noManifest, exit 0
apply --check	status: noManifest, exit 0
vendor	status: noManifest, exit 0
repair, remove <purl>	manifest_not_found, exit 1
rollback	{"error":"Manifest not found"}, exit 1
list, vendor --check	manifest_unreadable (Too many levels of symbolic links), exit 1

The pinned test, apply_with_unreadable_socket_dir_fails_closed,`` uses a chmod 000 .socket/ (EACCES) fixture. It self-skips as root, which is why I reproduced the bug with ENOTDIR and ELOOP instead.

Symptoms

No open issue. The test's own comment states the impact: install hooks and CI steps run apply --silent and read exit 0 as "patched".

Impact

apply and vendor fail open. Every patch in a project whose .socket/ can't be traversed is silently left unapplied with a success exit; the triggers are a root-owned or ACL-restricted .socket/ on a CI runner, a symlink loop, or .socket checked in as a file. The three other commands fail closed but with the wrong code, and their remedy text points at a missing file. Small fix, real CI consequence.

Proposed change

• Add one core probe next to read_manifest, for example manifest::probe(path) -> Result<Presence, io::Error> (or reuse read_manifest's Ok(None) directly), with the same NotFound-only rule.
• Delete the five metadata(&manifest_path).await.is_err() probes and route those commands through it:
  • a non-NotFound error becomes manifest_unreadable (exit 1) on apply, apply --check, vendor, repair, remove and rollback;
  • a real NotFound keeps today's behavior: noManifest on apply/vendor, the hosted/vendored-trace fallbacks on repair/remove/rollback.
• Un-ignore apply_with_unreadable_socket_dir_fails_closed, and add a root-proof variant (ENOTDIR or ELOOP) so the test runs in CI containers.

Size and scope

About 40 production lines across apply.rs, vendor.rs, repair.rs, remove.rs, rollback.rs and manifest/operations.rs, plus about 80 test lines. Out of scope:

• unparseable-manifest codes, which are An unparseable .socket/manifest.json is reported under five different --json error codes depending on the command #931 (same family; this issue is the stat/read half);
• rollback's bare-string envelope, which is Decide: one shape for the --json top-level error (scan and get emit both a string and a {code, message} object) #704.

Acceptance criteria

• grep -rn "metadata(&manifest_path).await.is_err()" crates/socket-patch-cli/src finds nothing.
• With .socket as a file, and with a self-referencing manifest.json symlink, apply, apply --check, vendor, repair, remove and rollback all exit 1 with manifest_unreadable under --json.
• apply_with_unreadable_socket_dir_fails_closed is no longer #[ignore]d, and an ENOTDIR twin runs as root.
• The existing no-manifest tests stay green (apply noManifest exit 0 and its human line; repair's hosted-only skip; remove/rollback ledger-only and hosted-only paths), along with core's read_manifest NotFound tests.

Dependencies

None blocking. It pairs with #931 (one manifest-load error mapping); whichever lands second reuses the other's helper.

[mikolalysenko]

[agent] Triaged as priority:p3 (general CLI, not tied to one ecosystem). It isn't a duplicate, and no open PR covers it. I confirmed it on main (9c43dfc): all five tokio::fs::metadata(&manifest_path).await.is_err() probes are still there (apply.rs:835, vendor.rs:756, repair.rs:67, remove.rs:353, rollback.rs:1044), and apply_with_unreadable_socket_dir_fails_closed is still #[ignore = "RED: …"] at tests/apply/apply_invariants.rs:514. #931 is related but doesn't share the cause: #931 is about the codes for a manifest that can't be parsed, and this issue is about the stat probe. I'm leaving them as separate pieces of work.

---

Generated by Claude Code

[mikolalysenko]

[agent] Re-checked on main @ b762f41. The bug still holds and the code has moved, so here are fresh permalinks. All five probes still treat any stat error as "no manifest":

• apply.rs#L838
• vendor.rs#L912
• repair.rs#L67
• remove.rs#L353
• rollback.rs#L1051

The containment helper merged in #1042 doesn't touch these probes.

---

Generated by Claude Code