Summary
When CodexBar is running with Codex enabled, the app can make the whole machine feel slow, not just the menu bar app itself.
This looks tied to the Codex OpenAI-web/dashboard refresh path. On launch, CodexBar triggers offscreen WKWebView work, and fresh com.apple.WebKit.WebContent helpers spike CPU hard.
What I observed
On April 9, 2026, I reproduced this locally and saw:
CodexBar briefly hit around 100% CPU on launch
fresh com.apple.WebKit.WebContent processes hit roughly 160–185% CPU
another WebKit content process stayed hot afterward around 50–110%
the slowdown was noticeable system-wide, not only inside CodexBar
Relevant logs
From ~/Library/Logs/CodexBar/CodexBar.log:
OpenAI web refresh start
OpenAI webview show
browser cookie import begins
second OpenAI webview show
Probe timed out (href=https://chatgpt.com/)
No matching browser session found
import mismatch: no signed-in session detected ...
There were also Safari cookie permission-denied messages, but those looked secondary. The main issue appears to be the expensive WebKit scrape / probe path.
Suspected cause
The expensive part seems to be the Codex OpenAI dashboard scraping flow using an offscreen WKWebView, especially when:
the browser session does not match the Codex account
the dashboard probe times out
startup still awaits this path
retries continue after mismatch / timeout
Expected behavior
launching CodexBar should stay lightweight
a failed Codex web/dashboard probe should not cause prolonged high CPU
a menu bar app should not make the whole machine feel slow
Suggested fixes
do not await OpenAI web refresh during startup
move it to a detached / delayed background refresh
use a much shorter timeout for the browser-session probe
add aggressive backoff after timeout or account/session mismatch
stop retrying once the app knows there is no matching signed-in browser session
Environment
macOS 14.7.7
CodexBar 0.20 (build 55)
Summary
When CodexBar is running with Codex enabled, the app can make the whole machine feel slow, not just the menu bar app itself.
This looks tied to the Codex OpenAI-web/dashboard refresh path. On launch, CodexBar triggers offscreen WKWebView work, and fresh com.apple.WebKit.WebContent helpers spike CPU hard.
What I observed
On April 9, 2026, I reproduced this locally and saw:
CodexBar briefly hit around 100% CPU on launch
fresh com.apple.WebKit.WebContent processes hit roughly 160–185% CPU
another WebKit content process stayed hot afterward around 50–110%
the slowdown was noticeable system-wide, not only inside CodexBar
Relevant logs
From ~/Library/Logs/CodexBar/CodexBar.log:
OpenAI web refresh start
OpenAI webview show
browser cookie import begins
second OpenAI webview show
Probe timed out (href=https://chatgpt.com/)
No matching browser session found
import mismatch: no signed-in session detected ...
There were also Safari cookie permission-denied messages, but those looked secondary. The main issue appears to be the expensive WebKit scrape / probe path.
Suspected cause
The expensive part seems to be the Codex OpenAI dashboard scraping flow using an offscreen WKWebView, especially when:
the browser session does not match the Codex account
the dashboard probe times out
startup still awaits this path
retries continue after mismatch / timeout
Expected behavior
launching CodexBar should stay lightweight
a failed Codex web/dashboard probe should not cause prolonged high CPU
a menu bar app should not make the whole machine feel slow
Suggested fixes
do not await OpenAI web refresh during startup
move it to a detached / delayed background refresh
use a much shorter timeout for the browser-session probe
add aggressive backoff after timeout or account/session mismatch
stop retrying once the app knows there is no matching signed-in browser session
Environment
macOS 14.7.7
CodexBar 0.20 (build 55)