Control Panel renders cumulative CPU-seconds as a percentage — "Total CPU" grows without bound (0.11.0, Windows)

Summary

The Control Panel's Total CPU tile and the per-process CPU field render /api/processes's cpu value with a % suffix and a progress bar. That value is not a percentage — it is cumulative CPU-seconds since process start. Because it is a monotonic counter that is never differenced against a sampling interval, the displayed "percentage" only ever increases, and after a few hours of uptime the panel reports figures like 2447.8 %.

Actual CPU usage on the same machine at the same moment was about 5% in total.

Environment

• codebase-memory-mcp 0.11.0
• Windows 11 Home 10.0.26200 (x64)
• Launched as an MCP stdio server from Claude Code; Control Panel served on 127.0.0.1:9749
• Four server instances running across two concurrent editor sessions, uptimes ~2 min to ~18 h

Evidence

1. The field is seconds, and the binary says so

The server's own JSON format strings name the self-stats in seconds but drop the unit on the per-process field:

{"self_pid":%d,"self_rss_mb":%.1f,"self_user_cpu_s":%.1f,"self_sys_cpu_s":%.1f,"processes":[
{"pid":%lu,"cpu":%.1f, ...

2. cpu is exactly user + system CPU-seconds

From a live /api/processes response, for the self process:

"self_user_cpu_s":36.1  +  "self_sys_cpu_s":64.9  =  101.0
"cpu":101.1

The per-process cpu field is the sum of the two _cpu_s fields. It is seconds.

3. It matches the OS's cumulative CPU-time counter

Get-Process on Windows reports .CPU as total processor seconds consumed since start:

Id          : 15128
ProcessName : codebase-memory-mcp
CPU         : 1179.4375
StartTime   : 9/15/2026 8:23:44 PM

The panel displayed 1177.2 % for that same PID moments earlier. Same number, wrong unit.

4. It is monotonic, not a rate

Two samples of /api/processes, 20 seconds apart:

Elapsed CPU-time only accumulates, so the rendered "percentage" can never fall.

5. Total CPU is a sum of those seconds

The screenshot's 2447.8 is exactly 100.5 + 1170.1 + 1177.2 — the three per-process values added together. Summing cumulative CPU-time across processes is meaningful; presenting the sum as a percentage is not.

Why this matters beyond cosmetics

The bug is invisible on a young process and damning on an old one. PID 91572 above, two minutes into its life, reported 1.8 — which reads as a perfectly plausible "1.8%". The same field reads "1177%" after eighteen hours. Anyone who opens the Control Panel after leaving an editor session running overnight will conclude the server is pathologically burning CPU when it is idling at ~2%.

This may account for some share of the existing high-CPU reports. #45 ("Very high CPU usage", currently awaiting-reporter) is a screenshot of elevated per-process CPU figures across three long-running repos, which is the exact shape this bug produces. It would be worth asking that reporter to cross-check against ps -o time= / Activity Monitor before treating it as a genuine regression. #2093 measures a real ~19%-of-a-core idle burn by other means and looks unrelated.

Suggested fix

Either of:

1. Report a real rate. Cache the previous (cpu_seconds, wall_clock) pair per PID and emit (Δcpu / Δwall) × 100. First sample after startup has no predecessor, so fall back to cpu_seconds / elapsed × 100 (lifetime average) or report null rather than a bogus figure. Worth renaming the field cpu_percent at the same time so the unit travels with the value.
2. Relabel the display. Keep the field as-is, rename it cpu_seconds, and have the tile read "CPU time" with a s / h:mm:ss suffix and no progress bar. A cumulative counter has no meaningful denominator to fill a bar against.

Option 1 is what the tile's design implies a viewer will read, so it is probably the intended behavior; option 2 is the smaller change.

Happy to test a patch on Windows if useful.