0.55.1 (130): sustained ~92% CPU + 2.2 GB RSS within 35 min of launch, and ~468 orphaned WebKit.WebContent processes spawned overnight (~1 per 30–90s); orphans survive app quit and SIGKILL

Begin with the reported cost-usage corpus at ~/Library/Caches/CodexBar/cost-usage, the verbose logs, and the crash report ~/Library/Logs/DiagnosticReports/CodexBar-2026-08-26-181214.ips. Compare behavior with cost tracking enabled and disabled, and inspect the WebKit-related process timeline alongside issues #2538, #2824, #3073, and #678/#713/#1217. Done means identifying whether cost tracking or the WebKit dashboard causes the resource growth and reproducing a verified fix.

Summary

Two related symptoms on the current release, possibly the cost-usage/WebKit surface again (see Related issues below):

1. Sustained CPU spin + memory growth in the main process. Fresh launch reached 91.7% CPU (≈1 full P-core) and 2.2 GB RSS in ~35 minutes. System load average hit 202 on a 10-core machine and dropped to 31 within ~90s of quitting CodexBar. RAM itself was fine (91% available), so this is pure CPU saturation.
2. Mass overnight leak of WebKit content processes. Found 468 com.apple.WebKit.WebContent processes (mostly ~16 MB, state Ss, oldest zombies 8 days, bulk spawned over ~11h at roughly 1 per 30–90 seconds, spawn rate stopped ~5h before measurement). CodexBar links WebKit.framework and its crash/relaunch timeline matches the leak window. Attribution of the WebContent leak is circumstantial (I could not read responsible-pid without sudo), but CodexBar is the only third-party WebKit host alive during the window besides Mail.

Environment

• CodexBar 0.55.1 (build 130) — latest release, auto-update on, last check 2026-08-26 23:07 UTC
• macOS 26.5.2 (25F84), Apple Silicon M1 Max, 64 GB
• Cost tracking enabled; ~/Library/Caches/CodexBar/cost-usage = 324 MB corpus
• debugLogLevel = verbose
• Multiple providers tracked (Codex + Claude + Cursor probes)

Timeline (from process forensics)

• 2026-08-26 18:12 — CodexBar crash (~/Library/Logs/DiagnosticReports/CodexBar-2026-08-26-181214.ips)
• 2026-08-26 20:07 — relaunched (18h31m uptime by next morning)
• ~02:30 → ~09:40 — WebContent spawn window (etime distribution of the 468 orphans)
• Morning state: main process 2.7 GB, load avg 202, machine visibly crawling
• Quit + relaunch today: 91.7% CPU / 2.2 GB within 35 min (exact signature of #2538's ~91%)
• Quit again: load 202 → 31 in 90s; CPU of remaining processes normal

Kill behavior of the orphans (matches #3073)

• Orphans in Ss state survived app quit, SIGTERM and direct kill -9 <pid> (signal delivered, process remained for minutes)
• pkill -9 -f WebKit.WebContent removed them (441+ procs); note this pattern also hits Safari renderers, use with care

Why I think it's the cost-usage scan again

• CPU signature (91.7%) mirrors #2538 exactly; corpus is 324 MB in cost-usage
• #2538 was fixed by #2525 for 0.46-era corpora, and #2824 showed a second spin path (ICU date formatter) on 0.49 with a 110 MB corpus. This looks like a third occurrence on 0.55.1 with a different corpus shape, and/or the WebKit dashboard refresh spawning one WebContent per poll cycle (lineage of #678/#713/#1217)

Requested

• Pointers on what to capture next time (verbose log is on); happy to provide cost-usage corpus metadata (file count/size distribution) or a sample JSONL
• Willing to test a fix build with cost tracking disabled vs enabled to confirm which subsystem pins the core

Workaround (from #2538, untested on this corpus)

Disable Usage & Spend → Track Costs and Cost Summary, keep the app closed until then.