chore(cli): drop the unused anyhow dependency

[pawellisowski]

Scheduled dead-code sweep, 2026-09-04. One deletion; the rest of the run is the evidence for what it deliberately spared.

Deleted

anyhow (dependency) — cli/Cargo.toml, and the return type it existed to name in cli/src/main.rs.

Evidence it was unreachable:

• One reference in the whole crate. grep -rEn "\b(use|extern crate)\s+anyhow\b|\banyhow::|anyhow!" src tests build.rs returns exactly one line: src/main.rs:196: async fn main() -> anyhow::Result<()>. No use anyhow, no anyhow!, no Context.
• That return type could not carry a value. main contains no ? operator (0 occurrences in its body), and both of its error paths end in std::process::exit(err.exit_code()), which returns !. So Ok(()) was the only value main could ever produce, and no Err ever reached the runtime's Termination impl.
• Nothing else keyed on it: no reference in .github/workflows/, scripts/, cli-npm/, or cli/tests/ (including lint_gates.rs, which gates several other Cargo.toml and main.rs properties).

Effect: cargo tree -i anyhow now prints nothing for the targets this crate builds, so the crate is no longer compiled. It stays in Cargo.lock as a transitive of the wasm-only wit-* / wasm-metadata crates, which are never built here — that lock entry is not ours to remove.

Behaviour is unchanged. AwareError::exit_code already decided the process's exit status; the returned value never did. Verified against the built binary: --version → 0, agent describe does-not-exist → 7, agent list → 0.

This also brings main in line with CLAUDE.md §Code style, which asks for concrete error types via thiserror — the crate's AwareError — rather than an erased one.

Deliberately spared, with reasons

The whole Rust pub-item hunting ground is structurally empty, and I verified that rather than assuming it. This crate has no library target, so rustc's dead_code lint treats reachability from main as the root set and fires on unused pub items too — and cargo clippy --all-targets -- -D warnings makes that an error. Probe: appending pub fn zzz_dead_probe_fn() -> u8 { 42 } to src/text.rs produced warning: function 'zzz_dead_probe_fn' is never used. So an unreachable pub item, module, struct field or enum variant cannot land here. Baseline was clean before this change.

• cfg(windows) code — the one place dead_code cannot see on Linux. I installed x86_64-pc-windows-gnu + mingw and ran cargo check --target x86_64-pc-windows-gnu --all-targets: clean, both before and after this change. Nothing dead in the ~20 Windows-gated blocks under model_reader_host.rs, pidfile.rs, invoker.rs and friends. All five windows-sys features and all three win32job uses are live.
• The 21 #[allow(dead_code)] items (manifest/agent.rs, manifest/app.rs, manifest/loader.rs, sidecar.rs, app_lock.rs, auth/keychain.rs, lockfile.rs, receipt.rs). Each already carries a written rationale, and each holds up: the manifest fields are what type-check the keys agent-spec.md / app-spec.md publish, and since there is no deny_unknown_fields, deleting a field would stop rejecting a malformed declaration rather than start. NoteKind::Error + CompileNote::error track a contract the app-spec still publishes; keychain::delete_app_secret is a wired-up-call away from closing a real gap, so the missing thing is the call, not the function. Re-litigating these would be churn.
• The #[allow(unused_imports)] facade in registry/mod.rs — a genuine compiler blind spot, so I checked all six names by hand. Index, IndexEntry, VersionEntry, check_subdir_portable, checkout_relative_subdir and portable_subdir_key are each reached through crate::registry:: by at least one caller. Nothing to remove; a previous sweep already took the three that were dead.
• Every other dependency in cli/Cargo.toml has a real use, including the thin ones: rand_core (OsRng in receipt.rs), cssparser and lol_html (the report sanitizer), webbrowser (the OAuth flow). No [features] section exists, so there are no feature flags to strand.
• All 20 atoms under atoms/. Only is-newer-than and at-least are named by an example app, but atoms are resolved dynamically by atom://generic/<id> URI and the library is published content in its own right — exactly the string-keyed reach the sweep is told not to delete.
• Content is consistent. All 79 agents on disk appear in both registry-index.json and registry-catalog.json, with no entry in either pointing at an agent that is gone. All 3,346 skill files are declared by their agent's manifest and every declared skill has a file — a clean 1:1, zero orphans either way. All 10 Blender agent scripts are referenced. All 39 .mjs modules in cli-connection-reader/ are reachable from the package's bin, build.mjs or a test. Every script in scripts/ is invoked by a workflow except regen-nuget-agents.py (see below).
• cli/tests/browser/ — a documented manual pre-PR gate, referenced from viewer_3d.rs and three specs. Not CI, not dead.
• cli-connection-reader/model-provider-v2.schema.json — reachable only from a design doc today, but feat: add isolated RVT connection reader runtime #480 is open on exactly this runtime. Not mine to delete mid-flight.

Two things worth a maintainer's eye (not touched here)

Neither is a deletion, so neither belongs in this PR — but the sweep surfaced them and they would otherwise go unrecorded.

1. 3,207 orphaned SketchUp command docs, and they are orphaned by the CLI's own definition. validate.rs raises W_COMMAND_DOC_ORPHAN for a commands/<stem>.md whose stem is not a key in manifest.commands, and sketchup-2025 (1,589 of 1,684 docs) and sketchup-2026 (1,618 of 1,725) trip it wholesale. It is a naming drift, not dead content: the docs carry a module prefix the manifest keys drop (geom-bounding-box-add.md vs key bounding-box-add), and Ruby's ? becomes -q in the key but is dropped in the filename (array-on-line.md vs array-on-line-q). ~930 of them match a key after stripping one leading segment. Critically, the prefixed file is the only doc for that command — bounding-box-add.md does not exist — so deleting them would destroy real documentation. The fix is a rename on one side or the other, and it needs someone to decide which side is canonical. Meanwhile 1,337 declared commands per agent have no doc at all.
2. scripts/regen-nuget-agents.py is referenced by nothing — no workflow, no doc, no script — and hardcodes cli/target/release/aware.exe plus a bin/Debug/net10.0/ sidecar path, so it is stale as well as unreferenced. But a maintenance script a human runs by hand is reachable by a human, which is not something a sweep can disprove. Left alone deliberately; delete it if it has served its purpose.

Gates

Run from cli/ on the pinned 1.95.0 toolchain, with CI's apt packages (clang libsecret-1-dev libdbus-1-dev pkg-config) installed:

• cargo fmt --all -- --check — pass
• cargo clippy --all-targets -- -D warnings — pass
• cargo test — pass, 1,195 + 1 unit and every integration binary green, 0 failed
• cargo check --target x86_64-pc-windows-gnu --all-targets — pass (extra, not a CI gate)

🤖 Generated with Claude Code

https://claude.ai/code/session_01QVFTHfkqpjZHNusWXEaTXT

---

Generated by Claude Code

[pawellisowski]

@codex review

---

Generated by Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-04T02:30:00.184258Z	175bf35	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Chef's kiss.

Reviewed commit: 175bf35593

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".