* Place a bar widget on a bar without the widget it names
'omarchy bar put X --after Y' refused outright when Y was not on the bar, so
migration 1786279107 failed for every user whose clock is their own clone of
omarchy.clock rather than the built-in, and took the rest of the migration
chain down with it. put is the verb a migration or an install reaches for
precisely because it cannot know what the bar it places into looks like, so it
now falls back to the widget's usual spot instead of failing. 'plugin enable',
which someone types, still says when it cannot find the target.
A clone also answers as a placement target now, whether it is the widget the
placement named or the anchor the fallback lands against: cloning the clock
leaves a bar carrying your id where omarchy.clock used to be, and a caller
naming the source means the clone that took its place, the way resolveEnabledId
already routes calls to it. So the widget sits next to that clock rather than
at the end of the section.
Fixes#6678
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Keep asking a shell that is still starting
An 'omarchy update' landing while the shell restarts failed migration
1786279107 twice over. Quickshell answers a call made before it finishes
loading with "Not ready to accept queries yet." on stdout and exits 0, so a
caller polling with a ping read a starting shell as up and then took that
sentence for the answer to its real call; report it as unreachable, which every
caller already knows how to handle, and omarchy-restart-shell stops cutting its
readiness loop short on it too.
Reading the plugin manifests is a subprocess behind that, so IPC starts
answering before the registry knows the widget it is being asked to place, and
put refused it as unknown. Say which of the two it is and let put keep asking.
Only a shell that was never there is nothing to fail over. One that never
finishes starting, one that stops responding, one too old to know the call at
all: each has to fail, since omarchy-migrate records a migration that returns 0
as done, and the widget is then never placed and never asked for again.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Fall back for the shell an update has not restarted yet
omarchy-update runs its migrations before omarchy-update-restart, so the shell
answering migration 1786279107 on the update that carries this fix is still the
one that shipped without it, and it refuses the placement exactly as before.
The users this is for would have watched one more update go wrong. put owns the
fallback it documents, so let the command carry it: asked again without the
neighbour the shell says it cannot find, that shell places the widget.
A restarted shell never answers this way — it falls back itself, and knows to
look for a clone of the widget the placement named, which the command cannot.
Having answered once is now remembered across both asks. A shell that speaks
and is then gone has stopped mid-request, and reading that as a machine that
never had one would leave the migration recorded as done.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Wait for a shell that has not appeared yet
A shell being spawned has no socket to answer on, and nothing tells the command
a launch is under way, so a put landing in that window read the silence as a
machine without a shell and carried on — leaving the migration recorded as done
with nothing placed. Give one three seconds to turn up first. A machine that
genuinely has no shell still carries on, three seconds later.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Leave a clone of the widget being put where it is
A clone is the widget it was cloned from wearing its owner's name, so a bar
carrying one already has what put is being asked to place. put only saw the
literal id, and enabling a first-party source whose clone is active is how you
switch back to the built-in — so a migration placing omarchy.keyboard-layout
would have handed a user's own copy back for the shipped one, and called it
done. Targeting learned to read a clone as its source; presence had not.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Trim the comments on the bar put path
Roughly a line of comment per line of code, most of it restating what the code
and the assertion messages already say.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Add agent usage collectors that write display-ready data files
One omarchy-agent-usage-scan-<agent> collector per AI coding agent prints a
complete display-ready usage record — identity, tier, status, rate limits,
and today/week/all-time stats. omarchy-agent-usage-update runs every
collector it finds and writes the records atomically to
~/.local/state/omarchy/agents/usage/, so anything that displays usage only
ever reads JSON from there.
The Claude collector absorbs what the shell previously did in-process:
transcript scanning, the stats-cache/history fallback, credentials parsing,
and the OAuth limits probe, now with a probe throttle and last-good limits
kept across network failures. The Codex collector is the existing scanner
reshaped to the shared record contract.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Redo the model-usage plugin as omarchy.agents watching usage data files
The panel is now strictly a display. It discovers the JSON records that
omarchy-agent-usage-update maintains under
~/.local/state/omarchy/agents/usage/, watches them for changes, and draws
whatever appears — so adding an agent means shipping a collector, never
touching the panel. Marks resolve by convention (assets/<id>.svg with an
optional -light twin), the limits meters read a generic limits array, and
the per-provider QML adapters and in-plugin scanner scripts are gone.
Cross-device sync aggregation stays in the shell and keeps the snapshot
field names older versions wrote, so mixed-version fleets still merge in
both directions.
With the provider fan-out gone, the widget takes its real name: the plugin
id becomes omarchy.agents. A migration renames it wherever a user's config
mentions it — layout entries keep their settings and position, a disabled
widget stays disabled — then primes the data files once and drops the old
scanner cache. The migration test also drops a stale assertion that expected
migrations to restart the shell themselves, which c992cdff moved to
omarchy update.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Address Codex review: synced-only tabs, limits retry, history fallback
Three data-availability gaps from review. An agent whose records only exist
in synced snapshots — a collector installed on just one machine — now gets
its tab by unioning the synced aggregate into the provider list, with rate
limits blank since those never travel. A Claude limits probe that reaches no
server at all writes retryAdvised into its record, and the shell honors it
with one 30-second retry instead of waiting out the full refresh interval,
restoring the old boot-before-DHCP behavior. And a machine with only
history.jsonl — no transcripts, no stats-cache — still reports today's
prompt and session counts.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Address second Codex pass: history-only visibility, targeted retries
Today's prompt and session counts now count toward an agent's presence in
the bar, so a machine whose only Claude source is history.jsonl shows up
without waiting for limits. And the 30-second limits retry passes the
advising agent ids to the updater, so an outage at one provider no longer
puts every other collector on a retry treadmill.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Drop omarchy-cmd-present jq guards from the agents migrations
jq ships in the default package set, which makes it a runtime invariant per
AGENTS.md — call it directly. The migration tests lose their now-unused
omarchy-cmd-present stubs with it.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Drop the scan infix from the collector command names
Collectors are omarchy-agent-usage-<agent>; the updater skips its own name
when globbing them, and the update test proves it with a decoy.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Keep the credential store out of the printed usage record
The Claude collector now reads .credentials.json once into three scalars —
the access token, its expiry, and the plan label — instead of passing the
parsed store around. The token reaches nothing but the Authorization header
of the limits probe, and only the plan label may travel into the record,
which is what CodeQL's clear-text-logging alert on the record print was
unable to see when the whole dict flowed through.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Give built-in plugins an honest on/off state
Every built-in reported itself enabled no matter what. A bar widget said
"enabled" while sitting nowhere near the bar, and disabling a built-in service
silently did nothing, because enabled meant "listed in plugins[]" and a
built-in never is. Nothing surfaced that, since the only caller listing plugins
was the CLI.
For a widget, on and off is its place in the bar, so listPlugins reports layout
membership -- what enable/disable actually toggles. For everything else built
in, loading by default is the right behaviour to keep, so switching one off is
recorded the other way round, in disabledPlugins[]. shell.json still carries
only the deviation from the defaults: the key is dropped the moment nothing is
switched off, leaving a config that never disabled anything byte-identical.
isEnabled still answers a separate question -- whether the component loads at
all -- and deliberately does not follow a widget out of the bar. omarchy.menu
is both a widget and the menu itself, so tying the two together would let
taking its button off the bar lock the menu out of the shell, with no way back
that isn't the CLI.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Manage plugins from Setup > Plugins
Plugins were CLI-only. Setup > Plugins now offers Enable, Disable, Add, and
Remove, each list living in the menu itself so picking a row acts on it.
Enable and Disable cover the built-ins as well as anything installed -- the bar
widgets you can put in the bar, the services and overlays you can switch off.
Remove is limited to plugins the user installed, since a built-in has no
checkout to delete, and stays hidden until there is one. Whole-bar
replacements are left out; those are chosen under Style.
Enabling a bar widget asks for a section first, because enabling alone drops it
on the right and the only way to move it was a follow-up bar plugin move. The
CLI asks the same question after its own add, so both paths place a widget the
same way. Add and Remove run in a terminal: one needs a git URL and shows the
trust warning before cloning, the other deletes a checkout and prints where it
backed it up.
Providers grew two hooks for this. placementFor turns a row into a submenu
instead of an action, and volatile re-runs the enumeration when its submenu is
entered -- picking from these lists is what changes them, and rows a provider
no longer returns now drop out instead of lingering forever.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Trim the plugin menu after review
Menu.qml carried its own shellQuote while already importing Util and calling
Util.shellQuote a few lines up; two copies of the same escaping is one place
for a future fix to miss. isDisabled walked the array by hand to compare values
it writes itself, and dropDisabled was an eight-line helper with one caller.
Two bugs came out of the same pass. A whole-bar replacement belongs under Style
rather than these lists, but the exclusion sat in the shared row builder, so a
third-party bar could be installed and never removed -- Remove would show an
empty list under a guard that said something was there. The exclusion now sits
on the two lists that mean it.
Rows are keyed by id, and distinct plugin ids can slugify alike: acme.foo,
acme_foo and acme-foo all give acme-foo. The merge keeps the first row per id,
so the rest simply vanished from the list with nothing to say why. Row ids are
now made distinct before merging.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Pick a plugin the way we pick a theme
Setup > Plugins listed plugins as menu rows, which needed three providers, a
placement submenu, a volatile-refresh hook and a row-swap in the merge. Only
Font and Apps are built that way. Theme, Background, Unlock, Timezone and
Keybindings all pipe a list into omarchy-menu-select instead, which is one
action string and a small script -- so that is what these use now.
The trade is search: a plugin name is no longer findable from the root prompt.
Neither is a theme name or a timezone, and Enable Plugin still is, so the loss
sits where the rest of the menu already puts it.
Two pieces of the row machinery stay, because they are worth having for the
lists that remain. A volatile provider re-runs when its submenu is entered, so
a font installed since the shell started now shows up without restarting it,
and rows a provider stops returning drop out. Row ids are still made distinct
before merging: Fira Code and Fira-Code both slug to fira-code, and a repeated
id was silently dropped.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Let a picked option carry an icon
Moving the plugin lists onto omarchy-menu-select cost them their glyphs: the
select mode has always hardcoded an empty icon, which is why Timezone and
Keybindings have none either. An option may now lead with one, as
"<glyph><TAB><label>". The menu shows the glyph, filters on the label, and
hands the label back, so a caller never strips a glyph off its own selection
and a list of plain strings behaves exactly as before.
The plugin picker uses it for the puzzle glyph on each plugin and the align
glyphs on the sections, which also regain the capitals they lost when the
section names were passed through raw.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Switch bars by enabling one
A bar option was kept out of Enable and Disable on the grounds that picking
which bar to run belongs under Style -- but nothing under Style ever offered
it, so an installed bar could be added and removed and never actually put to
use. The menu was guarding a door to a room that was never built.
Enabling one is the switch. setEnabled already assigns bar.id for a bar
option, so a bar has always replaced the one before it; only the picker's
filter stood in the way. Dropping it costs nothing else, because enabled for a
bar option means active: the bar in use is the one row absent from Enable,
every other installed bar is one pick away, and the built-in is just another
entry, so going back to it is enabling Bar.
Disable keeps the exclusion. That is the one verb a bar cannot answer -- there
is no off, only a successor -- and offering it would have listed the built-in
bar on a stock system, where turning it off deletes a bar.id that was never
set and nothing happens.
A bar carries the bar glyph rather than the puzzle one, so a row that replaces
the whole bar does not read like one more widget to switch on, and enable now
says "Now using X as the bar" instead of "Enabled X", which understated a
whole-bar swap in both the enable and the freshly-added path.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Refuse a plugin that declares a kind it cannot load
A kind is a promise to supply something to load, and the shell reads that
something from a fixed key: entryPoints.bar to draw a bar, entryPoints.menu to
open a menu. Nothing checked the promise. A manifest could claim kinds ["bar"]
with no bar entry point, pass validation, install, and enable -- and then the
bar would fall back to the built-in and the widget would be skipped, leaving a
plugin that does nothing, explained only by a console.warn nobody reads.
Our own plugins have been held to this table by plugins-test.sh all along.
This holds third-party ones to the same table, at add and update time, where
there is still someone to tell.
A kind outside the table is left alone rather than guessed at, so a shell that
learns a new kind does not need this list updated first. The cost is that a
misspelled kind still installs quietly.
omarchy-plugin-validate had no tests; it has some now.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Act on the plugin whose row was picked
The picker showed a name and then looked that name up again across every
plugin, filtered set or not, taking the first match. Two plugins can share a
name: cloning one keeps the name it was cloned from, so the documented
`omarchy plugin clone omarchy.clock local.clock` leaves two plugins called
Clock. Enable listed the clone -- the built-in was already enabled, so only the
clone was eligible -- and then enabled omarchy.clock, moving the built-in
widget instead. Remove listed the clone and tried to delete a built-in that has
no checkout to delete.
A row now carries its id alongside its label, and the id is read back off the
row that was picked instead of being derived from the name a second time. Where
a name is not unique among the rows on offer, the label carries the id too, so
two rows that would both say Clock can be told apart at all -- which they could
not before, whichever one the pick resolved to.
The verb prompt only ever sees the first two fields, so the menu shows what it
always did.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Never ask a bar where to sit in the bar
A manifest may declare both bar and bar-widget, and validation accepts it. The
picker saw bar-widget, asked for a section, and passed it to enable. setEnabled
takes bar as the dominant kind: it writes bar.id and returns, adding nothing to
any layout, so the move that followed had no widget to find and failed -- after
the bar had already been switched. A partial success with an error on the way
out.
Bar wins ahead of bar-widget now, in the picker and in the placement prompt
`plugin add --enable` asks, so a bar is enabled without a placement it cannot
use. The CLI refuses a placement on a bar outright, before the bar is switched
rather than after, since `omarchy plugin enable <bar> --section left` could
reach the same half-applied state without going through either.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Only replacement, no off
* Add default placement for bar widgets
* Simplify plugin menu actions
* Document plugin placement behavior
* Allow dropping widgets in empty bar space
* Treat plugin dependencies as runtime invariants
* Reject duplicate plugin ids on add
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Bring the fingerprint affordance to the Quickshell lock screen and polkit
dialog, matching what hyprlock did on master.
Lock screen: render the md-fingerprint glyph inside the password field's
right edge when a sensor is enrolled, reserving space so long passwords
never run under it.
Polkit dialog: show one method at a time. When a sensor is enrolled and
the reader is reachable, the dialog is just the centered fingerprint icon
(square card); the moment PAM asks for a password it switches to the
password field. Detects pam_fprintd anywhere in the auth stack now that a
gate can precede it.
Lid awareness: a closed lid means the reader is unreachable, so both
surfaces fall back to the password. polkit gets a pam_exec clamshell gate
(auth [success=1 default=ignore] before pam_fprintd) so a shut lid drops
straight to the password prompt instead of blocking on the reader for the
pam_fprintd timeout; the lock screen hides the icon and skips scanning.
The gate points at the fixed /usr/bin path the package always provides so
it survives switching between package installs and dev-link. A migration
adds the gate for existing fingerprint setups.
New helper omarchy-hw-laptop-closed (pure lid state); omarchy-hw-clamshell
now composes it with the external-monitor check.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Accumulate sub-threshold movement so slow motion with a flat acceleration profile updates selection. Sample pointer state on row entry and carry pointer intent through subordinate menus while preserving predictable keyboard selection.
Same treatment as Stay Awake: the indicator polled the toggle CLI over
a Process with a timer to paper over the race after clicking, and the
CLI ended by asking the shell to refresh every indicator over IPC. A new
omarchy.nightlight service owns hyprsunset instead - it probes the
temperature on startup, applies changes itself for in-shell toggles, and
answers on the nightlight IPC target. The indicator becomes a plain
binding. The CLI still drives hyprctl directly so keybindings, the menu,
and ssh work without the shell, but now just nudges the service to
re-probe since hyprsunset has no state file to watch.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Deriving the tray's implicit size from childrenRect fed layout results
back into the bindings that produced them, tripping implicitWidth
binding loop warnings. Compute it from the active and inactive blocks'
own implicit sizes instead, and center the loaded blocks rather than
anchor-filling containers that are sized by their content. The contract
test now instantiates the tray to check the collapse/expand cycle and
fails on any implicitWidth binding loop in the log.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The indicator polled omarchy-toggle-idle over a Process and re-ran it on
a timer to toggle, while the CLI called back into the shell over IPC to
apply and refresh the state it had just changed. Now the indicator binds
straight to the idle service's stayAwake property and flips it in
process. The CLI only touches the state file, which the service already
watches, so toggling from keybindings and scripts still reaches the
shell without any reentrant IPC.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Long passwords used to overflow the input field and clip with no
feedback that typing was still registering. Scale the dot size and
letter spacing down as the password grows, like macOS, so every
keystroke stays visible.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
