t3-resource-monitor samples every process on the machine every 5 s with no live subscriber and cannot be turned off

[SkiTee3000]

What happened

With the diagnostics panel closed and no client connected, the bundled t3-resource-monitor keeps enumerating every process on the machine every 5 s, holds ~280–290 process handles permanently, and uses ~1.3% of a core around the clock. There is no setting, flag, or environment variable that turns it off.

Diagnosis

• resolveNativeSampleIntervalMs (apps/server/src/resourceTelemetry/NativeTelemetryClient.ts) returns 5 s when there is no live subscriber (UNKNOWN_BACKGROUND_SAMPLE_INTERVAL_MS, also on battery), and 15 s only when the host is locked, in low-power mode, or thermally constrained. It never returns "off". docs/internals/resource-telemetry.md says the server "requests continuous snapshots only while diagnostics has live subscribers"; the code does not match that.
• Each sample calls refresh_processes_specifics(ProcessesToUpdate::All, ...) (native/resource-monitor/src/main.rs:419) and walks every process on the machine (~440 here) to find the T3 subtree. On Windows sysinfo opens a handle per process and, on discovery, reads its command line out of the remote process, so the monitor reads processes it does not report on, including a running game. Only the T3 tree is sent to the server.
• The only related config is resourceMonitorPath, which is internal. Nothing in Settings, t3 serve --help, or T3CODE_* disables the collector.

Steps to reproduce

1. Start the desktop app on Windows, close the diagnostics panel or disconnect all clients.
2. Watch t3-resource-monitor.exe in Process Explorer: handle count, CPU, and OpenProcess / ReadProcessMemory activity every 5 s.
3. Lock the screen: the interval becomes 15 s; nothing stops it.

Expected: no sampling without a live subscriber (as documented), or a setting to disable native telemetry; enumeration limited to the T3 process tree.
Actual: whole-system sampling every 5 s for the life of the server.

Version

0.0.41-nightly.20260908.1414 (desktop); code unchanged on main @ 211618f.

Environment

Windows 11 Pro 26200, desktop app hosting the server.

Evidence

Process Explorer over several hours: ~281–293 handles held by t3-resource-monitor.exe, ~1.34% CPU steady, a sample every 5 s (15 s while locked).

Related issues

#4182 / #2679 replaced the process-diagnostics polling on the server side; this is the native collector that remained. #9661 item S16 covers a separate one-second process-table poll for idle terminal prompts. #7736 and #9837 are about the collector not starting on Linux.

Fix applied or workaround

None found. Deleting the binary would stop it, but the server then logs a failed collector on every start.

Filed by

Claude Code (Claude Fable 5.1), following the t3 triage playbook from a checkout of main.

[juliusmarminge]

Triage

Confirmed on main @ 211618fd9. This is a real Windows idle-cost / process-inspection bug, not a misread of Process Explorer.

What the code actually does

Two different “on” switches:

1. Streaming to diagnostics is demand-gated. ResourceTelemetry only attaches nativeClient.snapshots while a client is subscribed (acquireLive / releaseLive). That sends setStreaming: false when the panel is closed. Electron app.getAppMetrics() is also live-only.
2. Native sampling is not demand-gated. resolveNativeSampleIntervalMs returns 5 s with zero subscribers (UNKNOWN_BACKGROUND_SAMPLE_INTERVAL_MS), 1 s with a subscriber, and 15 s only when the host is locked, in low-power mode, thermally constrained, or suspended. It never returns “off”. The sidecar still walks the process table and records bounded in-memory history so the panel can fetch history on demand.

docs/internals/resource-telemetry.md is easy to over-read. “Requests continuous snapshots only while diagnostics has live subscribers” describes the server stream, not the collector. The native child is designed to keep sampling for history (#8187 explicitly kept a 5 s background cadence).

Each sample still does refresh_processes_specifics(ProcessesToUpdate::All, …) (native/resource-monitor/src/main.rs). On Linux, #9768 already split this: cheap CPU discovery for everyone, then memory / disk / command line only for the T3 tree, and that detail System is dropped. On Windows and macOS, discovery uses the full refresh kind (with_memory, with_disk_usage, with_cmd(Always)) on a persistent System, which matches the ~280 handles, OpenProcess / ReadProcessMemory of unrelated processes (including games), and ~1.3% of a core. Only the T3 tree is sent upstream.

There is no user-facing off switch. resourceMonitorPath / T3CODE_RESOURCE_MONITOR_PATH only pick the binary. T3CODE_TELEMETRY_ENABLED is PostHog product analytics. Background-activity profiles do not change this interval. The protocol already treats sampleIntervalMs: 0 as “stop sampling” (clamp_sample_interval); the TypeScript client never sends 0. Deleting the binary just makes the server log a failed collector on every start.

Related work

• Reduce idle work and disk churn with native resource diagnostics #2679 / [Bug]: Excessive CPU usage on Windows #4182 — replaced the old PowerShell/ps diagnostics poll with this sidecar.
• perf(server): cut idle CPU use and stop provider event leaks #8187 — 1 s → 5 s when nobody is subscribed (intentional history warmup).
• perf(telemetry): reduce idle resource monitoring CPU #5345 — earlier attempt at idle 5 s and tracked-only details; closed as overlapping Reduce idle work and disk churn with native resource diagnostics #2679.
• perf(server): skip unused Linux process detail reads #9768 / Track performance audit fixes #9661 R3 — Linux detail-read cut landed; Windows/macOS still on the old path. Track performance audit fixes #9661 S16 is a different 1 s terminal process-table poll.
• [Bug]: Bundled t3-resource-monitor ships mode 0644, so native process telemetry never starts on Linux/macOS #7736 / [Bug]: Resource monitor binary missing entirely for linux/x64 in WSL runtime (distinct from #7736) #9837 — collector fails to start; opposite symptom.

Not a duplicate of #9661 (tracking epic). This is the user-facing leftover of R3 on Windows, plus the missing kill switch.

Suggested fix

1. Port the Linux two-pass refresh to Windows/macOS so command lines and extra counters are read only for the T3 tree, and unrelated process handles are not held.
2. Decide whether zero subscribers should send sampleIntervalMs: 0 (empty history until the panel opens) or keep 5 s and say so in the internals doc.
3. Optional Settings / env kill switch if we want an explicit off (do not reuse T3CODE_TELEMETRY_ENABLED).

Accepted as a medium Windows performance / privacy-scope bug. No workaround other than not running the desktop-hosted server.