Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
Agents panel: status card renders as an empty box when usageStatusText is set without authHelpText
Reported by davo42002 · filed Aug 26, 2026Closed upstream on 2026-10-04 by the bot omarchybot; the closing comment says it was fixed by PR #14049. GitHub close reason: completed.
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- Not yet mapped to any requirement or component.
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
What happened
In the agents bar widget, the status card's visibility is gated onusageStatusText, but the text it draws comes from authHelpText
(shell/plugins/agents/Panel.qml:498 and :512):
BorderSurface {
visible: !!root.provider && String(root.provider.usageStatusText || "") !== ""
...
Text {
text: root.provider ? String(root.provider.authHelpText || "") : ""A record with a non-empty usageStatusText and an empty authHelpText
therefore renders the card as an empty red box — border and urgent tint, no
text.
Why this is reachable
shell/plugins/agents/README.md documents adding an agent as an
out-of-tree concern:
Adding an agent therefore never touches this plugin: ship a collector that prints the record contract (see theclaudeandcodexcollectors inbin/), and the panel gains a tab.
The two fields are independent in that contract, and the combination is a
natural one: an agent whose provider publishes no quota endpoint has a real
status to report ("limits unavailable") but nothing auth could fix, so it has
no help line to offer. I hit this immediately writing a Gemini CLI collector —
Gemini CLI exposes no usage/quota API, so limits is empty and there is no
sign-in advice to give.
The shipped collectors don't surface it because all three happen to set both
fields together or neither, so the mismatch is invisible in-tree.
(Related but distinct: #6987 notes there is no Gemini collector. This report
is about the renderer, and would apply to any collector — in-tree or not —
that reports a status without an auth remedy.)
Latent in stock code too
bin/omarchy-agent-usage-fireworks:501 builds the pair as:
except FireworksError as error:
record = base_record(usageStatusText="Fireworks unavailable", authHelpText=str(error))str(error) is empty for any zero-argument exception. Every currentraise FireworksError(...) passes a message, so this doesn't fire today, but
the empty card is one argument-less raise away.
Steps to reproduce
- Write any record to
~/.local/state/omarchy/agents/usage/<id>.jsonwith
usageStatusText set, authHelpText empty, and enough activity for
providerHasData() (e.g. totalPrompts: 1):
jq -n '{schemaVersion:1, id:"demo", name:"Demo", ready:true,
hasLocalStats:true, totalPrompts:1, totalSessions:1, activeDays:1,
activeDates:["2026-08-26"], recentDays:[], modelUsage:{},
limits:[], tierLabel:"",
usageStatusText:"Demo limits unavailable", authHelpText:""}' \
> ~/.local/state/omarchy/agents/usage/demo.json- Open the agents panel and switch to the Demo tab.
Expected
No card when there is no text to put in it. The hero subtitle already carriesusageStatusText, so the card adds nothing in this state.
Actual
An empty red box between the subscription switch and TOKENS BY DAY.
Suggested fix
Gate the card on the text it actually renders:
visible: !!root.provider && String(root.provider.usageStatusText || "") !== ""
&& String(root.provider.authHelpText || "") !== ""Alternatively have the card fall back to usageStatusText whenauthHelpText is empty — though that duplicates the subtitle.
System
- Omarchy 4.0.1-1
- Hyprland 0.56.2
- Kernel 7.1.9-arch1-2
- Intel Core i5-1035G7 / Intel Iris Plus Graphics G7
(No diagnostics log attached: omarchy debug is not a command in 4.0.1 —omarchy commands --all lists no debug/diagnostics entry.)
View raw text
### What happened
In the `agents` bar widget, the status card's visibility is gated on
`usageStatusText`, but the text it draws comes from `authHelpText`
(`shell/plugins/agents/Panel.qml:498` and `:512`):
```qml
BorderSurface {
visible: !!root.provider && String(root.provider.usageStatusText || "") !== ""
...
Text {
text: root.provider ? String(root.provider.authHelpText || "") : ""
```
A record with a non-empty `usageStatusText` and an empty `authHelpText`
therefore renders the card as an empty red box — border and urgent tint, no
text.
### Why this is reachable
`shell/plugins/agents/README.md` documents adding an agent as an
out-of-tree concern:
> Adding an agent therefore never touches this plugin: ship a collector that
> prints the record contract (see the `claude` and `codex` collectors in
> `bin/`), and the panel gains a tab.
The two fields are independent in that contract, and the combination is a
natural one: an agent whose provider publishes no quota endpoint has a real
status to report ("limits unavailable") but nothing auth could fix, so it has
no help line to offer. I hit this immediately writing a Gemini CLI collector —
Gemini CLI exposes no usage/quota API, so `limits` is empty and there is no
sign-in advice to give.
The shipped collectors don't surface it because all three happen to set both
fields together or neither, so the mismatch is invisible in-tree.
(Related but distinct: #6987 notes there is no Gemini collector. This report
is about the renderer, and would apply to any collector — in-tree or not —
that reports a status without an auth remedy.)
### Latent in stock code too
`bin/omarchy-agent-usage-fireworks:501` builds the pair as:
```python
except FireworksError as error:
record = base_record(usageStatusText="Fireworks unavailable", authHelpText=str(error))
```
`str(error)` is empty for any zero-argument exception. Every current
`raise FireworksError(...)` passes a message, so this doesn't fire today, but
the empty card is one argument-less raise away.
### Steps to reproduce
1. Write any record to `~/.local/state/omarchy/agents/usage/<id>.json` with
`usageStatusText` set, `authHelpText` empty, and enough activity for
`providerHasData()` (e.g. `totalPrompts: 1`):
```bash
jq -n '{schemaVersion:1, id:"demo", name:"Demo", ready:true,
hasLocalStats:true, totalPrompts:1, totalSessions:1, activeDays:1,
activeDates:["2026-08-26"], recentDays:[], modelUsage:{},
limits:[], tierLabel:"",
usageStatusText:"Demo limits unavailable", authHelpText:""}' \
> ~/.local/state/omarchy/agents/usage/demo.json
```
2. Open the agents panel and switch to the Demo tab.
### Expected
No card when there is no text to put in it. The hero subtitle already carries
`usageStatusText`, so the card adds nothing in this state.
### Actual
An empty red box between the subscription switch and `TOKENS BY DAY`.
### Suggested fix
Gate the card on the text it actually renders:
```qml
visible: !!root.provider && String(root.provider.usageStatusText || "") !== ""
&& String(root.provider.authHelpText || "") !== ""
```
Alternatively have the card fall back to `usageStatusText` when
`authHelpText` is empty — though that duplicates the subtitle.
### System
- Omarchy 4.0.1-1
- Hyprland 0.56.2
- Kernel 7.1.9-arch1-2
- Intel Core i5-1035G7 / Intel Iris Plus Graphics G7
(No diagnostics log attached: `omarchy debug` is not a command in 4.0.1 —
`omarchy commands --all` lists no debug/diagnostics entry.)
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
No decision has been recorded yet.