Repository navigation
t3-resource-monitor samples every process on the machine every 5 s with no live subscriber and cannot be turned off #11222
Description
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.mdsays 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 Windowssysinfoopens 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, orT3CODE_*disables the collector.
Steps to reproduce
- Start the desktop app on Windows, close the diagnostics panel or disconnect all clients.
- Watch
t3-resource-monitor.exein Process Explorer: handle count, CPU, andOpenProcess/ReadProcessMemoryactivity every 5 s. - 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.
Activity
juliusmarminge commentedon Sep 11, 2026
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:
ResourceTelemetryonly attachesnativeClient.snapshotswhile a client is subscribed (acquireLive/releaseLive). That sendssetStreaming: falsewhen the panel is closed. Electronapp.getAppMetrics()is also live-only.resolveNativeSampleIntervalMsreturns 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.mdis 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 (#8187explicitly kept a 5 s background cadence).Each sample still does
refresh_processes_specifics(ProcessesToUpdate::All, …)(native/resource-monitor/src/main.rs). On Linux,#9768already split this: cheap CPU discovery for everyone, then memory / disk / command line only for the T3 tree, and that detailSystemis dropped. On Windows and macOS, discovery uses the full refresh kind (with_memory,with_disk_usage,with_cmd(Always)) on a persistentSystem, which matches the ~280 handles,OpenProcess/ReadProcessMemoryof 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_PATHonly pick the binary.T3CODE_TELEMETRY_ENABLEDis PostHog product analytics. Background-activity profiles do not change this interval. The protocol already treatssampleIntervalMs: 0as “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
psdiagnostics poll with this sidecar.Not a duplicate of #9661 (tracking epic). This is the user-facing leftover of R3 on Windows, plus the missing kill switch.
Suggested fix
sampleIntervalMs: 0(empty history until the panel opens) or keep 5 s and say so in the internals doc.T3CODE_TELEMETRY_ENABLED).Accepted as a medium Windows performance / privacy-scope bug. No workaround other than not running the desktop-hosted server.
perf(server): resource monitor no longer scans every process while idle
t3dotgg commentedon Oct 14, 2026
Note
🤖 Claude Opus 5.5 responding on behalf of Theo
Progress on this issue:
#19399 stops idle sampling. While no client is watching resource data, the server sets the native monitor's interval to 0, which means it samples only on request. Opening Diagnostics brings back the normal rate (1 s, 5 s on battery, 15 s when constrained). On a Linux release build idle for 30 s, the monitor took 0 samples, down from 7. One trade-off: resource history now covers only the time Diagnostics was open.
Still open:
t3dotgg commentedon Oct 14, 2026
Note
🤖 Claude Opus 5.5 responding on behalf of Theo
Reopening. #19399 used "Fixes" by mistake, but it only stops idle sampling. The Windows/macOS process-list work and the terminal's 1 s poll, listed in the comment above, are still open.
t3dotgg commentedon Oct 21, 2026
Note
🤖 Claude Opus 5.5 responding on behalf of Theo
Thanks for the report. One part of this is fixed on main in #19399, #21242 and #19745. Please test on the nightly built from main on 2026-10-21, or on the next stable release. One part is still open: Windows and macOS still use full-detail process refreshes and retain a persistent process list (#18518). If that part still matters to you, please open a new issue for that part only.