codexbar and chrome cookie refresh

[vinschger]

I have opened an issue some time ago as codexbar isn't able to refresh the usage chart for claude since weeks. I am not sure if the ticket is still open or if there is anything more I can provide to help to fix this issue. Is this a bug or a problem on my side? Please see issue #3209 for more information

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 20, 2026, 4:38 AM ET / 08:38 UTC.

Summary
Keep open under this repository’s no-auto-close policy. This follows the still-open, maintainer-engaged original report; neither the existing fixes nor the Chrome-cookie hypothesis establishes why Claude’s cost chart remains stale.

Reproducibility: no. high-confidence current-main reproduction is established: the thread documents persistent symptoms but does not establish whether fresh supported local Cowork records reach the scanner.

Root-cause cluster
Relationship: duplicate
Canonical: #3209
Summary: This is an explicit follow-up to the same reporter’s open investigation; a technical root cause remains unconfirmed.

Members:

• canonical: I am using v0.55.0 - now after using it for a whole day, the token/spend chart does not refresh. no error message. it shows "updated just now" after refreshing, but only the session/weekly use updates. (I am not sure if I needed to create new issue, as the previous one was already closed) #3209 - Contains the original symptoms, repeated version retests, settings confirmation, and maintainer investigation.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Ways to help us reproduce this

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

Next step
Continue diagnostics in #3209 using the already-confirmed settings; obtain the current version and exact redacted cookie error before separating authentication from local-history discovery.

Review details

Best possible solution:

Resolve the original report with clear in-product source and freshness diagnostics that distinguish missing local history from failed quota authentication.

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

No high-confidence current-main reproduction is established: the thread documents persistent symptoms but does not establish whether fresh supported local Cowork records reach the scanner.

Is this the best way to solve the issue?

Unclear: cookie refresh can repair web quota authentication, but current source and maintainer guidance show it cannot populate local token history by itself.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The evidence does not distinguish missing or undiscovered local Cowork usage from a scanner/publication failure; the latest cookie complaint may describe a separate quota-fetch problem.

Codex review notes: model internal, reasoning medium; reviewed against c1e063d1e06b.

Label changes

Label changes:

• add P2: A persistent stale cost chart merits investigation, but the discussion reports functioning quota readings and no core availability failure.
• add impact:ux-friction: Independent chart inputs and refresh timestamps have led to repeated cookie troubleshooting without identifying the failing stage.
• add issue-rating: 🦪 silver shellfish: Current issue advisory state selects this label.
• add clawsweeper:needs-info: Current issue advisory state selects this label.

Label justifications:

• P2: A persistent stale cost chart merits investigation, but the discussion reports functioning quota readings and no core availability failure.
• impact:ux-friction: Independent chart inputs and refresh timestamps have led to repeated cookie troubleshooting without identifying the failing stage.

Evidence reviewed

What I checked:

• Original report remains open: I am using v0.55.0 - now after using it for a whole day, the token/spend chart does not refresh. no error message. it shows "updated just now" after refreshing, but only the session/weekly use updates. (I am not sure if I needed to create new issue, as the previous one was already closed) #3209 is open, belongs to the same reporter, and tracks the same stale chart. This issue explicitly points there and supplies no distinct reproduction.
• Maintainer guidance and subsequent reporter answers: The owner distinguished quota readings from local cost history and explicitly kept the original report open. The reporter subsequently confirmed Track costs is enabled, described Chat and Cowork activity, reported persistence through v0.60.5, and later suspected cookies. Those answers must not be discarded or requested again. See I am using v0.55.0 - now after using it for a whole day, the token/spend chart does not refresh. no error message. it shows "updated just now" after refreshing, but only the session/weekly use updates. (I am not sure if I needed to create new issue, as the previous one was already closed) #3209 (comment) and I am using v0.55.0 - now after using it for a whole day, the token/spend chart does not refresh. no error message. it shows "updated just now" after refreshing, but only the session/weekly use updates. (I am not sure if I needed to create new issue, as the previous one was already closed) #3209 (comment).
• Current local-history source boundary: Claude cost discovery reads configured project roots, default local Claude projects, and discovered Desktop project stores. Browser cookies are not an input to this discovery path. (Sources/CodexBarCore/Vendored/CostUsage/CostUsageScanner+Claude.swift:46, c1e063d1e06b)
• Supported Desktop history has focused coverage: Tests cover nested Desktop project logs and current Desktop sessions stored in shared Claude projects, asserting discovered roots and token totals. These tests were inspected, not executed; they do not establish that the reporter has matching local input. (Tests/CodexBarTests/CostUsageScannerClaudeDesktopTests.swift:6, c1e063d1e06b)
• Refresh already bypasses scanner debounce: The application token-snapshot loader passes bypassScannerDebounce: true. That existing mechanism alone cannot explain or resolve the reporter’s continuing Claude symptom. (Sources/CodexBar/UsageStore+TokenCost.swift:98, c1e063d1e06b)
• Related fixes do not establish resolution: The changelog identifies the original report’s clipped-date repair as partial. Nearby cookie-recovery and Cloudflare fixes concern web quota fetching, not proof that this local-history failure is fixed. (CHANGELOG.md:486, c1e063d1e06b)

Likely related people:

• steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

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.