can someone fix the performance?

[guocity]

can someone fix the performance? popup menu its really lagging, please fix it!!!

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 5, 2026, 4:58 PM ET / 20:58 UTC.

Summary
The report should stay open because popup-menu lag is plausible against current menu rebuild/rendering code, but the issue has no scenario or timing data and current main only shows related recent performance work, not a proven fix for this exact complaint.

Reproducibility: no. The report only says the popup menu is lagging, and there is not enough information to reproduce it against current main without the reporter's version, macOS version, enabled providers, display mode, timing, or profile.

Ways to help us reproduce this

• Add expected vs actual behavior.

Next step
The report may matter, but it needs maintainer/reporter reproduction data or profiling before a safe repair lane can target one code path.

Review details

Best possible solution:

Keep the issue open, ask for a reproducible popup-lag scenario, then land a focused menu-open or menu-rebuild performance fix with state/model tests and real bundle timing proof if UI behavior is affected.

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

No. The report only says the popup menu is lagging, and there is not enough information to reproduce it against current main without the reporter's version, macOS version, enabled providers, display mode, timing, or profile.

Is this the best way to solve the issue?

Unclear. A narrow performance fix is likely the right kind of solution, but the exact code path could be menu-open refresh, provider switcher rendering, SwiftUI card measurement, hosted submenu hydration, or refresh/rebuild scheduling.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The report does not say whether the lag is on latest release v0.32.4 or current main, and recent current-main menu performance work may not match the reporter's installed build.
• Without provider count, display mode, enabled providers, macOS version, and timing/profile data, an attempted fix could optimize the wrong menu path.

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

Label changes

Label changes:

• add P2: Popup-menu lag is a user-facing performance problem with limited blast radius, but no crash, data loss, or security impact is shown.
• add impact:other: The issue is about menu responsiveness/performance, which is meaningful maintainer-visible impact outside the specific owned impact categories.
• add issue-rating: 🦪 silver shellfish: 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: Popup-menu lag is a user-facing performance problem with limited blast radius, but no crash, data loss, or security impact is shown.
• impact:other: The issue is about menu responsiveness/performance, which is meaningful maintainer-visible impact outside the specific owned impact categories.

Evidence reviewed

What I checked:

• Issue body: The issue reports that the popup menu is lagging but gives no CodexBar version, macOS version, enabled-provider count, provider selection mode, timing sample, profile, screenshot, or reproduction steps.
• Policy read: AGENTS.md was read fully; its UI/runtime and Keychain-prompt guidance affected the decision not to run live bundle validation during this read-only review. (AGENTS.md:1, af2c754d2426)
• Vision fit: VISION.md says CodexBar should preserve fast refreshes and that bounded performance improvements are merge-by-default work, so a concrete menu-lag fix is in scope. (VISION.md:3, af2c754d2426)
• Menu-open path: menuWillOpen records menu-open timing, defers OpenAI dashboard refresh while Codex menus are open, refreshes menu content if needed, registers the open menu, and schedules an open-menu refresh. (Sources/CodexBar/StatusItemController+Menu.swift:75, af2c754d2426)
• Menu rebuild path: Open-menu rebuilds are explicitly scheduled and coalesced through scheduleOpenMenuRebuildIfStillVisible, with debounce and cancellation behavior that could affect perceived popup responsiveness. (Sources/CodexBar/StatusItemController+MenuRefreshScheduling.swift:123, af2c754d2426)
• Height-cache path: Current code caches SwiftUI menu-card height measurement by id, scope, width, text scale, and fingerprint, showing active optimization work around a likely popup-menu hot path. (Sources/CodexBar/StatusItemController+MenuCardHeightCache.swift:22, af2c754d2426)

Likely related people:

• hhh2210: Recent menu-performance history includes commits for menu-card height caching, height fingerprints, hot-path trimming, and closed merged-menu rebuild behavior on the central menu files. (role: recent area contributor; confidence: high; commits: ef17fbd45d91, 989a7572747d, c7f8336e1314; files: Sources/CodexBar/StatusItemController+MenuRefreshScheduling.swift, Sources/CodexBar/StatusItemController+MenuCardHeightCache.swift, Sources/CodexBar/MenuCardHeightFingerprint.swift)
• Peter Steinberger: Current menu-open lines and many historical menu architecture/performance commits route through Peter, including menu construction, refresh deferral, menu tracking, and release/appcast context. (role: long-running area contributor; confidence: high; commits: af2c754d2426, 440aeb1cb0d4, 07ed3facdd4e; files: Sources/CodexBar/StatusItemController+Menu.swift, Sources/CodexBar/StatusItemController+MenuRefreshScheduling.swift, Sources/CodexBar/StatusItemController+MenuCardItems.swift)
• Behnam M: Earlier history includes menu flicker/opening-delay and open-menu rebuild prevention commits that are adjacent to the same popup responsiveness area. (role: historical performance contributor; confidence: medium; commits: feb0c0b480fb, b4f25fd6ecc9, dc9ce6005d08; files: Sources/CodexBar/StatusItemController+Menu.swift, Sources/CodexBar/StatusItemController+MenuRefreshScheduling.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.

[mattdaniell]

+1 to this, when I open codexbar it freezes and I am unable to do anything on mac until it resolves.
I suspect its the multiple codex accounts, or windsurf / opencode.

[AmirAjaj]

I downgraded to 0.31.0, which runs pretty stable for me with no performance regressions. I advice you to do the same if you are also experiencing the laggy behaviour. The downgrade fixed it for me and afaik there were no meaningful feature additions in 0.32.0

[kcahrens]

+1 — Very laggy hover + slow provider switching / combined page
Hover interactions feel extremely laggy, especially when:

Hovering over providers
Switching between different providers
Using the combined page

The UI response to hover is noticeably delayed and makes the app feel sluggish.
Video showing the issue:
https://github.com/user-attachments/assets/708d6cc2-c176-435a-a3f1-4355b32d331e
Environment

CodexBar: 0.32.4 (79) — built Jun 2, 2026
macOS: 26.3.1 (25D2128)

This is on top of the general performance complaints already in this thread. Happy to test any fixes or provide more details.

[markwylde]

I downgraded to 0.31.0, which runs pretty stable for me with no performance regressions. I advice you to do the same if you are also experiencing the laggy behaviour. The downgrade fixed it for me and afaik there were no meaningful feature additions in 0.32.0

Thanks, can confirm downgrading to 0.31.0 fixes the performance issues.

[Yuxin-Qiao]

I dug into this (the "0.31.0 is fine, 0.32.x lags, downgrading fixes it" reports were the key signal) and traced two concrete main-thread costs that were added/grew in the 0.32 series and still exist on main. Opened two focused PRs:

#1351 — menu readiness signature cost
observeStoreChanges recomputes a "readiness signature" on every store mutation. It serializes every enabled provider's token snapshot + 30-day daily breakdown + the OpenAI dashboard per-service breakdown into a string (with String(format: "%.8f", …) per value), so the cost scales with provider/account count and fires on every background refresh tick.

• Skip computing it entirely when no menu is open (the result is only consulted while a menu is open).
• Use the raw Double bit pattern instead of %.8f formatting (it's only compared for equality). Micro-benchmark: ~0.68ms → ~0.065ms per signature build (~10x).

#1352 — hosted chart submenus build a throwaway hosting controller
Each hosted chart item (cost/usage/credits history, storage breakdown, z.ai hourly) built two SwiftUI hierarchies per (re)build: the displayed MenuHostingView plus a separate NSHostingController created solely to measure height — whose result was always immediately overwritten by the subsequent refreshHostedSubviewHeights() fittingSize pass. The PR sizes the live displayed view directly, removing the redundant SwiftUI tree. No caching/fingerprints, so chart content is never stale.

Both build clean, pass make check, and pass the menu test suites (with a new test for the chart sizing path).

Caveats / help wanted:

• I can't reproduce the heavy-config lag locally, so these are code-attributable regressions, not a proven end-to-end fix. If maintainers/reporters can confirm on a build with many providers/accounts, that would help.
• For the "freeze on open with multiple Codex accounts" reports specifically: recent main already added Codex token-scan budget/cap commits since 0.32.4, so part of that may already be mitigated — a fresh repro on latest main would be useful.
• A sample/Instruments trace during the lag (or the built-in "slow menu operation" warnings) would let us confirm whether these two paths are the dominant cost or if there's more.

[Yuxin-Qiao]

Consolidated triage map for the 0.32.x menu‑lag reports

Posting this to help locate the problem in one place. All plain # refs (no pings). I went through the current open issues/PRs; corrections welcome.

Same user‑visible problem — main‑thread lag when opening/switching the (merged) menu in 0.32.x, reported in different words/languages:

• can someone fix the performance? #1321 (this issue) · Menu popover stays open or delays switching between Claude and Codex tabs #1325 (Claude↔Codex switch delay, includes a current‑main sample) · High CPU usage #1311 (high CPU + laggy menu) · 同时配置2个ai工具，小组件ai切换会卡顿，点击其他按钮也会卡顿 #1308 (Chinese: lag with 2 providers configured + switching)

These look like the same root family: synchronous rebuild of SwiftUI‑backed menu‑card rows + AppKit layout on open/switch, plus per‑tick background costs. Likely dedup candidates → #1321.

Related symptom but likely a distinct root cause (flagging so they aren't closed as dups of the above):

• Main thread spins after a few days of uptime — Settings won't open, ~9% CPU at idle #1347 — idle main‑thread spin after long uptime; reporter's sample points to isRunningTestsProcess() re‑reading ProcessInfo.environment in a hot view‑body loop.
• CodexBar menu bar icon hangs and remains memory-heavy #1329 — hang + elevated RSS; logs show Keychain / LocalAuthentication (SecItemCopyMatching) churn.

Open PRs attacking this area:

• Reduce merged menu tab rebuilds #1345 (Fixes #1325) — cache built merged‑tab content, skip re‑select rebuilds
• perf: cut menu readiness signature cost on store changes #1351 — cut readiness‑signature cost on store changes (background‑tick path) + baseline‑staleness fix
• perf: size hosted menu charts without a throwaway hosting controller #1352 — size hosted charts without a throwaway NSHostingController
• Reduce idle menu power usage #1292 — stop idle closed‑menu prewarm (rebuildClosedMenuIfNeeded → populateMenu → sizeThatFits)
• perf: optimize menu population and usage formatting #1290 — cache JWT / formatters / menu width in the population path
• Improve menu performance #1198 — broad menu‑perf bundle + main‑runloop stall monitor

Already merged in this lineage (0.32.5+): #1286 · #1314 · #1261 · #1291 · #1233
Earlier closed reports of the same symptom: #1274 · #1196 · #1235 · #1227 · #1303 · #949

Not this problem (menu‑bar positioning / visibility — listed only to avoid confusion): #1267 ↔ #1288 / #1324 ; icon‑disappearing #1109 / #1169 / #861 ↔ #1306

Net: the lag is being addressed piecemeal across the PRs above; #1311 / #1308 / #1325 look like duplicates of #1321; #1347 and #1329 appear to need their own fixes.