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: let plugins extend the per-provider brand-mark assets
Reported by FelipeMayerDev · filed Sep 15, 2026 · open at source
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?
- AreaOutside the audited area· Decided by agents · verified
- 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?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
The problem
The built-in agents panel resolves each provider's brand mark by convention from its own assets directory:
\\\`
/usr/share/omarchy/shell/plugins/agents/assets/<id>.svg
\\\`
(\Panel.qml\, \iconCandidatesForProvider()\ — \assets/<id>.svg\, with an \assets/<id>-light.svg\ twin for light surfaces.)
That directory ships with omarchy and is root-owned, so a third-party plugin that feeds the panel (in my case a Z.ai GLM Coding Plan usage collector) can never ship its own mark:
- The panel README documents \
assets/<id>.svg\as the extension convention ("Marks resolve by convention, so a new agent's data file needs nothing from this panel"), but only built-in ids can ever match it. - The only workaround for a plugin author is writing into a root-owned directory under \
/usr/share\, which needs sudo, gets wiped by omarchy upgrades, and can conflict with package-managed files.
Today the tab falls back to the generic bar glyph, which works but loses the visual identity the panel was clearly designed around (every built-in provider has a mark).
Proposal
Let a plugin's own directory participate in the mark resolution. For example, in \iconCandidatesForProvider()\, also probe a path relative to the plugin that supplied the usage record (or a user-writable assets directory), e.g.:
\\\`qml
// after the built-in candidates
candidates.push(Qt.resolvedUrl(pluginDir + "/assets/" + p.providerId + ".svg"))
\\\`
Any of these would work and stay backwards compatible (built-in marks keep winning or remain the first candidate):
- Per-plugin assets — resolve \
assets/<id>.svg\relative to the directory of the plugin/manifest that provides the record. - User assets dir — probe something like \
~/.config/omarchy/shell/assets/<id>.svg\as a fallback, so users (and plugins' install scripts) can drop marks without root. - Record-carried path — allow an optional \
icon\field in the usage record pointing at a local file.
Option 2 is probably the smallest change and benefits more than agents: any panel that resolves marks by convention could get the same user-level fallback.
Context
With any of these, my plugin can bundle \zai.svg\ and have the icon "just work" on install — no sudo step, nothing for an upgrade to wipe. Happy to send a PR if you point me at the preferred shape.
View raw text
## The problem
The built-in agents panel resolves each provider's brand mark by convention from its own assets directory:
\`\`\`
/usr/share/omarchy/shell/plugins/agents/assets/<id>.svg
\`\`\`
(\`Panel.qml\`, \`iconCandidatesForProvider()\` — \`assets/<id>.svg\`, with an \`assets/<id>-light.svg\` twin for light surfaces.)
That directory ships with omarchy and is root-owned, so a third-party plugin that feeds the panel (in my case [a Z.ai GLM Coding Plan usage collector](https://github.com/FelipeMayerDev/omarchy-zai-usage)) can never ship its own mark:
- The panel README documents \`assets/<id>.svg\` as the extension convention ("Marks resolve by convention, so a new agent's data file needs nothing from this panel"), but only built-in ids can ever match it.
- The only workaround for a plugin author is writing into a root-owned directory under \`/usr/share\`, which needs sudo, gets wiped by omarchy upgrades, and can conflict with package-managed files.
Today the tab falls back to the generic bar glyph, which works but loses the visual identity the panel was clearly designed around (every built-in provider has a mark).
## Proposal
Let a plugin's own directory participate in the mark resolution. For example, in \`iconCandidatesForProvider()\`, also probe a path relative to the plugin that supplied the usage record (or a user-writable assets directory), e.g.:
\`\`\`qml
// after the built-in candidates
candidates.push(Qt.resolvedUrl(pluginDir + "/assets/" + p.providerId + ".svg"))
\`\`\`
Any of these would work and stay backwards compatible (built-in marks keep winning or remain the first candidate):
1. **Per-plugin assets** — resolve \`assets/<id>.svg\` relative to the directory of the plugin/manifest that provides the record.
2. **User assets dir** — probe something like \`~/.config/omarchy/shell/assets/<id>.svg\` as a fallback, so users (and plugins' install scripts) can drop marks without root.
3. **Record-carried path** — allow an optional \`icon\` field in the usage record pointing at a local file.
Option 2 is probably the smallest change and benefits more than agents: any panel that resolves marks by convention could get the same user-level fallback.
## Context
With any of these, my plugin can bundle \`zai.svg\` and have the icon "just work" on install — no sudo step, nothing for an upgrade to wipe. Happy to send a PR if you point me at the preferred shape.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.
- Out of scopeDecided by agents · verified · 2026-10-09 13:36 UTC