CodexBar Web Content spikes CPU and respawns after quitting menu bar UI

[petrinigiuseppe]

Title: CodexBar Web Content spikes CPU and respawns after quitting menu bar UI

Summary

CodexBar 0.31.0 / build 73 can spawn a WebKit process named CodexBar Web Content that consumes very high CPU and memory. In one observed run the process reached over 150% CPU and about 1.3 GB RSS. After the original process calmed down, another CodexBar Web Content process spawned and continued consuming CPU.

This caused noticeable heat and performance load on an Apple Silicon Mac even though the main CodexBar menu bar process itself was only using low single-digit CPU.

Environment

• App: CodexBar
• Version: 0.31.0
• Build: 73
• Commit: 56261df4
• Build timestamp: 2026-05-28T22:05:05Z
• Bundle ID: com.steipete.codexbar
• macOS: Version 26.4, build 25E246
• Hardware: Apple Silicon / M2 Pro
• Sparkle auto-update enabled
• Refresh frequency preference: oneMinute
• Launch at login: enabled

Evidence

Example process snapshot:

PID    CPU     MEM/RSS       PROCESS
87613  156.8%  ~1.3 GB RSS   CodexBar Web Content / com.apple.WebKit.WebContent
59827  3.3%    ~84 MB RSS    /Applications/CodexBar.app/Contents/MacOS/CodexBar

LaunchServices identified the hot WebKit process as:

CodexBar Web Content
bundleID="com.apple.WebKit.WebContent"
parentASN="CodexBar Networking"

After the first hot WebKit process dropped, another WebKit content process appeared:

88118  35.4%  ~630 MB RSS  /System/Library/Frameworks/WebKit.framework/.../com.apple.WebKit.WebContent

The high CPU stopped after quitting/killing CodexBar and its WebKit content processes.

Related Context

This machine also previously had a long-running git clone zombie under a Claude/plugin cache workflow that appeared to have been triggered indirectly around CodexBar/Claude usage probing. I cannot prove causality, but it suggests CodexBar may be triggering provider/plugin/background refresh paths that can become expensive or stuck.

Expected Behavior

CodexBar should not keep a WebKit content process spinning at high CPU while running passively in the menu bar. Background provider refresh should be bounded, cancellable, and observable.

Actual Behavior

CodexBar Web Content spawned under CodexBar Networking, consumed very high CPU and memory, and contributed to heat/performance load. Quitting CodexBar stopped the spike.

Suggested Diagnostics / Fixes

• Add logging around WebKit usage/provider refresh tasks so the active provider or URL/action can be identified.
• Add a timeout/cancellation boundary for WebKit-driven refresh/probing.
• Consider exposing a low-power mode or disabling WebKit refresh when the menu is closed.
• Consider reducing default refresh frequency or backing off if WebKit CPU remains high.
• Consider separating Claude/Codex provider probes from menu rendering so a stuck provider cannot spin a WebKit content process indefinitely.

Workaround

Quit CodexBar when heat appears, or disable launch-at-login until the WebKit refresh path is bounded.

[petrinigiuseppe]

Related prior reports I found after filing:

• Codex provider OpenAI web refresh can spike WebKit.WebContent CPU and slow the whole machine #678 — Codex provider OpenAI web refresh can spike WebKit.WebContent CPU and slow the whole machine
• WebKit.WebContent process stuck at 100% CPU when popover is closed #713 — WebKit.WebContent process stuck at 100% CPU when popover is closed
• OpenAI web refresh uses high CPU while scraping full dashboard HTML #1033 — OpenAI web refresh uses high CPU while scraping full dashboard HTML
• High CPU (~400%) when Claude probe enabled in 0.5.1 on macOS 26.1 #9 — High CPU when Claude probe enabled

Those are closed as fixed/stale, with maintainers asking for a fresh issue if current builds still pin WebKit. This report is from current 0.31.0 build 73 / commit 56261df4, so it may be a regression or a remaining provider path not covered by the prior fixes.

The distinctive bit in this capture is LaunchServices identifying the hot process as CodexBar Web Content with parentASN="CodexBar Networking", while the main CodexBar process stayed relatively low CPU.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed May 29, 2026, 1:55 PM ET / 17:55 UTC.

Summary
Keep open. This is a fresh v0.31.0 report of the same WebKit/OpenAI dashboard performance surface that prior issues explicitly asked reporters to reopen if current builds still pinned WebKit, and current main has no affected-code change after v0.31.0 that would make the report obsolete.

Reproducibility: no. the report has credible runtime observations and process snapshots, but it does not include a deterministic current-main trigger. AGENTS.md also rules out autonomous live provider probes that could show Keychain prompts, so source and issue evidence are the safe basis for now.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
A fix likely belongs in the OpenAI WebKit refresh lifecycle, but maintainers should first choose the diagnostic/reproduction route because the failure is runtime-specific and live provider probing is unsafe for automation here.

Review details

Best possible solution:

Keep this open and add focused diagnostics plus a bounded cancellation/teardown/backoff fix for the OpenAI WebKit refresh path, validated through model/cache tests and any maintainer-supplied runtime sample rather than automated live provider probes.

Do we have a high-confidence way to reproduce the issue?

No: the report has credible runtime observations and process snapshots, but it does not include a deterministic current-main trigger. AGENTS.md also rules out autonomous live provider probes that could show Keychain prompts, so source and issue evidence are the safe basis for now.

Is this the best way to solve the issue?

Unclear: the suggested logging, timeouts, and cancellation boundaries are plausible, but current code already contains several safeguards. The best fix should first identify which WebKit lease, retry, or shutdown path remains active in v0.31.0.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The exact trigger is still non-deterministic, so a repair should start with diagnostics or a controlled WebKit harness rather than live account probing.
• Current code already has opt-in defaults, retry timeouts, idle blanking, and teardown management; changing the WebView lifecycle without focused evidence could regress dashboard hydration or account-cookie behavior.
• The report mentions a possible Claude/plugin cache zombie, but causality is unproven and should not broaden the first fix beyond the observed WebKit helper path.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 6fe01054424b.

Label changes

Label changes:

• add P2: The issue reports current-release high CPU and memory from a background WebKit helper, but the trigger is not yet deterministic or proven to affect all users.
• add impact:crash-loop: The affected behavior is process-level availability: a WebKit helper remains hot and another helper can respawn under CodexBar.
• add issue-rating: 🦐 gold shrimp: Current issue advisory state selects this label.
• add clawsweeper:needs-info: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.

Label justifications:

• P2: The issue reports current-release high CPU and memory from a background WebKit helper, but the trigger is not yet deterministic or proven to affect all users.
• impact:crash-loop: The affected behavior is process-level availability: a WebKit helper remains hot and another helper can respawn under CodexBar.

Evidence reviewed

Acceptance criteria:

• swift test --filter OpenAIWebRefreshGateTests
• swift test --filter OpenAIDashboardWebViewCacheTests
• swift test --filter WebKitTeardownTests
• swift test --filter CodexManagedOpenAIWebRefreshTests
• make check

What I checked:

• current report evidence: The issue body reports CodexBar 0.31.0 build 73 with CodexBar Web Content reaching about 156.8% CPU and about 1.3 GB RSS, followed by another WebKit content process at about 35.4% CPU.
• current-main release delta: Current main only changes CHANGELOG.md and version.env after v0.31.0; no OpenAI WebKit, UsageStore, settings, or related test files changed after the reported release. (6fe01054424b)
• background OpenAI web refresh path: Regular refresh still gates and schedules OpenAI web dashboard refresh work when Codex is enabled, OpenAI web access is enabled, and the cookie source is enabled. (Sources/CodexBar/UsageStore.swift:577, 6fe01054424b)
• bounded but still active WebKit scrape path: The dashboard fetcher acquires an offscreen WKWebView lease and polls until a deadline, so the remaining bug likely lives in this fetch/cache/teardown surface rather than menu rendering alone. (Sources/CodexBarCore/OpenAIWeb/OpenAIDashboardFetcher.swift:201, 6fe01054424b)
• existing WebView idle and teardown safeguards: The cache already has a 60-second idle timeout, blanks the page on idle release, uses inactive scheduling policy on macOS 14+, and closes through WebKitTeardown, so a blind duplicate fix would be risky without diagnosing the remaining spinning path. (Sources/CodexBarCore/OpenAIWeb/OpenAIDashboardWebViewCache.swift:83, 6fe01054424b)
• prior reports invited a fresh current-build issue: Prior related reports were closed as fixed/stale with maintainer comments asking for a fresh issue if a current build still pins WebKit after a few minutes idle; this issue supplies that current-build report.

Likely related people:

• steipete: Blame on the current OpenAI web refresh/cache code in this checkout points to the v0.31.0 source snapshot authored by Peter Steinberger, and prior related issues were closed with routing guidance from steipete. (role: recent area contributor and merger; confidence: high; commits: f83fb70b7f24, 56261df4fed1; files: Sources/CodexBar/UsageStore+OpenAIWeb.swift, Sources/CodexBarCore/OpenAIWeb/OpenAIDashboardFetcher.swift, Sources/CodexBarCore/OpenAIWeb/OpenAIDashboardWebViewCache.swift)
• douglascamata: Merged PR perf(openai-web): reduce idle CPU by suspending cached WebViews #96 introduced the prior offscreen WKWebView idle CPU mitigation that maps directly to the current cache/hide behavior. (role: prior WebKit idle-CPU fix contributor; confidence: medium; commits: a01cdcab0746; files: Sources/CodexBarCore/OpenAIWeb/OpenAIDashboardWebViewCache.swift)
• ratulsarna: Prior related WebKit memory/CPU issues had ratulsarna assigned or commenting about OpenAI Web Extras and battery-saver mitigation, which is relevant routing context for this fresh report. (role: prior related issue responder; confidence: low; files: Sources/CodexBar/SettingsStore.swift, Sources/CodexBar/UsageStore+OpenAIWeb.swift)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[petrinigiuseppe]

Fresh repro on the same machine:

1. Quit CodexBar completely.
2. Launch with open -a /Applications/CodexBar.app.
3. Wait ~8 seconds.

Observed immediately after launch:

PID    CPU     RSS      ELAPSED  PROCESS
29242  152.4%  604 MB   00:06    com.apple.WebKit.WebContent / CodexBar Web Content
28759   82.0%  596 MB   00:09    /Applications/CodexBar.app/Contents/MacOS/CodexBar

So this reproduces deterministically on launch, not only after long idle time. Quitting CodexBar removes the hot WebKit process. Main app and WebKit both spike together during the initial refresh/probe path.