Agent Skills: Hyperconsciousness operations

Hyperconsciousness operations

Treat HC as encrypted storage with explicit trust boundaries, not as a folder copier. Establish the live device, store, binary, and permission scope before acting.

Install this skill into the standard Claude, Codex, active Hermes home, Pi, and screenpipe roots with scripts/install-agent-skill.sh on Unix/macOS or scripts/install-agent-skill.ps1 on Windows. Installation teaches an agent how to operate HC; it does not grant that agent access to a brain.

Establish current truth

1. Run scripts/hc-doctor.sh [store] on Unix/macOS or scripts/hc-doctor.ps1 [-Store path] on Windows.
2. Inspect running process arguments. Do not assume a process uses ~/.brain; --dir may select an isolated store or workspace projection.
3. Read hc status --dir <store> and hc peers --dir <store>. A configured peer is not proof that the peer is online or continuously syncing.
4. Distinguish the encrypted brain store from a projected human-readable directory. A watcher synchronizes the projection only when its process and workspace watch-status are healthy.
5. When source code is involved, inspect the live worktree and binary hash. Do not claim a deployed binary contains uncommitted or newer source merely because that source exists elsewhere.

Choose the narrow operation

• Inspect: use status, peers, grants, audit, files, and workspace watch-status. These do not establish remote liveness by themselves; also check the process and transport.
• Append a durable learning: use the standard note kind and a durable-learning tag so ordinary reads and existing note grants can find it, for example hc write '<stable key and compact conclusion>' --kind note --tags durable-learning,<topic> --sensitivity personal --dir <store>. The current CLI treats hc write --help as literal note text, not help. It also omits custom kinds from hc read, so do not invent a durable-learning kind merely to classify the record. Because the log is append-only, deduplicate the stable key before writing and verify it through the same read or grant path consumers will use.
• Sync trusted devices: run hc sync [peer] --dir <store>, then read status on both devices and compare every author head. Sync is successful only when both views agree; command exit alone is weaker evidence.
• Repair bytes: use ordinary sync first. For pinned archives, use hc blobs verify, then sync --strict; never hand-copy ciphertext into live object paths.
• Project a directory: preview with workspace status, use checkpoint for unattended non-destructive capture, and require explicit human approval for deletions or conflict resolution.
• Connect an AI: create a narrow, expiring grant and run hc mcp --as <grant>. Never give an agent the brain key. Verify the agent can see an allowed record, cannot see a withheld record, and that hc audit records the read. For a large result set, keep the semantic filters unchanged and pass next_cursor into the next search or recent call; page and excerpt sizes may change. Do not raise the whole-response budget merely to continue. A cursor is not authority: every page must still fail after grant expiry or revocation.
• Use a credential without disclosing it: keep credential bytes in a purpose-built local adapter backed by Keychain, TPM storage, an HSM, or a remote vault. HC stores only an encrypted random reference and a closed operation list. Register the exact local executable with hc secret adapter set <adapter> <absolute-program>; each node independently pins its canonical path and BLAKE3 digest, so adapter configuration does not sync. Add the opaque reference with secret register, preferably inside a separately keyed space when its name or operation list is sensitive. Use secret grant for a short USE-only capability or let request_access ask the owner for one exact use_secret call. READ, WRITE and SEND must never imply USE. Require undeclared operations, replaced adapters, changed one-time arguments and revoked grants to fail. Audit must show paired secret_use_started/secret_use_finished receipts containing opaque ids, operation and outcome but no hashes or plaintext of parameters, results, stderr or credential bytes. A start without a finish is an uncertain external effect, not permission to retry automatically. Do not run authority harden on a live endpoint until every standing connector grant and OAuth credential has been inventoried: hardening intentionally invalidates them.
• Connect a remote client: expose serve-http --as <grant> over node-owned TLS. This repository ships the HTTP/OAuth server, not a mobile application. Bearer clients can disclose their returned plaintext to the model provider. DPoP clients must keep the bound private key separately protected. Test redirected startup output: it must name private credential files without printing credentials. Give separate agents separate narrow grants.
• One-time access: request_access queues an exact protected operation; access_status only observes it. Approval requires a separate owner client and credential. There is no bundled approval UI or enrollment page. Never give an owner credential to an agent, model provider, or relay. Verify the requested tool, exact arguments, and scope before approval. A short-lived grant permits one matching call; changed arguments must fail without consuming it, and a repeated call must fail after consumption. Revocation and expiry remain enforced. A successful push submission is not proof that an owner saw or approved a request.
• Recover: verify a kit before any incident. For a complete non-destructive proof, create a personal bundle plus one bundle for each named space, then run recovery drill against the live store. It requires the exact current key set and exact historical signed heads, decrypts and hashes all referenced file bytes, and removes its fresh file-only identity on success or failure. After a forced termination or machine restart, run hc recovery cleanup; it removes only private exactly marked stale drill attempts and fails closed around suspicious paths. Never overwrite a working store as a recovery test.

Use a third-party keyless storage provider

Use this when the owner wants S3, R2, B2, MinIO, Wasabi, Garage, or another S3-compatible provider to hold large encrypted bytes without enrolling that provider as a brain device.

1. Establish the exact personal brain or separately encrypted space. Configure its remote with hc remote <endpoint> <region> <bucket> <prefix> <key-id> --secret-file <private-0600-file> [--space <name>]. The resulting private remote file is storage authority only. It must never contain, derive, or be confused with a brain key, device identity, recovery phrase, grant authority, or provider plaintext access.
2. Run hc push [--space <name>], then pull on a separate enrolled test store and verify signed heads and restored hashes. A successful push is not a restore test. A bucket is never the live append-only log.
3. For local-space release of one existing version, run hc blobs offload <name> remote --json [--version n] [--space <name>]. This first command is read-only. Require target.kind to equal keyless_object_storage, inspect every blocker and retain the returned apply.arguments array without converting it into shell text.
4. After explicit approval, execute only that exact argument array. Apply must recompute the plan, upload signed log objects and missing selected ciphertext chunks, require a fresh complete content-address plus size inventory, persist remote_proved, and only then evict exact local loose ciphertext while policy remains metadata. Route, prefix, account, version, retention, or inventory drift invalidates the old plan.
5. Treat the receipt as a point-in-time storage claim, not an integrity scrub or permanent durability. The provider still sees account, IP, object keys, sizes, timing, and access patterns and can delete, withhold, roll back, or suspend access. Pulled objects remain untrusted and must pass normal signature, size, hash, pack, and log verification.
6. Keep an independent archive or recovery medium. Prove retrieval into a fresh destination and compare the whole-file hash. Never delete history, recovery material, or the only remaining ciphertext copy merely because a listing succeeded.

Do not run relay listen as a storage service. The rendezvous relay is bounded ephemeral transport and retains no vault objects. Do not give the provider a brain key merely to let it enforce grants; permission interpretation belongs on a trusted key-holding node.

Bound a device cache without deleting history

Use this for a laptop or phone that should expose a large brain without keeping every ciphertext byte locally. This is cache eviction, never signed-history garbage collection.

1. Keep at least one independent recovery source: preferably a key-holding archive on blobs pin all, or a keyless remote plus separately verified recovery material. Keep the constrained device on blobs pin metadata. Run blobs verify on a key-holding archive before treating it as a recovery source; a bucket inventory cannot replace that scrub.
2. Inspect hc files --json and hc blobs status --json. Select one exact logical file and version. Do not infer importance from entropy, embeddings, filenames, recency, or an agent score.
3. Produce a read-only hc blobs offload <name> <peer|remote> --json plan, obtain approval, and execute only its returned apply.arguments. Failed target proof, route drift, policy drift, or local inventory drift must leave every selected local byte intact.
4. Prove transparent recovery with hc get <name> <fresh-destination> <preferred-peer> --dir <store> for a peer, or hc pull followed by a separate get for a keyless remote. Compare the whole-file hash, then run blobs verify on a key-holding archive again. Never restore over a live source file.

The current CLI has no automatic byte budget, LRU optimizer, keep/unkeep list, or whole-cache keyless eviction command. Do not invent blobs cache, blobs optimize, blobs keep, or blobs unkeep. Report that boundary and use the explicit single-file plan/apply path until those commands exist.

Inventory is physical ciphertext, including duplicate loose and packed representations. Packed eviction is copy-on-write, so it may temporarily need space for old and replacement packs. Successful human-facing reads refresh recency; verification does not. Proof is point-in-time and one archive is not durability: keep independent archives or recovery media. A key-holding archive must reject an otherwise valid signed history that cannot decrypt with its brain key; signature-only acceptance is reserved for an intentional blind relay.

For isolated physical tests, create fresh stores and candidate binaries under explicit temporary paths; never point a test peer command at a default live store. An SSH remote command must include both the candidate binary and its --dir <temporary-archive> before the transport appends serve. On Windows, OpenSSH may terminate a detached child after the launcher exits; keep a test listener in a supervised foreground session or forward to its loopback port, then stop and verify the exact PID and ports. Set BRAINMESH_NO_KEYSTORE=1 only for a newly created test directory when the Windows credential manager cannot answer; never use it to guess around an existing identity.

Archive a live screenpipe database

Use this when screenpipe must remain live while an encrypted historical copy is held by another hc device without a permanent second database-sized copy on the source.

1. Never hardlink, reflink, clone, or directly copy db.sqlite and its WAL into HC. Plaintext and encrypted ciphertext are different bytes, and only screenpipe owns the transactional snapshot boundary.
2. On the intended always-on archive node, set hc blobs pin all --dir <store>. On the screenpipe machine, require hc blobs pin metadata --dir <store>. Skill installation or pin-policy inspection does not grant brain-key access.
3. Prove an ordinary metadata sync and compare signed heads on both devices. Then run hc screenpipe archive <peer> --dir <store>. Use --port only for a known non-default local screenpipe port and --staging only for a private local volume with enough temporary space.
4. The command must obtain screenpipe auth token only through a captured pipe, keep it in zeroizing process memory, and send it in the loopback HTTP header. Never place the token in curl, process arguments, logs, a hc record, or durable memory.
5. Require the archive readiness handshake, signed-record offer, bounded chunk upload, and final exact manifest inventory to all succeed. A failed command must retain the named consistent snapshot for inspection or retry and must not evict local ciphertext.
6. Verify hc history screenpipe.sqlite --dir <store> names the new version and check the archive node with blobs status and, periodically, blobs verify. Steady state on the source is the live screenpipe database plus metadata, but version one temporarily needs one plaintext snapshot and one encrypted cache. Packed chunks shared with other manifests are not deleted by this workflow.
7. Prove recovery into a separate path with hc get screenpipe.sqlite <destination> <peer> --dir <store> and run sqlite3 <destination> 'pragma integrity_check;'. Never restore over the live database. Replacing a screenpipe database requires screenpipe to be stopped, a retained original, and a separate explicit recovery decision.

Ingest an existing brain and agent skills

Use distinct workspaces for the human-readable brain and for each device/runtime skill tree. Do not flatten Claude, Codex, Hermes, shared-agent, Gemini, and screenpipe roots into one directory: symlinks and duplicated names make that ambiguous, while device-qualified workspace names preserve provenance without manufacturing conflicts.

1. Inventory source bytes, free disk, Git state, secret-shaped filenames, symlinks, generated trees, the exact HC store, and every reachable configured peer before writing. A historical author with no configured, reachable route remains unverified.
2. Preview every source with workspace status <name> <folder> --summary. Workspace traversal already excludes .git and .brainmesh, skips symlinks, and blocks credential-shaped filenames. Use a checked-in .brainmeshignore for additional generated dependencies, builds, and machine caches. Its rules are literal files/directories only; never paste Git globs or negation into it.
3. When legacy Git clones differ, prove the chosen canonical head is a strict superset before treating it as primary. Preserve every remote uncommitted or untracked non-secret file in a one-time device-qualified workspace before a pull, branch change, or projection materialization. Keep deletions as an explicit manifest. Do not overwrite or silently discard divergent work.
4. Run workspace checkpoint ... --skip-secret-files --summary, then workspace verify ... --skip-secret-files against the same source folder. Checkpoint is non-destructive and defers files that change while read; rerun it until no eligible changes remain.
5. Give one intended always-on archive node blobs pin all; keep ordinary clients metadata unless the user requests another full copy. First sync signed history everywhere. A sync initiated by a metadata node may deliver all records without filling the archive, so run ordinary sync from the pin all node and require blobs status to reach zero missing chunks. Finish with blobs verify on the archive.
6. Same-subnet addresses are not proof of a usable direct route. Test the exact private address first. If a temporary listener is justified, bind only that address, never a wildcard, and close it after transfer. Fall back to the authenticated tailnet route when client isolation rejects LAN traffic.
7. Compare every signed author head on all reachable stores and prove an exact restore/read. Matching record counts alone are insufficient.

The store-scoped sync service moves encrypted history and chunks only. It does not notice future edits in the human-readable brain or skill folders. Ongoing source ingestion requires separately tracked projections and healthy workspace watchers (or an explicitly designed sequential checkpoint scheduler); report that boundary instead of calling a one-time checkpoint continuous sync.

Prove recovery without mutating the live brain

1. Put the kit, phrase file, and bundles on the intended independent backup media. Keep the phrase file separate from the kit after the test. Never pass the phrase itself as an argument or print it in diagnostics.
2. Create the personal bundle with hc bundle <personal.bundle> --dir <store>. For every current space named by hc spaces, create a separate hc bundle <space.bundle> --space <name> --dir <store>.
3. Run hc recovery drill <kit> <personal.bundle> --space-bundle <name> <space.bundle> ... --phrase-file <phrase-file> --dir <store>.
4. Require a successful exact-head proof, zero missing/damaged chunks, and the final temporary-identity-removed message. A valid-but-stale kit or bundle is a failure, as is any omitted or repeated space bundle.
5. Keep full-disk encryption enabled on the drill host. Temporary files are deleted, but SSD, swap, snapshots, and copy-on-write storage do not offer reliable secure erasure. The host briefly holds every recovered key.
6. If the drill process was killed or the host restarted, run hc recovery cleanup before the next proof. Require either a removal count or zero; an unsafe-attempt error requires manual inspection, not broad deletion.

For an actual disaster, restore only into a fresh store, import the personal bundle, import each space bundle with --space <name>, verify a separately held recovery witness, then create and verify a successor kit. Do not delete or overwrite the old artifacts during the proof.

Make sync continuous

1. Prove one foreground sync over the exact intended transport before creating a service. A tailnet listener should bind only the device's tailnet address, not 0.0.0.0; an SSH route must work with BatchMode=yes and no prompt.
2. Configure at least one real peer in the exact store. A five-minute job that runs hc sync against an empty peer list is healthy as a process but does not replicate anything.
3. Install the store-scoped outbound scheduler with hc service install --interval 300 --dir <store>. It runs sync --require-any before registration and refuses an empty or entirely unreachable peer set. Read back hc service status --dir <store>; require both registered true and healthy true after the first run.
4. For rollback detection through the last locally observed heads, create a witness on independent storage with hc witness create <external file> --dir <store>, verify it, then add --witness <external file> to service install. Never place it inside the protected store or silently choose a cloud/volume for the user. A missing, read-only, stale or concurrently replaced witness makes the scheduled result unhealthy after sync; uninstall preserves it. This is a durable local lower bound, not proof that an observed peer disclosed records this device has never seen.
5. The CLI uses launchd on macOS, a systemd user timer on Linux and Task Scheduler on Windows. Windows is intentionally an interactive-user task and pauses while that user is logged out. An always-on Linux user service may require an administrator to enable lingering; do not claim logged-out coverage without testing it.
6. A listener is separate from outbound sync. Supervise it only on a device that must accept inbound sessions, bind only its tailnet or loopback address, and verify the actual socket plus manager state. Do not create a public or wildcard listener as a side effect of service installation. The direct TCP listener admits 64 active workers globally, eight per observed source and 120 new workers per source per minute before brain-key proof; its 4,096 source windows reset on restart. A proxy collapses clients into one source. Treat these as local resource bounds, not public DDoS protection.
7. Trigger each scheduler after peers are configured, then foreground-sync every route once more and compare all signed author heads. A service state, last exit code, or reachable port alone is not convergence evidence.
8. Test the partial-availability case: with at least one peer reachable and one route unavailable, hc sync --require-any --dir <store> must exit zero after the complete session. Unix exit 141 means a closed child SSH pipe escaped as SIGPIPE and the scheduler is not reliable. --strict is the separate all-routes boundary.
9. Replacing the installed binary intentionally makes service status report binary matches false. After hash read-back and rollback staging, rerun the same service install --interval ... --dir ..., trigger it, and require registered, binary-matching, configuration-matching and healthy state. On Windows PowerShell/.NET, System.IO.File.Replace requires an explicit backup path in this environment; passing $null as the third argument can fail with The path is not of a legal form. Verify candidate and predecessor hashes, then use the intended rollback path as that argument.

Use hc service uninstall --dir <store> to remove only the scheduler. It preserves the brain and macOS diagnostic logs. Never delete the store as part of service troubleshooting.

Do not replace or restart a healthy projection watcher merely to update an unrelated CLI path. Identify its exact binary and store first, stage a rollback binary, and preserve workspace watch-status before and after any restart. On macOS, a launchd job can remain running while privacy-gated Documents access is blocked inside open(2); require the expected listening socket or a new successful watcher generation, not manager state alone. If the same command works interactively, treat that as a privacy boundary. For a disposable validation projection, an APFS clone under Library/Caches is acceptable; a real human workspace needs explicit user-granted access or a user-selected non-protected path. Tracking is bound to the exact folder path, so verify and run workspace track again after an intentional relocation, then require one fresh full watcher cycle.

For a native-event latency proof, use a harmless unique file in a disposable tracked projection and preserve it as history. Record source creation and destination materialization times, require exact bytes, inspect both alternating watch-status slots, and prove full: false with one checkpointed source event and one materialized destination event. Test both directions. Then run full workspace verify on both folders. A source event that samples in plan_with_keys -> local_files -> digest is still hashing the entire vault; an incoming record that waits for --interval is not event-driven. Watch only the store's encrypted log/ subtree for remote wakeups, never projection/status files, and keep the polling plus bounded full-content audit as the correctness backstop. On macOS canonicalize /var and /private/var watcher roots before classifying events. Multi-megabyte projection cursor JSON must be buffered; a raw serde_json::from_reader(File) can turn one cursor read into millions of small syscalls under launchd.

Preserve the security model

• Keep brain stores outside iCloud, Dropbox, OneDrive, and similar syncing folders. Never bypass the synced-folder guard for a real store.
• On Unix, an unsafe key-mode error is a hard stop. Resolve the exact identity path read-only, require a regular non-symlink owned by the expected OS user, then tighten that exact file to 0600 without reading or copying its bytes. Rerun status afterward. Never recreate a key merely to clear the error.
• Do not print, copy, log, or place brain keys, recovery phrases, bearer tokens, bucket secrets, invitations, or raw private records in prompts or process arguments.
• Treat redirected stdout and stderr as durable logs. After installing or restarting serve-http, search its captured startup output for the actual pairing bearer and fail the deployment if it appears; do not paste the bearer into the diagnostic command or its report.
• Treat each store's peers file as private local routing configuration. Do not put passwords or bearer tokens in a peer command; after changing routes, verify the file is a regular non-symlink and mode 0600 on Unix.
• Use grants for agents and people. Scope by workspace/path, kind, tag, sensitivity, action, and expiry; default to read-only and short-lived.
• Treat revocation as future access control. A recipient may retain plaintext already disclosed, and an offline former member may retain old keys.
• Never infer “all devices are synced” from device enrollment, peer config, Tailscale presence, a service process, or matching record counts alone. Compare signed author heads and verify required blobs/projections.
• Do not start a listener on a public interface without authentication and an explicit network boundary. Prefer a tailnet; keep TLS termination on the trusted node for public routes.
• Do not delete stores, peers, grants, projections, quarantine evidence, or recovery artifacts without explicit approval and an exact target.

Verification gates

For a cross-device change, report each gate separately:

1. device reachable;
2. expected binary present and hash/version identified;
3. expected store opens with protected keys;
4. transport process is live, if continuous operation was requested;
5. signed author heads converge after sync;
6. required blobs pass verification;
7. workspace projection has no missing blobs or unresolved conflicts;
8. a restore/read test returns exact expected bytes;
9. agent access is grant-scoped and leaves a receipt.

If a gate was not run, call it unverified. Never convert unavailable access or a failed command into a healthy result.

Development validation

npm CLI release

The npm package is currently a source-built preview: installation compiles the exact packaged Rust source with Cargo and places only the resulting executable under the package-local .hc-bin/<platform>-<arch>/ directory. It must not read or write ~/.brain, create an identity, install a service, or import any local runtime state. Keep the npm and Cargo versions identical.

Release the exact audited tarball, never the live directory:

1. Run npm test, then npm pack --dry-run --json and inspect the complete whitelist. It should contain only Cargo inputs, the license/readme, npm launcher/build scripts and src/.
2. Run npm pack --json, record its shasum and integrity, and reject tar members containing .brain, .npmrc, .git, target, tokens, secrets, or private-key-shaped filenames.
3. Install that .tgz into a fresh temporary npm prefix. Require hc --version to equal the package version and hc --help to start successfully. Do not run a stateful command merely to test packaging.
4. Verify the publisher with npm whoami. Refresh authentication through npm's browser flow; never request or print a registry token.
5. Publish the already tested file with npm publish ./hyperconsciousness-<version>.tgz --access public. Do not use npm publish ., because it repacks the current checkout and can diverge from the audited artifact.
6. Read the full public npm view hyperconsciousness@<version> --json object and compare dist.shasum and dist.integrity byte-for-byte with the local pack result. Dotted field selections are returned as flattened keys and are unsuitable for a nested-object assertion.
7. Install hyperconsciousness@<version> from the public registry into a second fresh prefix, rerun --version and --help, and verify the intended dist-tag.

The source build requires Rust 1.88 or newer. Linux users also need pkg-config, OpenSSL development headers, and D-Bus development headers. Until first-party native artifacts exist for every supported target, do not replace this with a macOS-only binary or call the npm package zero-dependency.

When changing the Rust implementation, preserve unrelated dirty work and run:

cargo test --release
cargo clippy --all-targets --release -- -D warnings -A clippy::too_many_arguments
cargo check --release --target x86_64-pc-windows-msvc --features blake3/pure
git diff --check

A fresh Debian or Ubuntu native builder needs build-essential pkg-config libdbus-1-dev; the Linux Secret Service keyring backend will otherwise fail in libdbus-sys before HC compiles. Treat installing build prerequisites as environment setup, then rerun the unchanged exact-source archive.

A rustup minimal toolchain omits Clippy; install the matching official component with rustup component add clippy before treating the lint gate as available. A missing component is not a passing lint result.

Use native OS/physical-device tests for claims that a cross-target build cannot prove. Do not call simulator, emulator, VM, or cross-compile coverage a physical device pass.

For identity-key persistence changes, require the old-or-new publication tests on native Windows as well as Unix: replacement must change the complete 32-byte value without exposing a truncated named file, new-key publication must refuse an occupied destination, and ordinary completion must leave no private part file. A Windows cross-target compile proves only that ReplaceFileW and MoveFileExW bindings type-check; it does not prove the filesystem behavior.

For recovery-witness replacement changes, require native Windows and Unix tests that prove a complete successor atomically replaces the expected predecessor, a stale expected id cannot publish, and a successor cannot drop an author or move a head backwards. Cross-target compilation proves only that ReplaceFileW type-checks. For service integration, generate and inspect launchd, systemd and Task Scheduler arguments containing spaces and manager metacharacters; retain byte-exact version-1 configuration rendering so an existing service does not become unhealthy merely because the binary learned manifest version 2.

For an exact native Windows source validation, transfer every compile-time input, including Cargo.toml, Cargo.lock, src/ and tests/, then compare a source manifest or digest before building. Extract into a new empty validation directory when proving exactness; an archive hash proves the bytes transferred, not that an overlaid checkout has no stale compile inputs. Build the manifest with tracked and untracked compile inputs rather than git archive; current source patterns are Cargo.toml, Cargo.lock, src/** and tests/**. When creating a portable tarball on macOS, set COPYFILE_DISABLE=1, pass tar --no-xattrs, count the listed regular files, and reject any ._ AppleDouble members before transfer; otherwise Windows can extract a metadata sidecar for nearly every source file and invalidate the clean-source count. PowerShell's $ErrorActionPreference = "Stop" does not make a failing native tar.exe, certutil.exe, or Cargo invocation throw: check $LASTEXITCODE after every native command before continuing. Separately, after invoking another PowerShell script with &, check $? immediately; $LASTEXITCODE may still contain a successful nonzero code from an earlier native tool such as robocopy and falsely report that the script failed. Conversely, Cargo's ordinary stderr progress can become a terminating NativeCommandError when stderr is redirected through a pipeline under Stop; temporarily use Continue around that invocation, capture $LASTEXITCODE immediately, then restore Stop. In noninteractive Windows sessions, a stale RUSTC_WRAPPER or CARGO_BUILD_RUSTC_WRAPPER may point to an unavailable sccache shim; clear only those wrapper variables for the validation process and record that exception rather than changing the user's persistent environment.