CodexBar Still Shows 1% After a Quota Reset? Updating to 0.72.0 and Checking Authentication

First Check Whether This Fix Matches Your Problem

The developer's 0.71.1 release notes describe a specific issue: after a confirmed Codex weekly reset, an old snapshot without credit inventory could prevent new limits, reset credits, and the update timestamp from reaching the interface, leaving the reading near 1%. That release fixes this display-update condition; it does not mean upgrading resolves every quota problem.

Before troubleshooting, ask three questions: which account is shown, whether you are comparing the session or weekly window, and whether the displayed update time is still from before the reset. Recording only '1% remaining' is not enough because the same account may face limits in different windows. A note such as 'Account A / weekly window / update time' helps avoid comparing a personal account's menu bar reading with a work account's web page.

This guide follows the developer's documentation for the macOS menu bar app; it has not been installed or tested for this article. Start with one provider, confirm how its data corresponds to the account, then enable other subscriptions to reduce confusion between multiple accounts and windows.

Update Through the Original Installation Source and Confirm the Running Version

The macOS app requires macOS 14 or later. For a first installation, get the app from the official Releases linked below or use brew install --cask codexbar. If it is already installed, identify the original installation method instead of adding a second copy just to update it.

For an official release package, use Check for Updates in the menu or About and confirm installation when a downloaded update is ready. Homebrew installations do not use Sparkle updates and should follow the Homebrew route. The app's About screen also offers version checks and available upgrade actions; if an upgrade fails, check the upgrade command it displays.

After updating, reopen CodexBar and check About to confirm that the running version is 0.72.0. The developer released this stable version at 19:33 UTC on October 4, 2026, which was early October 5 in Beijing. A new file in your Downloads folder does not prove the upgrade succeeded. If the old version still appears, first identify which copy of the app is open and resolve the installation path; clearing account configuration is unnecessary for this check.

Choose a Data Source Before Granting Access

Open Settings → Providers and enable only the providers you need. Codex supports the OAuth API or the local Codex CLI, with optional web extras. Claude can use OAuth, browser cookies, or a CLI fallback. Each source has different requirements; providers do not all share one sign-in method.

Enable browser cookies only when needed. Tokens are stored in configuration files with restricted permissions. Full Disk Access is needed when reading Safari cookies or local storage; you can also check the other sources supported by that provider.

Start with a source whose account you can clearly identify. If a browser has several signed-in accounts, check which one is being imported. Do not grant every permission just to remove an empty reading, and do not post cookies, tokens, or complete configuration files in public support requests.

Refresh Once and Compare the Same Window

Use Refresh now in the menu. The refresh documentation explains that some temporary network failures preserve the last successful snapshot and its original timestamp, so a visible number does not prove a fresh fetch succeeded. Authentication failures and account changes are handled differently; use the menu's error state to distinguish them.

After the refresh, check the account, window name, update time, and value in that order, then compare them with the matching provider account's usage page. If the weekly window on the website has entered a new cycle but CodexBar still shows a pre-reset timestamp, first investigate whether the fetch succeeded. If both timestamps are recent but the windows differ, correct the comparison. This is a diagnostic approach, not a conclusion about a particular incident.

Refresh once and wait for the result instead of clicking repeatedly and losing track of which request succeeded. Until the timestamp and status are confirmed, treat the reading as unverified; do not buy extra quota or conclude that your subscription allowance has shrunk based on it.

0.72.0: Handle Sign-In Failures and Authorization Retries Separately

If adding a Google account to Antigravity returns invalid_client, update CodexBar, update the local Antigravity installation, and retry sign-in. Version 0.72.0 fixes OAuth client-pair discovery for Antigravity 2.19.1 on Apple Silicon and Intel. The developer's documentation also recommends updating Antigravity when discovery fails or Google rejects the client. This addresses that authentication cause; it does not resolve every Google sign-in failure, account eligibility issue, or quota restriction.

If browser-cookie access is blocked by Keychain, 0.72.0 allows an explicit user refresh to retry authorization. Check the selected provider and data source, click Refresh now, and decide whether to allow access based on the actual macOS prompt. Background refreshes should not repeatedly request permission. An explicitly enabled Disable Keychain access setting is still respected and cannot be bypassed by repeated refreshes. The absence of a prompt alone does not prove the update failed; check the source and error state to establish whether this access path was used.

After refreshing, verify the same account, actual data source, quota window, and new update time. Antigravity settings can show the last CLI, OAuth, or offline source used. Offline conversation history is not a live quota measurement, and Limits not available means neither zero quota nor a confirmed reset. CodexBar CLI 0.72.0 distinguishes rejected sessions, permission problems, and provider failures more clearly. Keep the error text and address the relevant step instead of using an old number as evidence of a sign-in result.

Enable Reset Notifications in the App

Open CodexBar Settings → Notifications and enable Reset notifications, which is off by default. It sends alerts for confirmed session or weekly resets. Whether those alerts appear also depends on macOS notification permissions and Focus or Do Not Disturb settings, so check the app switch and system settings separately.

Do not require an immediate notification as proof that setup worked, or deliberately exhaust quota to test the alert. At the next naturally occurring reset that you can verify, first confirm the account data has updated, then check the notification. A missing banner means the notification path still needs investigation; by itself, it does not prove the provider failed to reset the quota.

If Readings Still Differ, Choose the Next Step by the Symptom

If the provider's own page still reports insufficient quota, follow its account, cycle, and limit information first. Updating CodexBar or enabling notifications cannot change those rules. If the provider has restored quota but the tool's timestamp remains old, check authentication and fetch errors for the selected source. If the reading has updated and only the notification is missing, focus on notification settings instead of importing every account again.

When reporting an issue to the developer, include the operating system, CodexBar version, installation source, provider, selected data source, window type, and error text. Use redacted screenshots to show that both readings refer to the same account and cycle, and record when you observed them. Check screenshots for email addresses or account identifiers first. Tokens, cookies, and configuration file contents are not necessary feedback material. This makes it easier to distinguish a display defect from an actual account limit without exposing sign-in information while reproducing the issue.