Regression of #1031 on 0.28.0: "still loading usage data" error reappears with Claude CLI 2.1.148

[nischal94]

Summary

The fix from #1031 / PR #1032 (commit 1dd2804f) is included in my build,
but the exact symptom and error message it addressed have returned with
Claude CLI 2.1.148:

Could not parse Claude usage: Claude CLI /usage is still loading usage data.

The CodexBarClaudeWatchdog helper spawns within ~5s of every relaunch,
confirming the CLI PTY fallback is being used rather than OAuth or browser
cookies. The loading-state retry added in #1032 appears not to be
recovering on this CLI version.

Scope of the failure

The Claude tab's cost/token histogram (computed locally from
~/.claude/projects/*.jsonl) renders correctly — showing today's spend,
30-day spend, top model, etc. The failure is isolated to the
session/weekly quota probe path (OAuth → cookies → CLI PTY). Local-log
cost computation and the quota probe are independent codepaths; only the
latter is broken.

Environment

• CodexBar 0.28.0 (build 66, commit 855945a8) — 41 commits ahead of
  the Fix Claude usage loading stalls #1032 fix commit (gh api repos/steipete/CodexBar/compare/1dd2804f...855945a8
  → ahead_by: 41, behind_by: 0), so the fix is in this build
• macOS Darwin 25.x
• Claude CLI 2.1.148 at ~/.local/bin/claude
• Logged in to claude.ai in both Chrome (active session) and Safari
  (freshly authenticated during testing)

Suspected root cause

ClaudeStatusProbe.isUsageStillLoading matches the normalized substring
"loadingusage". Direct (non-PTY) invocation of claude /usage on
2.1.148 returns a single line:

You are currently using your subscription to power your Claude Code usage

That text does not contain "loadingusage" after normalization, so the
loading detector would return false for the final response. The error
in the menu bar therefore implies CodexBar's PTY probe is reading the
buffer before the final response materializes — catching the
intermediate "Loading usage…" render and emitting the loading-state error
without the retry succeeding.

Observed behavior

After each relaunch:

/Applications/CodexBar.app/Contents/Helpers/CodexBarClaudeWatchdog -- \
  ~/.local/bin/claude --allowed-tools …

…appears in ps aux within ~5 seconds, and the Claude tab shows the
error above. Persisted across ~10 hours of uptime and multiple restarts.

Steps to reproduce

1. Install Claude CLI 2.1.148.
2. Be logged in to claude.ai in a supported browser.
3. Launch CodexBar 0.28.0, open the Claude tab.
4. Observe: "Could not parse Claude usage: Claude CLI /usage is still loading usage data."
5. ps aux | grep CodexBar shows the watchdog helper running.
6. Quit + relaunch CodexBar multiple times — symptom persists.

What I tried (none fixed it)

• Restart CodexBar with existing browser sessions.
• Refresh Safari's claude.ai cookie (visit + sign in), then restart
  CodexBar. Cookie file ~/Library/Cookies/Cookies.binarycookies
  timestamp confirms write. Watchdog still spawns; error persists.
• Both Chrome and Safari claude.ai sessions are valid; since Safari
  cookies are not Keychain-protected on macOS, this rules out a
  Chrome-Safe-Storage-ACL issue as the sole cause (see also Keychain prompt for "Chrome Safe Storage" still appears repeatedly on 0.27.1 — is one-time entry supposed to stop it? #1056).

Possible directions

1. The PTY probe's short first attempt may be reading the buffer before
   Claude CLI 2.1.148 has settled — the CLI may have slower cold-start
   on 2.1.148 than earlier versions.
2. The retry-with-longer-probe added in PR Fix Claude usage loading stalls #1032 may not be triggering on
   the "loadingusage" detection in 0.28.0, or the longer probe is also
   timing out before the final response renders.
3. Worth verifying: does ClaudeStatusProbe correctly retry when
   isUsageStillLoading returns true, and does that retry path log
   anywhere I could inspect to confirm?

Diagnostic output

Happy to provide a CodexBar log bundle (Console.app filter, or wherever
the app writes its log) — just let me know which output is most useful.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve.

Latest ClawSweeper review: 2026-05-23 08:32 UTC / May 23, 2026, 4:32 AM ET.

Workflow note: Future ClawSweeper reviews update this same comment in place.

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.

Summary
Keep open: this is a fresh, detailed regression report for the Claude session/weekly quota probe, and current main still has the same bounded loading-retry shape that can surface the reported error when the longer CLI capture also returns a loading-only panel.

Reproducibility: no. not with a full real-runtime reproduction in this Linux review environment. Source inspection confirms current main can still surface the reported loading-state parse error after the bounded retry path, matching the user’s detailed macOS/Claude CLI report.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Next step
A maintainer or contributor should first capture the real Claude CLI 2.1.148 PTY dump/logs before choosing whether to extend wait behavior, retry conditions, or parser completion detection.

Review details

Best possible solution:

Keep the issue open and fix the Claude CLI PTY completion/retry behavior with a real 2.1.148 capture plus focused tests for repeated loading-only output and any changed final /usage format.

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

No, not with a full real-runtime reproduction in this Linux review environment. Source inspection confirms current main can still surface the reported loading-state parse error after the bounded retry path, matching the user’s detailed macOS/Claude CLI report.

Is this the best way to solve the issue?

Unclear. The earlier retry is the right area, but the durable fix should be driven by a real Claude CLI 2.1.148 PTY dump so maintainers can distinguish slow rendering from an upstream /usage format change.

Label changes:

• add P2: The report affects one provider’s quota probe with detailed reproduction context, while the app and local Claude cost history still function.
• add impact:auth-provider: The broken path is Claude provider source selection and CLI/OAuth/browser-cookie fallback for session quota data.
• add issue-rating: 🐚 platinum hermit: Current issue advisory state selects this label.
• add clawsweeper:needs-live-repro: 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 report affects one provider’s quota probe with detailed reproduction context, while the app and local Claude cost history still function.
• impact:auth-provider: The broken path is Claude provider source selection and CLI/OAuth/browser-cookie fallback for session quota data.

Acceptance criteria:

• swift test --filter ClaudeCLITimeoutRetryTests
• swift test --filter StatusProbeTests
• swift test --filter Claude

What I checked:

• Current loading error path: ClaudeStatusProbe trims to the latest usage panel and throws the exact “Claude CLI /usage is still loading usage data” parse failure when that panel still looks loading-only. (Sources/CodexBarCore/Providers/Claude/ClaudeStatusProbe.swift:161, 2dc7aa09dd24)
• Retry boundary on current main: Auto CLI fallback uses a 12s probe and retries loading/timed-out CLI failures with a 60s probe, so a second loading-only capture still bubbles out as the user-facing error. (Sources/CodexBarCore/Providers/Claude/ClaudeUsageFetcher.swift:551, 2dc7aa09dd24)
• Focused test coverage for prior fix: The existing regression test verifies one loading-panel retry in auto mode and expects timeouts [12, 60], but it does not prove recovery when Claude CLI 2.1.148 keeps rendering loading beyond that retry. (Tests/CodexBarTests/ClaudeCLITimeoutRetryTests.swift:109, 2dc7aa09dd24)
• PTY capture completion condition: The /usage capture waits for a normalized “Current session” percentage before stopping early, sends Enter periodically, and otherwise runs to the timeout; this matches the report’s suspicion that the capture may end before the final panel materializes. (Sources/CodexBarCore/Providers/Claude/ClaudeStatusProbe.swift:859, 2dc7aa09dd24)
• Prior loading retry provenance: Commit 1dd2804 is the prior hardening commit for Claude CLI loading retry, and the issue explicitly reports a build that includes it. (Sources/CodexBarCore/Providers/Claude/ClaudeUsageFetcher.swift:577, 1dd2804f406d)
• No newer status-probe fix found after latest release: The diff from v0.29.0 to current main only changes Claude OAuth extra-usage spend normalization in ClaudeUsageFetcher, not the Claude CLI PTY loading/status-probe logic. (Sources/CodexBarCore/Providers/Claude/ClaudeUsageFetcher.swift:954, 2dc7aa09dd24)

Likely related people:

• Peter Steinberger: Authored the prior Claude CLI loading retry hardening and the available blame/log history attributes the current Claude probe and retry code in this checkout to his commits. (role: recent area contributor; confidence: high; commits: 1dd2804f406d, e059a784538b, f61469c3cde6; files: Sources/CodexBarCore/Providers/Claude/ClaudeStatusProbe.swift, Sources/CodexBarCore/Providers/Claude/ClaudeUsageFetcher.swift, Sources/CodexBarCore/Providers/Claude/ClaudeCLISession.swift)
• rohitjavvadi: Opened the prior loading-stall PR that targeted the same Claude CLI /usage loading symptom and added focused retry/parser tests, even though the PR itself was closed unmerged. (role: prior related PR author; confidence: medium; commits: 5291a064d719; files: Sources/CodexBarCore/Providers/Claude/ClaudeStatusProbe.swift, Sources/CodexBarCore/Providers/Claude/ClaudeUsageFetcher.swift, Tests/CodexBarTests/ClaudeCLITimeoutRetryTests.swift)

Remaining risk / open question:

• The macOS Claude CLI 2.1.148 PTY flow was not executable in this review environment, so the exact buffer sequence still needs a real CodexBar debug dump or local macOS verification.
• The final Claude CLI 2.1.148 output described in the issue may be a changed upstream format rather than only a slow-loading panel, so a fix should avoid blindly increasing timeouts without checking the captured text.

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

[steipete]

Fixed by #1121, merged as 126dc92.

What changed:

• Claude CLI 2.1 subscription-only /usage output is now classified as a precise no-quota-data response.
• PTY collection stops on the subscription notice instead of waiting for quota labels that never arrive.
• If the PTY /usage panel times out or reports a load failure, CodexBar falls back to direct claude /usage with stdin closed and the same scrubbed Claude environment.

Proof on the reproducing machine:

• claude --version => 2.1.148 (Claude Code)
• direct claude /usage returns the subscription-only notice
• CodexBarCLI usage --provider claude --source cli now reports Claude CLI /usage returned a subscription notice without session quota data. instead of hanging or surfacing the generic loading failure
• focused Swift tests passed
• make check passed
• local autoreview clean

Closing as fixed.