Run the managed/persistent GuruConnect agent as a LocalSystem Windows
service so it is reachable at the login screen and across reboots, and
so the SPEC-016 per-machine cak_ store (ACL-restricted to SYSTEM +
Administrators) is finally readable in-context.
Phase 1 scope (host + lifecycle only):
- New agent/src/service/mod.rs: registers "GuruConnectAgent" with the
SCM via the windows-service dispatcher, reports a correct lifecycle
(StartPending -> Running -> StopPending -> Stopped), handles
Stop/Shutdown via an AtomicBool the agent loop polls (graceful WS
close), and provides install/uninstall/start (LocalSystem, AutoStart,
sc-failure crash recovery). Idempotent install/uninstall.
- main.rs: hidden `service-run` subcommand routes the SCM-launched
process into the dispatcher; new run_managed_agent_service() runs the
existing RunMode::PermanentAgent logic (resolve/enroll cak_, hold the
relay) as SYSTEM. run_agent() now takes an optional SCM shutdown flag,
skips the HKCU Run autostart and the tray when run as the service, and
interrupts the reconnect backoff promptly on stop. An interactive
launch of a managed binary now installs+starts the service and exits
instead of double-running.
- install.rs: a managed install (embedded config present) installs the
LocalSystem service as the single autostart and removes the legacy
HKCU Run entry; uninstall stops+deletes the service (idempotent).
Attended/viewer installs are untouched.
- Kept the SPEC-016 Phase B fail-fast guard as a harmless safety net for
any non-SYSTEM invocation; updated its comment to name this service as
the managed run context.
Phase 2 NOT built (seams documented): session broker, per-session
capture/input worker, CreateProcessAsUserW token handoff, service/worker
IPC, and SERVICE_CONTROL_SESSIONCHANGE. Phase 1 enrolls/connects as
SYSTEM but does not capture a desktop (a Session-0 process cannot).
No service is installed/started on the dev host; that is a VM/admin
integration step. fmt + clippy -D warnings + release build + 55 tests
all pass.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
CI never ran clippy on the agent crate (the build-server clippy job is
Linux-only and can't compile the Windows agent; build-agent only runs cargo
build), so 77 clippy -D-warnings errors had accumulated. Behavior-preserving
cleanup, code-reviewed APPROVED, locally verified (cargo clippy --workspace
--all-targets --all-features -- -D warnings exits 0; cargo test --workspace =
57 passed).
- let _ = on Win32 resource-teardown BOOL returns (gdi.rs); fallible
BitBlt/GetDIBits stay error-handled
- removed unused imports/vars; idiom fixes (div_ceil, is_null, transmute
annotations, match collapsing, useless_conversion)
- #[allow(dead_code)] + comment on genuine Task-6/7 scaffolding (vk consts,
SpecialKey emission, SAS mgmt API, modifier tracking, GDI frame-diff fields)
- Cargo.lock: cargo pruned ~147 stale transitive entries (no version changes)
Follow-up: add cargo clippy -D warnings to the build-agent CI job so the agent
crate stays clippy-clean.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
First run of the build-and-test CI gate (cargo fmt --all -- --check) surfaced
pre-existing formatting drift across the agent and server crates. Apply rustfmt
across the workspace so the codebase meets its own CI gate. Pure formatting; no
logic changes.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Brings azcomputerguru/guru-connect up to the authoritative working copy that
had been maintained in the claudetools monorepo: Phase 1 security and
infrastructure (middleware, metrics, utils, token blacklist, deployment
scripts, security audits) plus the native-remote-control integration spec.
Preserves the repo .gitignore, .cargo, and server/static/downloads.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
