akitaonrails/ai-usagebar

The problem

Antigravity relies on a Google session stored in the system password vault, read through external system tools on Linux and macOS. Those tools were launched inheriting every environment variable holding other providers' access keys, on each refresh that fell back to the saved session. The equivalent Grok Bot lookups already removed those keys.

What was done

The call on each system was reorganized to remove the keys before the lookup runs, without changing what is looked up or how. The reorganization and the behavior change were kept in separate steps, and a test confirms the removal on Linux and macOS.

Value delivered

API keys no longer reach a program that has no use for them, and the Antigravity lookup now follows the same rule as the tool's other outside calls (Grok Bot, Claude, Codex, GitHub and agy).

See PR #402 on GitHub

The problem

After the fix for five providers (PR #343), four format placeholders still carried provider text untreated: Claude's plan and model name, Codex's balance when OpenAI sends something that is not a number, and Ollama's cost. Ollama's default hover text also printed the activity period untreated. Any of them containing & or < reached Waybar as broken formatting.

What was done

The four placeholders and Ollama's period are now converted to safe text at the same point where each provider already handles its plan names. With this, the treatment the documentation already promised for plan and model names now actually holds for all of them.

Value delivered

Closes the remaining cases, including Claude, the last provider whose plan name went through untreated. People who customize their bar no longer see it break over unexpected provider text in these fields.

See PR #399 on GitHub

The problem

The command that adds an extra Codex account opens Codex's own interactive sign-in. That program was launched inheriting the environment variables holding other providers' access keys. The Claude sign-in already removed those keys; the Codex one had been left out.

What was done

The Codex sign-in now goes through the same cleanup as Claude's: the fixed list of known keys and any custom variable names the user configured are removed before the program starts. New tests check the cleanup on both sign-ins.

Value delivered

Narrows API key exposure: the Codex sign-in no longer receives other providers' keys, the same protection the Claude sign-in already had.

See PR #344 on GitHub

The problem

Users who build their bar or hover text from custom format placeholders got the plan and model names of Cursor, Z.AI, OpenAI (Codex), Kilo and Ollama untreated, most of them coming from the providers' APIs. Because the bar reads certain characters as formatting, a name containing & or < produced invalid text that Waybar rejected. These providers' default text was already handled; only the custom path was exposed.

What was done

The names are now converted to safe text at the point where they enter the placeholders, the same pattern already used for Kiro, OpenRouter and Antigravity. Each of the five providers gained a test with names containing & and <, which fails on the previous version.

Value delivered

Plan and model names from these five providers can no longer break or alter the formatting of a customized bar, and these providers now follow the rule others already did.

See PR #343 on GitHub

The problem

Before launching external tools such as the GitHub, Grok, Antigravity and Claude command-line programs, ai-usagebar strips provider keys from the environment variables passed to them so each key reaches only the service it belongs to. The list, however, held only the default names and those of custom providers. Keys from named accounts and from variables the user renamed, OpenRouter management keys included, were passed to all of those tools.

What was done

When the configuration loads, the program now registers for removal the variables of every named account, the default names the user changed and OpenRouter's management keys. Invalid or already covered names are still ignored, and two new tests fail on the previous version.

Value delivered

The rule that each key reaches only its own provider now also holds for people using named accounts or custom names, reducing the exposure of credentials to third-party programs.

See PR #328 on GitHub

The problem

The field meant for the name of the environment variable that holds the key sometimes gets the key itself, pasted in the wrong place. The program already avoided repeating that value, but two messages still showed it: Kimi's no-credentials error and the validation error for custom providers, which stops the whole configuration from loading. The key reached the bar's details popup, the scripting report and the terminal dashboard.

What was done

Kimi now names the variable only when it is a valid name and otherwise asks for a valid variable without repeating the value. The custom-provider error names the field without its content. Each message gained a test that fails on the previous version, and valid names still appear to guide the fix.

Value delivered

A common data-entry slip no longer exposes the API key on screen, and the message still points to the field that needs fixing.

See PR #326 on GitHub

The problem

Error messages for a config file that failed to load quoted the line where reading stopped. The most common mistake is a missing quote, and when it happens on an API key written in the file, the quoted line is the key itself. It showed up in the bar's details popup, in the warnings of every interface, in the scripting report, in the terminal dashboard, on the settings screen and in the error output.

What was done

A small function builds the message from the line, column and explanation only, without the line's content, and it applies wherever the file is read or written, including when accounts are registered. When the problem is a value of the wrong kind, the message still names the setting. The position is enough to find the mistake.

Value delivered

A common typo no longer exposes the API key on screen or in the terminal output, and the user still knows exactly where to fix it.

See PR #325 on GitHub

The problem

On Linux and macOS, when the config file has an API key written in it, the program restricts reading to the file's owner. The Ollama Cloud key was the only one of sixteen key fields missing from the list that triggers this protection. A file whose only key was Ollama's kept the permissions it was created with, usually readable by every user on the machine.

What was done

The Ollama Cloud key joins the list that triggers the protection. The new test walks every provider instead of naming each one, so a future provider that gains an in-file key without joining the list makes the test fail.

Value delivered

Anyone keeping their Ollama Cloud key in the config file no longer exposes it to other accounts on the same machine, and the automated check covers the providers to come.

See PR #320 on GitHub

The problem

On an authentication refusal, ai-usagebar stores only a neutral message on disk, because the server's response may carry account details. For SuperGrok, with an expired or revoked Grok Build login and the bar falling back to the last saved figure, the message on screen was still built from the raw response, up to 200 characters. It appeared in the Waybar details popup, the terminal dashboard and the scripting report on every new check.

What was done

The screens now show exactly the message stored on disk, as the other providers already did. The error is still recorded only when a saved figure goes on screen. A new test simulates a refusal whose response contains an email address and fails on the previous version.

Value delivered

SuperGrok users no longer have the content of an authentication response exposed in the bar, the dashboard or scripts, and what appears on screen matches what is recorded.

See PR #318 on GitHub

The problem

The documentation offers markers to show Antigravity's model group names in a custom format, and one group is called "Claude & GPT OSS". The text went untreated into the bar and its details popup, and a bare & is invalid in the formatting Waybar interprets, so the text was rejected. The plan name, which comes from the service itself, took the same path.

What was done

The five text fields (the plan and the four group names) are now converted to a form the formatting accepts before going into the bar and the details popup, the pattern Kiro and OpenRouter already followed. GNOME and macOS keep showing a plain &.

Value delivered

Anyone customizing the bar can show any model group without Waybar rejecting the text, and what comes from the service can no longer alter the bar's formatting.

See PR #317 on GitHub

The problem

The commands that add accounts, switch between them and merge conversation history across Claude Desktop profiles printed folder paths and account names untreated. A deliberately crafted name could carry terminal control codes able to change what appears on screen. History merging also touched the profile without the lock used by account switching and login renewal, so the processes could write the same files at once.

What was done

Every message from these commands now goes through a single cleanup before reaching the terminal, and a guard test rejects any new message that shows a path or error without it. History merging now waits for the same lock as account switching before touching the profile.

Value delivered

Anyone managing several accounts is protected from text that manipulates the terminal and from two processes changing the same profile at once, which can corrupt it. The guard test keeps future messages from bringing the problem back.

See PR #281 on GitHub

The problem

The KDE Plasma widget's card view colors each card with the highest severity among all its rows. Claude Code session rows, which measure context window use rather than quota, were part of that count. With a session at 90% and quotas at 29%, the main number read as calm, yet the Claude card turned red.

What was done

The card color now follows the same separation already applied to the main number and the panel slots: quota rows decide, and session rows count only when the provider has nothing else. The list of rows inside the card still shows everything.

Value delivered

Closes another spot on KDE where a long conversation looked like an exhausted quota, and the card now agrees with the widget's own main number.

See PR #401 on GitHub

The problem

The Windows tray icon takes its color from the most critical metric across all providers, and that count included Claude Code session rows, which measure context window use (the conversation size limit), not quota. A session at 90% painted the icon red while the quotas sat at 29%. Within the tray app, it was the last place still mixing sessions with quotas.

What was done

The color calculation now skips breakdown rows whenever the provider has a quota of its own; with no quota, they still count, as on the other screens. It is the same separation already used on Omarchy, Linux Mint, KDE and the macOS menu bar.

Value delivered

Red in the Windows tray once again means a quota is running low, and a long conversation no longer raises a false alarm at a glance.

See PR #400 on GitHub

The problem

Nous Research credits are shown with up to six decimal places, without trailing zeros. When the fraction was so small it rounded to zero, such as calculation residue near a whole number, all the zeros went away but the point stayed, so the bar and its details showed values like "1." or "0.".

What was done

After the zeros are removed, the formatting now also drops a decimal point left dangling at the end. Whole numbers and ordinary decimals stay the same.

Value delivered

Nous Research credit balances now always appear as well-formed numbers, on the bar and in its details.

See PR #394 on GitHub

The problem

The panel projects the pace of consumption to warn when a quota will run out before it renews. Early in a long window, such as the weekly quota of SuperGrok, Claude or Codex, a few hours of normal use already projected more than double the quota and set off the critical alert, with a flame and a run-out date. When showing what is left, the result was an 88%-full bar painted red.

What was done

In the first 15% of a window (roughly the first 25 hours of a week), with at least half of the quota still free, fast consumption now raises a yellow warning without the flame; Linux Mint got the same rule. Meters in the panel and the menu bar now always fill with what has been used (revisiting the direction taken in PR #389), and the used/left option changes only the numbers. A row at 0% also no longer vanishes against the dark macOS menu bar.

Value delivered

The critical alert signals real risk again: burning 55% in the first eight hours of a week still raises the alarm, but ordinary early-week use no longer looks like an emergency.

See PR #391 on GitHub

The problem

With the Codex login file signed out (blank credentials), the tool could try to renew access with an empty renewal code, which OpenAI rejected, or query usage with no credential. The server's refusal showed up as a temporary error and, when it came back as "too many requests", paused queries for five minutes, leaving the card wrong even after the user signed back in.

What was done

A blank credential is now treated as a sign-in problem, with a message asking to run "codex login", no network call and no pause. Renewal is attempted only when a renewal code is present, and in that case it restores access on its own before querying usage. Three new tests cover these paths.

Value delivered

Codex users get the right diagnosis and the action that fixes it, instead of waiting out a limit that does not exist. Claude already received the same treatment.

See PR #373 on GitHub

The problem

One of the macOS menu bar modes shows a badge with the provider's name and its highest usage percentage, the same number as the provider's tab in the panel that opens on click. When the provider also had a prepaid balance with a percentage, that balance joined the ranking: with 95% of it spent beside a weekly quota at 12%, the badge showed the dollar balance while the tab showed 12% (or 88% when showing what is left).

What was done

Balances no longer compete with quota windows and appear on the badge only when the provider has no window at all, the rule the panel already applied. Tests pin that rule on both sides, menu bar and panel, so they cannot drift apart again.

Value delivered

Anyone tracking usage from the menu bar sees the same number they find when opening the panel, in both reading modes. Two screens of the same tool stop contradicting each other.

See PR #363 on GitHub

The problem

The compact KDE widget that sits in the desktop panel shows a few numbers side by side. They were picked in report order without telling quotas apart from breakdown rows, so a Claude Code session at 90% of its context (or SuperGrok's per-product breakdown) appeared next to the 5-hour and weekly quotas and colored its slot with its own severity.

What was done

The slots now follow the same rule the widget's main number already uses: quota rows first, breakdown rows only when the provider has nothing else. How each slot looks is unchanged.

Value delivered

The panel's limited space now shows only what signals quota risk, with no visual alert caused by a long conversation. It closes a second path of the same problem on KDE.

See PR #362 on GitHub

The problem

With context tracking on, the widget also receives recent Claude Code sessions, each showing how much of its context window (the conversation size limit) it has used. The main number took the highest percentage across all rows, so a session at 90% became the headline, painted the widget red and triggered the alarm while the 5-hour and weekly quotas were low.

What was done

The headline is now picked from the quota rows only; session rows stand in only when the provider has nothing else. This is the same rule already applied on Omarchy and Linux Mint. New tests show the widget reading 29% with no alarm in the scenario where it used to read a critical 90%.

Value delivered

The widget's alarm once again means a real risk of running out of quota, not a long conversation. KDE Plasma users now get the same headline Omarchy and Linux Mint already showed.

See PR #345 on GitHub

The problem

With session tracking on, the Claude entry also lists each recent Claude Code session with how much of the conversation's text limit it already uses. The summary line in the Linux Mint tray menu showed the highest percentage across all of these, so a session at 90% appeared as Claude's usage while the 5-hour and weekly quotas were low.

What was done

Choosing the summary figure moves out of the graphical interface into the display rules module, where tests can reach it. The summary now picks among the quota rows, and grouped rows such as sessions are used only when an entry has nothing else. The full dashboard already kept those rows apart.

Value delivered

Linux Mint users see in the menu the figure that actually limits their Claude usage, under the same rule applied to the Omarchy bar.

See PR #324 on GitHub

The problem

With session tracking on, recent Claude Code sessions appear alongside Claude, each with how much of its text limit the conversation already uses. The Omarchy bar picked the highest percentage across every row, so a session at 90%, even one from yesterday, became Claude's value, turned the indicator critical and lit the bar's alarm while the 5-hour and weekly quotas were low.

What was done

The indicator now reads only the quota rows, and grouped rows such as sessions are used only when an entry has nothing else. The same rule covers SuperGrok's per-product slices, which are also a breakdown. The test that already reproduced the case gained checks that fail on the previous version.

Value delivered

Omarchy users again get an alarm that follows the quota that actually limits usage, with no false critical alerts caused by one long conversation.

See PR #323 on GitHub

The problem

With no team identifier configured, the default, every Grok check validates the management key before reading the prepaid balance. Errors from that step were stored without the server's status code: a revoked key put up to 200 characters of the response into the dashboard and report warnings, the Waybar bar showed the stale balance with no error at all, and a too-many-requests reply never triggered the five-minute pause.

What was done

The validation step now records the error with its status code, as the balance read already did. An authentication refusal becomes the standard neutral message, and too many requests trigger the shared pause. Network failures still fall back quietly to the last saved value.

Value delivered

Anyone tracking a Grok balance sees the key problem in the bar itself, without the server's response in the warnings, and the program stops insisting on a service that asked it to wait.

See PR #319 on GitHub

The problem

Kiro access lasts about an hour and is renewed before the usage read when it is close to expiring. If the network failed at that moment, as on a laptop waking up before it reconnects, the error became "run kiro-cli login again" and was recorded as the last error, next to the stale figure or in its place. The login was fine.

What was done

Network failures during renewal now pass through as temporary failures, which quietly fall back to the last saved value, as Kiro's own usage read and the Claude, OpenAI and Antigravity providers already do. The sign-in request is reserved for when the server answers and rejects the renewal.

Value delivered

Kiro users no longer see a false sign-in prompt when the network drops or is slow to come back, and the credential warning once again means a real problem.

See PR #316 on GitHub

The problem

Some Ollama Cloud Pro accounts report only a monthly limit, with no 5-hour or weekly window. The terminal dashboard and the report already showed that month, but the Waybar and macOS bars displayed 0% for the two missing windows and hid the real monthly usage. The documentation already promised the monthly percentage in the bar, and the code did not deliver it.

What was done

A window the account does not report is now left empty instead of turning into 0%, while real usage of 0% still shows as 0. The default bar format follows what the account reports: the 5-hour and weekly pair when it exists, or the monthly percentage. On macOS, the monthly limit now takes the main bar, labeled as monthly.

Value delivered

Anyone on a monthly Ollama Cloud plan stops seeing percentages for windows their plan does not have and sees the usage that actually limits it.

See PR #306 on GitHub

The problem

The command that reports usage across all providers exited with a failure code whenever every entry had an error, even after printing the complete report with the cause of each one. A monitoring script that trusted that code discarded the output and went silent exactly when every account was in trouble, the moment the diagnosis mattered most.

What was done

The command now exits successfully whenever it delivers the complete report, with each account's error still recorded inside it. The failure code is reserved for when the report cannot be produced: a missing, unreadable or invalid configuration, no provider enabled, or a startup failure. The command's help and the documentation state the rule, and a new test fails on the previous version.

Value delivered

Anyone monitoring AI usage through scripts now gets a per-account diagnosis in the worst case instead of silence. The success and failure rule is explicit and documented.

See PR #218 on GitHub

The problem

When agy's local server refuses a direct query, ai-usagebar uses the saved Google session to fetch the numbers from the cloud. It recognized that refusal by the exact text of the message, and agy 1.3.1 added a prefix to it. The refusal was then read as "signed out", the cloud lookup never ran and, with only agy open, Antigravity disappeared from the bar.

What was done

The check now accepts both the old and the new wording by looking at the end of the message, and keeps the other checks on the error. A refusal with a different message is still treated as a sign-in problem the user must fix.

Value delivered

Antigravity users see their numbers again after the agy update, and older versions of the tool keep working as before. The problem was reported by an Omarchy user.

See PR #379 on GitHub

The problem

Devin reports a daily and a weekly quota. To avoid presenting a 24-hour window as the 5-hour session, ai-usagebar does not put the daily quota in the session field, and the legacy macOS dropdown had nowhere else to show it. Selecting Devin left the main bar blank, the daily quota missing and the weekly one under generic labels.

What was done

The daily quota got its own fields at the end of the list the menu reads and now fills the main bar labeled "Daily" (1d), while the weekly one keeps "Weekly" (7d). With older versions of the program that do not send the daily quota yet, the weekly quota still shows as before.

Value delivered

Devin users on the legacy macOS menu now see both quotas the service reports, each with its own time frame, and the change does not break anyone still running an older version of the program.

See PR #372 on GitHub

The problem

DeepInfra is a prepaid, balance-only provider with no 5-hour or weekly quotas. The legacy macOS dropdown, still kept in the project, reads each provider from a fixed list of fields, and DeepInfra's balance was not on it. Selecting DeepInfra left the menu bar title empty and the menu without its credits row.

What was done

DeepInfra's balance was added to the fields the menu reads, at the end of the list so no other provider's data moves. The macOS documentation now lists DeepInfra and Lyceum among the balance-only providers.

Value delivered

DeepInfra users on the legacy macOS menu can now see how much credit they have left, with no change to how other providers are read.

See PR #364 on GitHub

The problem

On macOS, an additional Claude account whose login lives only in the Keychain (the system password vault), with no credentials file on disk, was listed as "not configured" in the provider catalog, the list that tells the interfaces which providers are ready on this machine. Usage fetching and automatic detection already found that account, so parts of the tool disagreed about it.

What was done

When an additional account has no credentials file on disk, the catalog now also checks that account's own Keychain entry. Nothing changes outside macOS.

Value delivered

People running several Claude accounts on a Mac no longer see a working account flagged as not configured, and the provider list now agrees with the usage the tool actually shows.

See PR #331 on GitHub

The problem

When renewing expired Grok Bot access, the program stored the new credentials under a different identifier from the one the next lookup used. Every check went back to the expired access and renewed again with the old credential. When the server accepts each renewal credential only once, the bar showed the old figure and then asked to sign in to the app again while valid credentials sat unused; otherwise, every check cost three requests.

What was done

Renewed credentials are now stored under the identity of the app sign-in they came from, the same rule Kiro and Antigravity already followed. A fresh sign-in in the app still never inherits the previous session's credentials. A new test runs two checks in a row and fails on the previous version.

Value delivered

Grok Bot users stop getting needless sign-in prompts and stale figures, and later checks go straight to the renewed access instead of spending three requests.

See PR #315 on GitHub

The problem

Support for multiple DeepInfra accounts was added to the program's core, but the macOS menu bar's list of providers with named accounts was not updated. As a result, the macOS app did not read those accounts from the config file and did not offer them in the menu or in Preferences.

What was done

DeepInfra joins the macOS list, and the app's documentation now mentions it. A new test checks that it is on the list and that the list holds the same ten providers as the program's core.

Value delivered

Anyone with several DeepInfra accounts on a Mac can now pick each one from the menu, as the rest of the program already allowed.

See PR #309 on GitHub

The problem

Anyone who set up a provider with named accounts only, or hid the default account, saw it marked "needs credential" in the provider catalog and in the status views of the terminal dashboard and macOS, even though usage was being read normally. The same happened to Claude and Codex when the login file lived at a custom path or in named accounts.

What was done

The status check now considers the named accounts of the ten API-key providers, plus Claude's and Codex's named accounts and custom paths. Automatic detection now also recognizes the named accounts of those two. Eight new tests cover these cases.

Value delivered

Anyone organizing access through named accounts sees a status consistent with what actually works, without false missing-credential warnings.

See PR #308 on GitHub

The problem

Among the providers that use an API key, only OpenRouter tracked several keys separately; anyone with work and personal keys elsewhere saw just one. Two bugs surfaced along the way: on macOS, OrcaRouter was never queried because the menu bar called it by a name the program rejected, and automatic detection ignored keys kept only in named accounts, leaving the provider switched off.

What was done

The eight providers get the same named-account feature as OpenRouter, and each account has its own tab in the terminal dashboard, its own line in the report, its own choice in the macOS menu and its own saved data. An unknown account name is an error and never falls back to the default key. New tests cover all nine providers, and both bugs are fixed.

Value delivered

Anyone using more than one key with the same provider, for example to separate work from personal use, can follow each one's usage without mixing the numbers. Existing configurations keep working with no changes.

See PR #266 on GitHub

The problem

The project formats money in a single place that respects each account's currency, because copies of that logic had once grown into four diverging versions. One old copy remained, always printing the dollar sign and used by no part of the program; only its own tests and a few comments mentioned it, as the example of the wrong way.

What was done

The function and its two tests were removed, and the comments were reworded to describe the counterexample without naming code that no longer exists. Negative-sign rules stay covered by the official formatter's tests, and nothing changes for users.

Value delivered

Less dead code, and no risk of someone reusing a formatter that would show a dollar sign on accounts billed in another currency.

See PR #403 on GitHub

The problem

The project has a reference guide, linked from the main documentation, with one section per provider describing the placeholders users can combine to build their bar text. Nous Research had no section, so its nine placeholders (plan, percentage, renewal and six more on credits) could only be discovered by reading the source code.

What was done

A new section, in the same shape as the others, explains what each placeholder carries, how credits are formatted, the default format, what appears when no percentage is available and which shared placeholders map to it. A general note that named only Kiro for a behavior Nous shares was corrected.

Value delivered

Nous Research users can customize their bar from the documentation instead of the code, and the reference now covers every provider.

See PR #396 on GitHub

The problem

Each API key card in the Omarchy settings screen carries a short note translated into the user's language. Lyceum's note ("billing credits") was left out of the translation dictionary when the provider was added, so it showed in English to people using Russian, Portuguese, Korean or Spanish.

What was done

The note was added to the dictionary with translations for the five supported languages: English, Russian, Brazilian Portuguese, Korean and Spanish. Tests check the text shown in each language.

Value delivered

People using Omarchy in Russian, Portuguese, Korean or Spanish see the whole settings screen in their language, with no stray English text.

See PR #395 on GitHub

The problem

Each report row states which of its two numbers leads: the percentage or the value, such as a prepaid balance or a credit spend. The KDE widget's main number already honored that, but the slots in the desktop panel, the card gauges and the rows of the pop-up window always showed the percentage. A row with 25% used and a value of $75.00 appeared as "25%".

What was done

All three places now follow the same rule as the main number: when the row asks for the value, the value is shown, and the percentage appears only if the value is empty. The alert color and the gauge fill are still driven by the percentage.

Value delivered

People tracking prepaid balances on KDE Plasma see the money figure in every part of the widget, consistent with the main number and with their configuration.

See PR #393 on GitHub

The problem

Users can choose to read usage as what has been consumed or as what is still left. On macOS the panel that opens from the icon followed that choice, but the compact bar chart in the menu bar ignored it. With the "left" option on, a fresh quota looked full in the panel and empty in the menu bar, and an exhausted quota looked the other way around.

What was done

The chart now reads the same setting as the panel: with "left" selected, each bar fills with the share still available, and rows without a percentage stay empty instead of looking full. During review, the maintainer reproduced the old defect and confirmed the new tests catch it.

Value delivered

Removes the contradiction between the menu bar and the panel for people who read usage as what is left. The fill direction was revisited shortly after in PR #391, which kept both screens in agreement.

See PR #389 on GitHub

The problem

On Windows the config file lives in a "config" subfolder of the application's data folder, but the program's help, the project's main page and three documentation pages gave another path. The Windows guide even created that file and opened it in Notepad. Nothing reads it, so settings were silently ignored, while whatever was saved from the tray or the dashboard went to the right place, which hid the mismatch.

What was done

All five places now name the real path, and the guide creates the correct folder. No program behavior changes; reading the old path as well, which would require a code change, was left to the maintainer's decision.

Value delivered

Windows users following the documentation now edit the file the program actually uses, without wasting time on settings that have no effect.

See PR #327 on GitHub

The problem

The program converts the ~ shortcut for the home folder in every path setting, but two had been left out: Command Code's login files and the GitHub command-line tool that Copilot uses. Turning on the documented example made Command Code report that the user was not signed in, and a path with ~ made Copilot claim the GitHub CLI was not installed.

What was done

Both settings now convert ~ like every other one, and full paths are left untouched. A new test covers both cases and fails on the previous version.

Value delivered

Anyone using ~ in these two settings, including the documented example, gets Command Code and Copilot working, without misleading messages about a missing login or a missing program.

See PR #321 on GitHub

The problem

When a user turned off the provider still set as primary (the one the bar shows by default) and it kept an API key, the settings screen reopened with that provider selected. The next save, whatever had changed, wrote the provider back as enabled and it started being queried again. The Omarchy settings panel followed the same path.

What was done

A disabled primary provider is no longer shown as the selected one; the screen shows the first enabled provider instead, a rule that already applied to Copilot and to keyless providers. Explicitly choosing a disabled provider is still the way to turn it back on. A new test reproduces the case and fails on the previous version.

Value delivered

The choice to switch a provider off is respected: it is not queried again because of a save that had nothing to do with it.

See PR #314 on GitHub

The problem

Each AUR package declares the files to download and, in a separate list, a checksum for each one. When the two lists end up with different lengths, Arch's packaging tool rejects the package, and this had already happened twice. The automatic check that runs before each release compared version numbers across eight files, but not this match.

What was done

The release verification step now compares the list lengths in both packages (the one built from source and the prebuilt one) and in their metadata files, and fails before publishing if they differ. The same check joined the project's regular test suite, so the mistake shows up during development.

Value delivered

Keeps a release from reaching the AUR with a package Arch Linux users cannot install. A mistake that had already recurred is now blocked automatically before publication.

See PR #347 on GitHub

The problem

Since the package started downloading each file's signature as well, every architecture needs two checksums. The bump to version 1.29.0 left only one, and Arch's packaging tool rejects lists of different lengths. The in-repository package would not build in a local test or in the manual AUR upload the release checklist describes, and the version check, which only looks at the number, let it through.

What was done

The two entries per architecture are restored in the recipe and in the package metadata file. Apart from the version number, both files are now byte-for-byte identical to the ones approved when signature checking was adopted. The automated publishing workflow had not been affected, because it rewrites these lists.

Value delivered

Anyone packaging or testing ai-usagebar on Arch Linux again has a recipe that works outside the automated workflow, and the manual publishing fallback no longer fails.

See PR #322 on GitHub

The problem

Since version 1.28.0, ai-usagebar has been released with a digital signature, but the AUR binary package neither downloaded it nor declared a trusted key. On installation, Arch Linux warned that it was skipping signature verification: the file was checked only by its checksum, which proves integrity but not authorship.

What was done

The package recipe now declares the maintainer's key and downloads the signature for each file, on both processor architectures, and Arch's packaging tool checks it automatically. The release workflow was adjusted to keep the checksum list as long as the file list, which the package needs in order to be accepted.

Value delivered

Anyone installing from the AUR now has assurance that the program was signed by the maintainer, not just that it arrived intact. This completes, on the packaging side, the hardening that began with signed releases.

See PR #288 on GitHub