---
name: reference_guru5070_rust_toolchain
description: GURU-5070 has a full Rust toolchain installed BUT a WDAC/Smart App Control policy now blocks running rustc/cargo locally (os error 4551) — build the Windows agent on Beast, not here; toolchain paths + CI gates still valid for reference
metadata:
  type: reference
---

**BLOCKED AS OF 2026-07-04 — do NOT rely on local Rust builds on GURU-5070.** A Windows
Application Control (WDAC / Smart App Control) policy now blocks execution of `rustc.exe`/`cargo.exe`
(and `sops.exe`, `openssl`, `gawk`, Python `cryptography`'s native DLL) — attempts fail with
`An Application Control policy has blocked this file. (os error 4551)`. This is the same policy behind
the "Windows can't confirm who published …" blocks on unsigned binaries. Until the policy is adjusted
to trust the toolchain, **compile Windows agent/GuruConnect changes on Beast** (`guru@100.101.122.4`,
Tailscale; sccache at `C:\sccache`) via a throwaway `git worktree` + `cargo check` — see
[[gururmm-beast-windows-build-host]]. The paths/gates below remain accurate for reference and for when
the policy is relaxed. WDAC impact also breaks the `vault`/`sops` path here (use `age`+Node fallback per
[[feedback_vault_gcm_shadow_auth]]) and silently swallowed error logging (`CLAUDETOOLS_ROOT=D:/claudetools`
wrong-case → `log-skill-error.sh` can't write; real repo is `D:/ClaudeTools`).

As of 2026-05-30, GURU-5070 has the full Rust dev toolchain installed (able to build locally *until the
2026-07-04 WDAC block above*):

- **cargo/rustc/clippy/rustfmt:** `C:\Users\guru\.cargo\bin\` (rustup; cargo 1.96, rustfmt 1.9, clippy 0.1.96).
- **MSVC C++ Build Tools:** VS2022 BuildTools (VCTools workload) — provides the `x86_64-pc-windows-msvc` linker.
- **protoc:** 35.0 via winget. The build.rs prost codegen needs it — **set the env var first:**
  `$env:PROTOC = "C:\Users\guru\AppData\Local\Microsoft\WinGet\Packages\Google.Protobuf_Microsoft.Winget.Source_8wekyb3d8bbwe\bin\protoc.exe"` (also set persistently as a User env var).
- Default target is `x86_64-pc-windows-msvc` (per the repo `.cargo/config.toml`), so this machine builds BOTH
  the server AND the Windows agent — better coverage than the Linux build host, which can't compile the agent.
- **Local gates that mirror CI** (run from the guru-connect dir with PROTOC set):
  `cargo fmt --all`, `cargo clippy --workspace --all-targets --all-features -- -D warnings`,
  `cargo test --workspace`, `cargo build --workspace`. Local rustfmt agrees with CI (verified — no skew).
- **CI gap to know:** CI only runs clippy on the **Linux server** build; the Windows **agent** crate is never
  clippy-checked in CI (let 77 errors accumulate, cleaned up 2026-05-30). Todo to add agent clippy to the
  build-agent (Pluto) job. So: clippy the agent LOCALLY before committing.

**How to apply:** when a Coding Agent works on GuruConnect Rust, have it self-verify with the local toolchain
(set PROTOC, run the four gates, iterate to green) and commit CI-green code — don't delegate fmt/clippy to the
build host. See [[project_guruconnect]].

**CI fmt gate — don't omit it from agent briefs (incident 2026-05-31):** the CI `Build Server (Linux)` job runs
`cargo fmt --check` as a hard gate FIRST (before build/test). SPEC-004 Task 2 + Task 4 (commits ffca7f0, 4e80573)
went red on Linux CI even though the Coding Agents reported "clippy clean, tests pass" — because the briefs listed
only `cargo check` + `clippy` + `test` and NOT `cargo fmt --check`, so rustfmt drift slipped through (compactly-
written new test code). Fixed with a `cargo fmt` follow-up commit (cef1928). **Every Coding-Agent brief that
touches GuruConnect Rust MUST list `cargo fmt --check` (server: `cd server && cargo fmt --check`) as a required
gate alongside clippy/test** — a clippy-clean, test-green change can still fail CI on formatting.
