[Crash] EXC_CRASH SIGABRT in CursorStatusProbe.fetchIfSessionAccepted on startup (0.20)

[h3x89]

Bug Report — App crashes on startup, cannot launch

CodexBar version: 0.20 (build 55)
macOS: 26.3.1 (25D771280a) arm64
Reproducible: Every launch

Symptom

CodexBar crashes immediately on every startup. The app is completely unusable — it crashes within ~1.5s of launch every time.

Crash stack trace (from DiagnosticReports .ips)

Exception: EXC_CRASH (SIGABRT)
Signal: SIGABRT

Crashed thread:
  __pthread_kill
  pthread_kill
  abort
  swift::swift_Concurrency_fatalErrorv(unsigned int, char const*, char*)
  swift::swift_Concurrency_fatalError(unsigned int, char const*, ...)
  swift_task_dealloc
  asyncLet_finish_after_task_completion(...)
  specialized CursorStatusProbe.fetchIfSessionAccepted(_:log:)
  CursorStatusProbe.fetch(cookieHeaderOverride:logger:)
  CursorStatusFetchStrategy.fetch(_:)
  protocol witness for ProviderFetchStrategy.fetch(_:) in conformance CursorStatusFetchStrategy
  ProviderFetchPipeline.fetch(context:provider:)
  closure #1 in closure #3 in UsageStore.refreshProvider(_:allowDisabled:)
  partial apply for closure #1 in closure #3 in UsageStore.refreshProvider(_:allowDisabled:)
  specialized thunk for @escaping @isolated(any) @callee_guaranteed @async () -> (@out A)
  partial apply for specialized thunk for @escaping @isolated(any) @callee_guaranteed @async () -> (@out A)
  completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*)

Attempted workaround

I tried disabling the Cursor provider via defaults:

defaults write com.steipete.codexbar providerToggles -dict antigravity 0 claude 1 codex 1 cursor 0 gemini 1
defaults write com.steipete.codexbar selectedMenuProvider claude

However, the crash persists. The stack shows refreshProvider(_:allowDisabled:) — it appears CodexBar fetches all providers including disabled ones on startup, which triggers the crash regardless of the toggle state.

Additional context

• selectedMenuProvider was set to cursor before I changed it to claude
• Cursor is installed on this machine
• The crash happens in Swift concurrency (swift_task_dealloc + asyncLet_finish_after_task_completion), suggesting a memory/task lifecycle issue specific to CursorStatusProbe.fetchIfSessionAccepted
• Crash report ID: 19ECAB52-9CA3-48BE-BE91-0BD4A1C29CE7

Is there a way to fully disable the Cursor provider from the command line so the startup fetch is skipped entirely?

[dpardo2183]

V .20 is completely useless

[ottolu]

I'm also experiencing this exact crash on v0.20 (build 55), macOS 26.3 (25D125), Apple Silicon.

The crash is 100% reproducible — app crashes within ~5 seconds of launch every time. I have 3 identical crash reports all pointing to the same stack:

CursorStatusProbe.fetchIfSessionAccepted → swift_task_dealloc → abort

Workaround that works for me

Instead of using defaults write (which the OP reported doesn't help), I edited ~/.codexbar/config.json directly and set the Cursor provider to "enabled": false:

{
  "enabled": false,
  "id": "cursor"
}

After this change, CodexBar launches and runs normally — Gemini, Antigravity, Claude, and Codex providers all work fine. Only the Cursor provider triggers the crash.

This suggests the config.json disable path does skip the fetch, unlike the defaults write toggle approach. Might be a useful workaround for others stuck on this.

Environment

• CodexBar 0.20 (55)
• macOS 26.3 (25D125) arm64
• Cursor is installed on this machine
• Crash report IDs: F96546A5-A6BF-4524-8077-6559D1E9AFD1, plus 2 more

[tillstriegel]

CodexBar crashes on launch when stored Cursor session exists

CodexBar 0.20 (build 55) on macOS 26.2 repeatedly crashes on launch after Cursor has been configured.

Observed locally:

• Repeated crash reports in ~/Library/Logs/DiagnosticReports/CodexBar-2026-04-13-102325.ips, 102350.ips, 102406.ips, 102515.ips
• Faulting path in crash stack points to CursorStatusProbe.fetch(cookieHeaderOverride:logger:)
• App-specific state on disk included ~/Library/Application Support/CodexBar/cursor-session.json
• No other obvious provider-specific config files were present besides that stored Cursor session and normal prefs/history files

Local recovery that restored launch:

1. Backed up ~/Library/Application Support/CodexBar/cursor-session.json
2. Renamed it to cursor-session.json.disabled
3. Relaunched CodexBar
4. App stayed running and no newer crash report was generated

Likely issue:

• Stored Cursor session cookies/tokens can trigger a concurrency fatal error during Cursor status probing at launch.
• Absence of the stored session does not crash the app; it only removes the saved Cursor auth state.

Suggested follow-up:

• Reproduce with a fresh stored Cursor session
• Harden CursorStatusProbe / stored-session parsing so invalid or unexpected session data degrades to “logged out” instead of aborting
• Consider quarantining unreadable/invalid cursor-session.json automatically and surfacing a non-fatal error in UI

[anirudhvee]

This is the same issue as #661 and was fixed on main in #663. Should be fixed in the next release