5edc3497fa6eecaca37ce41cdf2f576a81646815
425
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
5edc3497fa |
Bind SUPER + CTRL + a number to the bar's right panels (#6702)
The letters name a panel; the numbers count them. One is the leftmost panel in the right section, so the number matches the icon a user would point at: a widget with no panel of its own is passed over, and so is one that is hiding itself. Counting rather than naming means the hotkeys follow the bar. Rearranging the section, or adding a widget to it, renumbers the panels with no binding to rewrite. Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
David Heinemeier HanssonandClaude Opus 5
|
efe805387e |
Title a model-scoped limit the way the flat ones title themselves
A scoped window read as "Fable weekly" beside "Session" and "Weekly", so the one row that names a model was also the one row in lowercase. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
0ad64a59df |
Fix command injection in theme install, drop tzupdate NOPASSWD (#6694)
* Fix theme install code execution and drop tzupdate NOPASSWD
VULN-01 (C, D, E): a malicious theme can execute arbitrary code
during install through three injection sinks:
C: colors.toml values reach a sed script unsanitized.
GNU sed's `e` flag runs the pattern space as a shell command.
D: vscode.json `.name` is interpolated into a sed replacement
string without escaping sed metacharacters.
E: keyboard.rgb content is interpolated into a python3 -c
argument without validation.
Fix C by validating keys and values in omarchy-theme-color's parser
with a character allowlist. Byte-identical output for all 22 shipped
themes.
Fix D by escaping backslash, ampersand, and slash in the theme name
before sed interpolation.
Fix E by gating on ^[0-9A-Fa-f]{6}$ before interpolation, in both
the Framework 16 and ASUS ROG keyboard scripts.
VULN-02: the tzupdate sudoers grant has no argument constraint.
tzupdate -l lets any wheel user write a root-owned symlink to any
path. Drop it; nothing has invoked tzupdate since omarchy-cmd-tzupdate
was removed. Keep timedatectl set-timezone.
* Harden keyboard and vscode theme scripts
keyboard-f16: pass hex as sys.argv instead of interpolating into
python3 -c. The hex validation gate stays as the primary defense;
argv separation is defense-in-depth per OWASP guidance.
vscode: replace sed interpolation of theme name with jq, which
handles arbitrary strings safely via --arg. Validate extension IDs
against ^[a-zA-Z0-9._-]+$ before passing to --install-extension.
* Keep VS Code settings edits JSONC-safe
settings.json is JSONC, so routing the write through jq dropped theme sync
entirely for anyone with a comment or trailing comma in the file, including
the `{ "workbench.colorTheme": "",\n}` shape Omarchy itself creates. Edit in
place again and close the injection by validating the theme label instead.
Scope the extension-id guard to the install so a malformed id no longer skips
the colorTheme write, and treat a missing descriptor field as empty rather
than the literal string "null".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* Widen the accepted colors.toml value charset
The sanitizer dropped gradient angles, decimals, underscored palette
references, and paths, which vanish from --raw/--all and leave a raw
{{ placeholder }} in the generated config. Allow the punctuation real
palettes use, keep out everything sed treats as special, and say so on
stderr rather than dropping a key silently.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: David Heinemeier Hansson <david@hey.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
|
||
|
|
2b38f75506 |
Show the per-model weekly limit Claude's usage endpoint reports (#6691)
* Show the per-model weekly limit Claude's usage endpoint reports Model-scoped allowances arrive in the payload's limits array, not in the seven_day_<model> buckets, which come back null. Read them so a window like Fable's own weekly limit stops being spent against invisibly. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Read every model-scoped window, and title it for what it is A model can hold more than one scoped window, so keying the dedupe on the model alone dropped whichever came second — including a fuller one that decides the headline. The model and the window kind together make the key, and both make the title, so one model's two rows read apart. The panel guesses a window out of the label, and that guess cannot survive a model name: "Opus 5 (1M context)" parses as a one-minute window and renders as a second "Session". The collector states the title outright now and the panel takes it, eliding a long one rather than running it into the percentage. Scoped percentages are read on whatever scale the payload speaks, the way the flat buckets already are, rather than assuming percentages, and a model that names only an id still names a window worth showing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: David Heinemeier Hansson <david@hey.com> |
||
|
|
1e7bb66556 |
Recover a session lock stranded by a dead shell (#6692)
* Detect a compositor session lock through one helper omarchy-restart-shell decided whether the session was locked by looking for "LOCK" anywhere in the hyprctl monitors payload. That works, but not for the reason the code reads like: Hyprland reports no lock state of its own, and the string comes from solitaryBlockedBy, the list of reasons a monitor cannot hand a client the whole screen. An active ext-session-lock is one of those reasons. A substring match over the whole payload also answers yes to a workspace or a monitor description that merely spells LOCK, and locking a desktop nobody asked to lock is the worst way to be wrong. Match the reason list itself, and put it behind a helper now that a second caller needs the same answer. That second caller needs a third answer too, because the reason list is not always readable. Hyprland stops at the first reason on a monitor with no workspace yet — one just coming back — and returns before it ever looks at the lock, so a missing LOCK there means nothing was asked rather than nothing was found. Neither that nor an unreachable compositor is an unlocked session, and locks strand precisely while outputs are coming and going, so both exit 2. Callers that only branch on success are unaffected. The test fixture claimed the string came from a workspace name, so it was encoding the wrong model of the compositor. It now returns what Hyprland actually returns. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Retake a session lock stranded by a dead shell ext-session-lock keeps the session locked when its client goes away — that is the point of the protocol, so a crashing lock screen cannot expose the desktop. The cost is that a shell which dies while locked leaves the compositor locked with nothing left to authenticate against: Hyprland's failsafe, which takes a TTY or another machine to clear. Nothing carried the lock across a restart. Quickshell relaunches itself after a crash and omarchy-restart-shell can be run by hand, but both bring back a shell holding no lock, so the failsafe stayed up. A fresh shell never holds a lock, so a session already locked as the lock service starts can only be that orphan: take it back and let the user type their way out. Asking once is not enough. These deaths happen while outputs are going away, and the replacement shell comes up inside that same window, where there is nothing to read a lock off. So the question is asked until the answer means something: on a short timer while the session settles, and again when a screen comes back, since a display asleep for hours outlasts any timer worth running and returns through a state the compositor cannot answer for either. Once an answer does arrive the search ends, so the timer stops and later screen changes cost nothing. Three ways this could lock a desktop nobody asked to lock, all closed. A lock this shell took itself is not an orphan, including one taken while the question was in flight — omarchy-restart-shell re-locks a fresh shell, and the answer cannot tell whose lock it found. Recovery runs once and clears the flag, so nothing lingers to fire after an unlock. And PAM landing late reopens the question rather than answering it: clearing the failsafe from a TTY is the documented way out, so a yes from before there was anything to do about it may be stale by the time it can be acted on. The check has to live here rather than in the launcher. Quickshell's crash handler re-execs in place, keeping the same pid, so a supervising process never sees the restarts that recovery matters most for. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Relaunch the shell when it dies without a signal Quickshell restarts itself after a crash, but only from its signal handlers: SIGSEGV, SIGABRT, SIGFPE, SIGILL, SIGBUS, SIGTRAP. Qt does not always leave that way. When the Wayland connection fails, QWaylandDisplay::checkWaylandError calls _exit() directly, which raises no signal at all — so the crash handler never runs, no report lands in ~/.cache/quickshell/crashes, and the desktop is left with no bar and no explanation. That is how #6684 ends: the lock path meets a screen with no valid Wayland output, declines to create a lock surface for it, and the connection dies with EINVAL. Supervise the launcher so those deaths come back. A clean exit is deliberate — omarchy-restart-shell stops the shell over IPC and starts its own replacement — and a signal to the supervisor means the session is going away, so neither relaunches. Neither does a shell that outlived its compositor, though that takes more than one unanswered query to conclude: the shell dies while outputs are being reconfigured, which is also when a busy compositor can miss one without being gone. A shell that cannot stay up gives up after five tries in a minute rather than spinning. Signals need care now that a launcher stands between the session and the shell. Bash defers a trap until a foreground command returns, so the shell runs as a job and the supervisor waits on it. Stopping the launcher used to stop the shell with it, back when this script exec'd Quickshell, so the signal is passed on rather than leaving a desktop nobody is watching. One arriving during the backoff sleep only reaches the trap afterwards, so the flag is read again at the top of the loop: a shutdown racing a crash would otherwise get one more Quickshell on its way out. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
3d1914a8cd |
Let bar put place a widget on a bar it does not recognize (#6687)
* 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> |
||
|
David Heinemeier HanssonandClaude Opus 5
|
536fcd5c6c |
Move install-time plumbing out of the setup namespace
setup is where a user goes to configure something: direct boot, security keys, hibernation. These three are not that. omarchy-apply-system is the ISO's entry point in the target chroot, omarchy-apply-hardware is what it calls for device quirks, and omarchy-apply-lock is called by install/config/lockscreen-pam.sh. apply is the verb they already used to describe themselves, and it carries the contract: declared state under install/ converged onto the machine, idempotent, safe to repeat. The group gets no GROUP_DESCRIPTIONS entry on purpose. That table drives the top-level group list on its own, so an entry would put apply back in front of users even with every command in it hidden, the way provision already stays out. A test covers it. The ISO installs the runtime from the mirror it ships with, so it moves to the new names in lockstep and no compatibility route is needed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
David Heinemeier HanssonandClaude Opus 5
|
477284f002 |
Hide install-time setup plumbing from the command listing
The setup group is described as interactive setup wizards, but these three are not that. omarchy-setup-system is the ISO's entry point in the target chroot, omarchy-setup-hardware is what it calls for device quirks, and omarchy-setup-lock is called by install/config/lockscreen-pam.sh. None of them is something to browse to and run. Hiding only affects listings, so the ISO and the install leaves keep routing through the CLI exactly as before. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
186668a70f |
Apply the Broadcom Wi-Fi quirk to Macs without a T2 (#6652)
* Apply the Broadcom Wi-Fi quirk to Macs without a T2 brcmfmac lets the Wi-Fi firmware run the WPA handshake itself, and on Apple hardware that offload fails against an access point in WPA2/WPA3 transition mode: the client associates, the four-way handshake never completes, and NetworkManager reports the password as wrong. feature_disable=0x82000 turns off the firmware supplicant and authenticator so wpa_supplicant does the handshake in software. That quirk already shipped, but only for Macs with a T2 chip. The bug is in the Broadcom firmware rather than in the T2 bridge, so it was never the right thing to gate on: a MacBookPro11,4 has BCM43602 with 2015 firmware, fails exactly this way, and got nothing. Gate on the hardware that actually has the firmware — an Apple machine with a Broadcom wireless part — which covers both. Moving it out of fix-t2.sh also leaves one owner for the file. Two leaves writing the same config would have meant the later one silently winning, decided by an ordering in all.sh nobody would think to check. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Gate the Broadcom Wi-Fi quirk on the T2 ID or a brcmfmac chip ID Sniffing lspci for an Apple vendor with a Broadcom network controller made T2 Macs depend on a detection line they never needed: they carry a T2 PCI ID that is always there, and the class name half of `lspci -nn` comes from the pci.ids database. Keep their original gate untouched. Naming the rest by DMI model does not hold up either, because the model year does not predict the part. A MacBookPro11,4 from Mid 2015 carries a BCM43602 and needs this; a MacBookAir7,2 from Early 2015 carries a BCM4360 and does not. Covering the lineup by name takes around twenty identifiers across four product lines and grows every time Apple ships hardware. The set has an exact definition already: the PCI IDs brcmfmac binds, from the driver's own brcm_hw_ids.h. That reaches the 2016 and 2017 MacBook Pros and the T2-less iMac19,1 and iMac19,2 that a hand-written list missed, and it leaves out the BCM4360 Macs for free, since their out-of-tree wl driver would never read a brcmfmac option anyway. Matching an exact vendor:device ID also drops the piped `grep -q`, which returns 141 under pipefail once the producer is killed by SIGPIPE (#6608). The test runs the leaf with pipefail so the chatty lspci stub proves it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Fix Macs already installed without the Broadcom Wi-Fi quirk The quirk is written at install time, so a machine set up before it shipped never gets it, and no pre-T2 Mac ever did. Those installs still fail the WPA four-way handshake against an access point in WPA2/WPA3 transition mode, which is the state the reporter had to repair by hand. Appending leaves anything else in the config alone: modprobe reads every options line for a module, and nothing else sets feature_disable. Only an active options line counts as already applied, and the driver keeps the old behaviour until it reloads, so this asks for a reboot rather than pulling brcmfmac out from under a connection that currently works. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: David Heinemeier Hansson <david@hey.com> |
||
|
|
c53190be07 |
Remember Bluetooth on/off through the rfkill soft block (#6682)
* Turn Bluetooth off with an rfkill soft block BlueZ never persists an adapter's Powered property, so turning Bluetooth off in the panel lasted only until the next boot. Omarchy's answer was AutoEnable=false, which persists nothing either — it just means "never power the adapter on", so Bluetooth came up off every boot whatever the user had chosen. The soft block already does the job. systemd-rfkill saves every switch under /var/lib/systemd/rfkill and restores it early on the next boot; that is the entire purpose of the unit. Blocking also covers every controller at once, where bluetoothctl only ever addresses the default one. So the block becomes the state and BlueZ follows it: with AutoEnable back at its stock default, lifting the block is enough for bluetoothd to power the adapter up on its own. Powered still tracks the block, so the panel switch and icon read it exactly as before. Everything that turns Bluetooth on or off goes through omarchy-bluetooth-power, because bluetoothctl power on fails while a block is set. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Carry installed machines over to the rfkill block Existing installs have AutoEnable=false, so their adapter is down at every boot and Powered is the only record of what the user actually wants. Read it before anything changes, hand it to the block, then put AutoEnable back to its default so bluetoothd can act on that block. Only the exact line Omarchy wrote is reverted, so a hand-edited opt-out survives. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Ask the power helper for a direction, not a toggle The helper runs detached and the switch only moves once BlueZ catches up, so a second click inside that window re-read the pre-click state and undid the first. The panel already knows which way it wants to go, so let it say. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Read every controller and bound the power-up wait The block hits every Bluetooth radio at once, but the state was read from a bare bluetoothctl show, which reports the default controller only. A powered dongle sitting behind a powered-down internal controller read as off and got blocked along with it. Enumerate the controllers and take any powered one as on, exposed as is-on so callers do not each reinvent the read. The wait counted probes rather than time, so a wedged D-Bus turned a two-second bound into roughly fifty across a full power-up. One deadline around the whole wait holds it near nine. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Change the radio through sudo in the migration /dev/rfkill is only writable unelevated from an active graphical seat, so an update run over SSH failed here with EACCES. Migrations run under bash -e, so that aborted before the config revert and the marker, and aborted again on every retry. The privilege guidance already calls for sudo on machine-wide work run from a visible terminal. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
567e24cd90 |
Hold the indicator peek open while the pointer is on the bar (#6663)
* Hold the indicator peek open while the pointer is on the bar Revealing the hidden indicators widens their section, and a section that grows can slide a neighbouring widget under a pointer that never moved. Collapsing the peek on that un-hover narrowed the section again, moved the neighbour back out, and re-opened the peek, so a pointer resting in the bar space beside a grown section stuttered the bar until it moved away. Hold the peek while the pointer is anywhere on the bar and close it only once the pointer has left, which keeps the reveal-on-empty-space gesture and drops the feedback loop. Fixes #6581 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Assert the whole-bar hover helper does what the peek depends on The earlier assertions all held against a no-op setBarHovered, which would leave barHovered false and let the oscillation straight back in. Pin the assignment and the collapse re-run too, so the helper cannot be emptied without the suite noticing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Let the delayed peek re-check collapse only, never open The timer assigned centerSectionRevealHeld outright, so it opened the peek from bar hover alone. A pointer resting on the left section that dipped off the bar and returned inside 120ms left the timer pending with barHovered true again, and the indicators revealed without the pointer ever touching the center section. Opening stays the center section's own gesture in setCenterSectionHovered. The timer now only closes what that opened, and the test asserts the invariant against the whole file rather than one helper body that never had the offending assignment in it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Tally bar hover per monitor instead of sharing one flag Every screen's bar wrote the same barHovered bool, last writer wins. Sliding along the top edge from one monitor's bar to the next can deliver the enter before the leave, leaving the flag false under a live pointer; the collapse then fired on a peek the user was still hovering, and no further hover change arrived to correct it until the pointer left and came back. Counting each surface's hover makes the order irrelevant. A bar destroyed mid-hover — unplugging a monitor — never sends a leave, so it hands its tally back on destruction rather than holding the peek open for good. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: David Heinemeier Hansson <david@hey.com> |
||
|
David Heinemeier HanssonandClaude Opus 5
|
6d7826d635 |
Give non-login shells the system locale
/etc/profile.d/locale.sh only runs for login shells, so bash started by SSH or herdr's remote bridge ran in the C locale, where printf emits \u/\U escapes literally instead of the character. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
7633d8dee4 |
Keep the bar mapped while hidden so revealing it is instant (#6677)
* Keep the bar mapped while hidden so revealing it is instant Hiding the bar set the panel invisible, which unmaps the layer surface and releases the scene graph with it. Every reveal then had to rebuild all of it: a new layer surface, a configure roundtrip, re-shaped glyphs and re-uploaded textures, and a first frame before anything appeared. Measured on a 2560x1440 screen, showing took 155-175ms against 20ms to hide, and 400-595ms on the first reveal after a cold start. Splitting the cost showed the exclusive-zone reflow was not to blame: show latency was the same on an empty workspace as on a tiled one, and windows finished moving ~15ms after the bar was already on screen. Park the bar one bar-width past its anchored edge instead, and drop its exclusion zone while hidden. The surface stays alive, so showing is only a margin change: 10-14ms in both directions, at every bar position. Since a hidden bar is now mapped, layer_present no longer proves the bar is visible; the session acceptance test asserts on-screen geometry. * Fix layer visibility checks on offset monitors * Handle rotated outputs in layer visibility checks * Cover hidden bar behavior in acceptance tests --------- Co-authored-by: David Heinemeier Hansson <david@hey.com> |
||
|
David Heinemeier Hansson
|
4cc14933a4 | Use sudo for terminal update inhibition | ||
|
David Heinemeier HanssonandClaude Opus 5
|
dc1224c03a |
Stop the sleep lock budget assertion from flaking
A 1500ms budget plus the one 100ms poll interval the trailing sleep can overshoot is exactly 1600ms, which was the bound — but the test measures a whole process around that, so startup pushed real runs to 1602ms. Carry another interval. Two intervals of overshoot, the regression this guards, still trips it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
David Heinemeier HanssonandClaude Opus 5
|
4564c24a0e |
Cover the shared setup form's cancel contract
The form's 0/1/130 statuses gate both the ISO configurator and first-boot setup, and nothing tested them. Stubs gum with scripted per-screen answers and drives each prompt bare under `set -euo pipefail` — the shape that makes the status capture load-bearing, since a cancelled prompt is a failing assignment. A RETURN trap marks that the prompt returned its status rather than the shell dying inside it; both exit identically otherwise, so that marker is what catches a regression to a plain `status=$?`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
6fa4f78ee1 |
Add deferred first-boot provisioning and factory reset (#6621)
* Add OEM first-boot setup and factory reset An OEM-mode ISO install (or omarchy-reset-computer) leaves the machine in OEM state: fully installed, no user, /var/lib/omarchy/oem/pending armed. On the next boot omarchy-oem-setup.service runs the configurator's user form on tty1, creates the user with the groups system setup recorded, finalizes it offline from the stashed Node tarball, re-keys LUKS from the throwaway install passphrase to the user's password, and hands off to SDDM. omarchy-reset-computer returns a machine to that state: it swaps the running root for a fresh clone of the @factory snapshot the ISO takes at install time, scrubs machine identity and prior users, and stages omarchy-factory-wipe to drop the old root and recreate @home/@log on the next boot. Machines installed before @factory existed get a degraded reset (current system kept, users and state wiped) with that caveat surfaced in the confirmation. omarchy-setup-system/-hardware gain --oem to run without an install user; the group-granting install scripts now record their groups in /var/lib/omarchy/oem/groups and only call usermod when the user exists. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Harden OEM setup: correct cryptsetup key-file usage, retry on failure cryptsetup reads --test-passphrase/--key-file inputs byte-for-byte, so feed passphrases through process substitution consistently instead of positional args or stdin (which has different newline semantics). Run each first-boot setup attempt as its own process so a failure offers a retry instead of stranding the machine at a user-less login screen — bash ignores errexit inside `while !` conditions, a child process does not. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Always grant wheel sudo in OEM first-boot setup Detecting an existing %wheel grant by grepping sudoers is error-prone: omarchy ships narrow '%wheel ALL=(ALL) NOPASSWD: <command>' rules (e.g. asdcontrol) that match the naive pattern, which left the OEM-created user matching sudoers entries but unable to run anything. Write the drop-in unconditionally — a duplicate of an existing full grant is harmless. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Fix LUKS re-key device resolution and OEM state readability archinstall's encrypted installs put cryptdevice=PARTUUID=... on the kernel cmdline, not UUID=, so the first-boot re-key never found its device and silently skipped — leaving the throwaway auto-unlock keyfile in place, i.e. the disk effectively unencrypted. Parse every cryptdevice= source spec form and make any re-key failure abort the attempt loudly: a retry prompt beats a machine that quietly boots without a passphrase forever. The OEM state directory also has to be world-readable (its one secret, luks-key, stays 0600): user finalization reads the stashed Node tarball as the new user, and the 0700 directory forced it onto the network fallback. Step markers now land in /var/log/omarchy-oem-setup.log for debuggability. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Purge stale machine-id boot entries when resetting or re-keying limine-entry-tool keys its limine.conf OS entries by machine-id. A factory reset gives the machine a fresh identity, so the previous system's entry survived every rebuild, sorted first, and made Limine stop at a Blake2b hash-mismatch warning once the UKI was rebuilt. Start limine.conf over from the shipped template (and drop foreign machine-id history directories on the ESP) before any post-reset rebuild: in the staged chroot rebuild, in the first-boot LUKS re-key, and — for unencrypted resets, where nothing else rebuilds — in a dedicated first-boot refresh when foreign entries are found. The staged rebuild also verifies every UKI hash referenced by limine.conf against the file on the ESP before the subvolume swap, and the running system's limine-snapper-sync is runtime-masked during staging so it cannot rewrite the config behind the rebuild. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Harden reset and first-boot setup failure paths Review findings from codex and Copilot: - Generate throwaway passphrases without a trailing head stage: under pipefail, SIGPIPE from the infinite tr failed the substitution and errexit aborted every encrypted reset before it could stage anything. - Stage the fallible parts of a degraded reset (LUKS re-key, boot rebuild) before arming the wipe, so a staging failure leaves the machine untouched instead of scheduling a wipe for a reset that never finished. - Gate first-boot setup on the factory wipe having succeeded (ConditionPathExists=!wipe-pending plus an in-script guard): creating the new user on a half-wiped system would hand their data to the wipe retry. - Abort the wipe (keeping its retry marker) when deleting the old root or recreating @home/@log fails, and abort resets that cannot remove a prior account — a surviving account keeps its password and wheel membership. - Resume a partially-created account on setup retry instead of rejecting the username the failed attempt just created. - Only purge machine-id directories the old limine.conf actually referenced; a shared ESP may hold other installations' boot artifacts. - Recreate the hibernation swapfile (nested subvolume, so never captured by the factory snapshot) inside the factory root before its UKI rebuild, so a reset machine keeps disk-backed swap and a valid resume offset. - Source base-test.sh in the OEM groups test per test conventions. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Recreate the hibernation swapfile even when resume drop-ins survive omarchy-hibernation-setup short-circuits as 'already set up' when the resume mkinitcpio drop-in exists — which it always does in a factory root, while the swapfile itself never survives the snapshot (nested subvolume). Drop the marker when the swapfile is gone so setup reconfigures from scratch, and verify the swapfile actually exists before proceeding with the reset. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Second review pass: encrypted-config coverage, factory-baseline sanitization, recoverable rekey Codex xhigh round 2: - Detect the LUKS backing device by walking the root's device tree, not only the cmdline cryptdevice=; reset/first-boot now re-key roots reached via rd.luks/crypttab too, instead of silently leaving the seller's slots valid. - Sanitize the retained @factory baseline (accounts, /etc/shadow, machine identity) during a full reset: the new wheel user could otherwise mount it to recover the seller's data, and a second reset would restore the account. - Re-key the disk recoverably: rebuild the no-auto-unlock UKI before killing the throwaway slot or destroying the staged key, and restore the keyfile if that rebuild fails, so a retry with a different password can never leave the disk locked to the first attempt's password. - Roll back a degraded reset's live-root auto-unlock material if its boot rebuild fails, instead of leaving it for a later rebuild to embed. - Treat a missing current-machine limine entry as stale so a retry after a failed rebuild repairs the config instead of clearing OEM state over it. - Erase fingerprint enrollments (/var/lib/fprint) in degraded wipes. - Remove the resume-offset drop-in too when recreating the factory swapfile, so the rebuilt UKI gets a correct offset. - Pin first-boot retries to the account the first attempt created. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Expose factory reset in the Setup menu Add a 'Reset Computer' entry under Setup (Omarchy's Settings menu, where OS factory resets conventionally live), guarded to btrfs roots and launched in a floating terminal. omarchy-reset-computer now self-elevates via sudo so the menu entry needs no sudo prefix, forwarding the caller's gum theme env as env arguments so styling survives an env_reset sudoers. The typed 'reset' confirmation and the sudo password prompt remain as the guards against accidental triggering. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Defer keyboard selection to first boot for OEM installs The OEM first-boot setup now runs a keyboard step before the user form, mirroring the ISO configurator: it loads the chosen layout on the live VT so the password (and the LUKS re-key that follows) are typed under it, and persists it with systemd-firstboot so the installed system gets both the console KEYMAP and the XKB layout Hyprland reads — exactly what a normal install writes. Layouts localectl doesn't know keep the default, same as the installer. This lets the OEM operator set nothing user-specific: the machine's owner picks their keyboard alongside their account at first boot. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Rename factory-reset commands to omarchy-system-factory-reset[-finish] omarchy-reset-computer -> omarchy-system-factory-reset omarchy-factory-wipe -> omarchy-system-factory-reset-finish (and its systemd unit, log path, and temp mount to match) Pure rename: every reference — the Setup menu action, the first-boot finish service the reset stages and enables, the oem-setup ordering/gating, comments, and the menu test — moves together, with no behavior change. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Rename OEM vocabulary to provisioning (runtime) Commands unify under the provisioning family: omarchy-oem-setup → omarchy-provision-owner omarchy-finalize-user → omarchy-provision-user omarchy-first-run → omarchy-provision-first-run And the deferred-provisioning state/vocabulary replaces 'OEM': /var/lib/omarchy/oem/ → /var/lib/omarchy/provisioning/ /etc/omarchy/oem.key → /etc/omarchy/provisioning.key install/oem/ → install/provisioning/ OMARCHY_SETUP_CONTEXT=oem-firstboot → provision-owner omarchy-setup-system/-hardware --oem → --defer-provisioning All callers (provision-first-run→provision-user, autostart, factory-reset staging the provisioning units, the group-recording scripts) and comments move together. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Drop remaining OEM mentions from the provisioning groups test Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Finish the omarchy-first-run rename in the docs Two doc references to omarchy-first-run were missed when the script was renamed to omarchy-provision-first-run; update them to match. Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
e1d0c4e0a8 |
Ship the keyboard layout widget on the bar and make clicking it work (#6659)
* Hide the keyboard layout widget on a single-layout install There is nothing to read or switch when only one layout is configured, so the label is noise on the bar most people have. Hide it until the keyboard reports more than one, and keep showing it on a Hyprland that doesn't report the list at all rather than hiding the widget everywhere. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Put the keyboard layout widget on the bar by default The widget hides itself unless the active keyboard has more than one layout, so shipping it costs a single-layout machine nothing and saves everyone else from finding it in the plugin list. Sit it just right of the clock, and add it to existing bars the way the agents widget was added, leaving a curated bar and a disabled widget alone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Cycle the layout with the hyprctl command that exists switchxkblayout is a hyprctl command, not a dispatcher, so sending it over the dispatch socket only produced a Lua syntax error and clicking the widget did nothing. Run it instead, against the keyboard the label was read from. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Add an idempotent bar add command Nothing put a widget on the bar without going through the running shell: plugin enable and bar move both forward to it over IPC, which a migration cannot rely on. Add writes the config file the way position and transparent already do, and leaves a widget that is already on the bar where the user put it, so callers can ask for it repeatedly. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Put the keyboard layout widget on bars through the bar CLI The hand-written jq was a normalizer, a presence check and a splice for what is now one command that carries all three. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Keep bar add from writing a bar the shell was not reading The shell takes a user shell.json only when it parses, says version 1, and carries a bar layout, and does not deep-merge; anything else leaves the shipped defaults on screen. Reading and writing the user file regardless turned a config holding nothing but an idle timeout into a bar holding nothing but the new widget, and made an unparsable one abort the migration chain on every update. Work against whichever layout is actually in effect, seeding the defaults before placing a widget they do not already carry. A malformed hand-installed manifest fails the whole plugin catalog, which was enough to refuse a first-party widget, so treat an unreadable catalog as no answer rather than a no. Leave a widget listed in disabledPlugins off the bar instead of writing a layout entry the registry refuses to load, and re-check presence inside the mutation so two adds cannot both miss it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Read a widget's default bar section in one place cmd_defaults spelled out the same "defaultSection, or center when it is missing or not a section" rule that the add path already asks for by name. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Rename bar add to bar put 'omarchy plugin add' installs a plugin and 'omarchy bar add' placed one that was already installed, which is too much meaning for one verb. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Place a newly added bar widget with bar put plugin add reached the bar through plugin enable, which forwards to the running shell, so it first had to poll until the shell noticed the clone and then failed outright when no shell was there to ask. Putting a widget on the bar is a config edit, so do that directly and leave plugin enable to the plugins that need registering rather than placing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Put bar widgets through the shell instead of the config file Placing a widget existed twice: once in PluginRegistry, which the shell uses and owns the config it holds in memory, and once as jq against shell.json. The second was there so migrations could run without a shell, which they do not need to: the Quattro upgrade hands over the shipped shell.json before it runs any, and every other path runs inside a session with a shell up. Ask the shell, and say so and carry on when there is none to ask. putBarWidget enables only what is not already on the bar, which is what a caller that cannot know whether it ran before needs, and is the one thing the existing enable path would not do. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
6ddc39520d |
Clean up the terminal and reconnect when SSH connections drop (#6661)
* Clean up the terminal and reconnect when SSH connections drop A remote tmux, herdr, or editor arms terminal modes over the SSH pipe (mouse tracking, focus reporting, the alternate screen) that only it can disarm. When the connection dies instead of exiting cleanly, those modes stay armed on the local terminal, and every mouse move floods the prompt with escape-sequence junk. Wrap ssh in a shell function that disarms those modes after every exit, and automatically reconnects when an established interactive session drops. Remote commands, configured RemoteCommands, and redirected stdin never reconnect, so their side effects cannot replay, and the retry loop runs in a subshell so Ctrl-C cancels both the in-flight attempt and the loop. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Detect dead SSH connections within a minute Without keepalives, ssh does not notice a dead peer until TCP gives up, which can take hours of sitting on a hung terminal with remote-armed terminal modes stuck on. Ship a client keepalive default so drops are detected in about 45 seconds, letting the shell's ssh wrapper clean up and reconnect. ~/.ssh/config is read first and wins, so per-host overrides still apply. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Fail closed when ssh -G cannot resolve the effective config An unresolvable configuration could hide a RemoteCommand, so treat it as non-interactive rather than reconnectable. Also strengthen the tests from Copilot review: assert the complete disarm sequence, and verify on a real interactive pty that Ctrl-C during a retry attempt kills the reconnect loop itself, not just the in-flight attempt. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Tolerate the explicit RemoteCommand none when probing ssh -G The literal "none" is how ssh_config cancels a configured RemoteCommand, and some OpenSSH versions emit it even when unset, which would have silently disabled reconnecting entirely. Treat it as no remote command while still failing closed on real ones and unresolvable configs, and make the fake ssh -G emit the "none" form so the behavior tests cover it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
c4dda58ba2 |
Stop the clipboard picker freezing on huge pastes (#6568)
Every keystroke in the search box scanned, lowercased, and split the full text of every history entry, and the preview pane laid out the entire selection with WrapAnywhere. A single 1.6MB paste (or a large file selection) turned that into hundreds of megabytes of work on the shell thread and stalled the render thread — freezing the whole desktop. Cap each entry once as it enters the display, so searching, previewing, and rendering all work on a bounded prefix. Pasting reads the full entry back from history by index, so nothing is actually lost. The cut lands on a line break, keeping a file:// URI from truncating into a bogus path. Co-authored-by: markbusking <marcosbustos.dev@gmail.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
dd61d4a75b |
Ship herdr alongside tmux (#6406)
* Ship herdr with a config that mirrors our tmux setup Installs herdr through the mise shim, ships the matching config as an Omarchy default, and adds the usual refresh/restart pair. The keybindings map tmux sessions to workspaces, windows to tabs, and keep both the prefix and direct bindings from config/tmux/tmux.conf. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Add herdr versions of the tmux dev layout functions hdl, hds, hdlm, and hsl drive herdr through its socket API instead of tmux. hsl tiles into a real grid since herdr has no select-layout tiled. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Namespace the herdr layout helpers so they stay out of the shell Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Create hdlm's tabs in its own workspace instead of the focused one herdr tab create follows the focused workspace without --workspace, so switching workspaces while hdlm loops scatters the new tabs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Lay hsl's grid out in visual order Splitting the first column repeatedly inserted each new column between it and the previous one, so uneven counts put the spare row in a middle column instead of the last. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Report herdr config reload failures instead of swallowing them Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Hide herdr's pane scrollbars to match tmux Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Escape queued herdr layout commands * Install herdr from the omarchy-herdr package instead of mise * Use native herdr resize keybindings for tmux-style pane resizing * Rename the omarchy-herdr package to herdr --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
David Heinemeier HanssonandClaude Opus 5
|
19572a13c7 |
Skip compositor tests without recording a failure
Two problems made a missing Wayland compositor look like broken tests. The cleanup traps ended on a bare conditional, so when a test skipped before creating its TMPDIR the trap's last command returned 1 and, under set -e, that overrode the explicit exit 0. Six tests that launch quickshell had no compositor guard at all, so they ran anyway and failed on the Qt platform plugin. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
2a0c7371a5 |
Claude collector: attribute pi usage by provider, not api prefix (#6655)
Pi/omp sessions kept falling into the Claude record when the api field merely started with 'anthropic'. Kimi and other providers that speak the anthropic-messages protocol (kimi-coding) were therefore charged against Claude Code, showing k3 buckets under a Claude tab even for a user without a Claude login. Match the codex collector's provider-only attribution: only sessions whose provider is exactly 'anthropic' count toward Claude usage. Add a test proving a kimi-coding session sharing the anthropic-messages api does not land in the Claude record. Co-authored-by: Luca <luca@itwasarch> |
||
|
David Heinemeier HanssonandClaude Opus 5
|
8be0ca9d43 |
Expect Tailscale on the right in the bar defaults test
|
||
|
|
e4d85bd037 |
Keep concurrent usage collectors off one shared temp file (#6654)
Two Claude collectors running at once both wrote the cache through a temp path derived from the target, so the second replace found the file already moved away and crashed the update with a FileNotFoundError. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
1ded25fd45 |
Make a dead lock client diagnosable and recoverable (#6630)
* Persist the Omarchy shell log across sessions Quickshell only logs to its instance runtime dir on tmpfs, so when the shell dies the idle/lock event trail is gone after a reboot (#6628). Launch the shell through omarchy-launch-shell, which pipes stdout/stderr into the journal under the omarchy-shell tag — bounded, timestamped, and persistent — and surface that log in omarchy-debug-idle. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Recover a locked session whose lock client died When the shell dies while the session is locked, Hyprland's failsafe keeps the session locked with no lock client left, and omarchy-restart-shell refused to run in exactly that state, leaving reboot as the only way back in (#6628). Gate the refusal on the lock service actually holding (or acquiring) the lock rather than on the session's LOCK state — a dead shell and a crash-handler relaunch that holds no lock both fail that check — then restart the shell, re-acquire the session lock, and wait for it to report secure, the same secure-poll omarchy-system-sleep-lock uses, so the user can authenticate out of the failsafe. Enable Hyprland's allow_session_lock_restore so the compositor accepts the replacement lock client. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
5a58f79876 |
Keep clicking a notification working after a shell restart (#6636)
* Keep clicking a notification working after a shell restart Notification actions lived only in the sending process: `-a` appended `-A default=default`, so notify-send blocked on a D-Bus ActionInvoked signal and the caller ran the command when it arrived. Nothing about that reached disk, so a restored popup had no action to run and its sender stayed blocked forever. Replace `-a` with `--exec <command>`, carried as an `omarchy-exec` hint into the snapshot's `exec` role. It travels through the popup files and history, and the shell runs it on click, so restored toasts behave exactly like live ones and the sender exits immediately. That drops the scaffolding whose only job was keeping a blocked sender alive: the first-run invitations lose their `--show` re-entry and two transient units each, omarchy-migrate-notify loses its transient service, and the screenshot, recording, download, and taildrop toasts lose their wrapper subshells. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Keep a failed toast from failing the work it announces Moving these sends out of their backgrounded subshells put a fallible command on the foreground path, where the `&` used to swallow its exit status. A notification outage — including the shell restart this branch targets — now propagates: - taildrop's receiver dies under `set -e` mid-delivery - omarchy-capture-screenshot reports failure for a screenshot it already saved - a completed download exits before scheduling its thumbnail cleanup, leaking the mktemp file Announcing is best-effort in all three: the work is already done by the time the toast goes out. Also drop the first-run sleep that spaced out the welcome and Wi-Fi toasts. It compensated for the background notify-send processes this branch removes; each send now returns only once the server has taken the toast, so sending in order is enough to stack them newest-on-top. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Stop tying the preview cleanup to the toast's expiry The shell loads a notification thumbnail into memory when the toast appears and never re-reads the file, so the preview only has to outlive that load. Deriving the cleanup delay from the expiry was false precision, and it turned -t into a variable for no reason: -t is already the helper's expiry setting. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
b925431025 |
Give SSH commands the user-level tool paths (#6632)
* Give SSH commands the user-level tool paths
ssh host cmd runs neither a login nor an interactive shell, so on Arch it
gets the bare sshd PATH and can't find mise-managed tools like the agent
CLIs herdr scans for. Set PATH in the PAM environment (per-user via
@{HOME}), append the user-level dirs in env-bootstrap so login shells and
the uwsm session get them too, and source env-bootstrap before bashrc's
interactive guard for bash variants that read it non-interactively.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Don't let an empty PATH turn into a cwd entry
Appending with a bare "$PATH:" prefix leaves a leading colon when PATH
is unset, which shells treat as the current directory.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
|
||
|
David Heinemeier HanssonandClaude Opus 5
|
0f1e0ced36 |
Remove the omarchy-update-perform compatibility wrapper
Nothing calls it anymore; new code calls omarchy-update directly. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
318bf2c43a |
Keep the Quattro upgrade from aborting silently into an unsafe state (#6617)
The script is fetched from the branch but calls into the installed /usr/share/omarchy tree, which can lag it. A packaged build without bin/omarchy-done aborted apply_user_transition under set -e two thirds of the way through: NetworkManager was already enabled, iwd was not yet disabled, and nothing was printed, so the run read as finished. The completion markers are now written directly instead of through omarchy-done, and the two remaining unguarded packaged commands warn rather than abort. Retiring iwd moves up next to the NetworkManager enable it depends on, so no failure in between can leave both enabled. An aborted run now says so instead of returning to the prompt on a green progress line. Fixes #6575 Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
2b9e2720b3 |
Run every test file instead of stopping at the first failure (#6622)
test/shell and test/all inherit `set -euo pipefail`, so the first failing test file aborts the whole run. One failure then hides every file behind it: you fix it, rerun, discover the next one, and repeat a file at a time. On a 140-file suite a single unrelated failure can keep most of the suite from ever reporting. Keep going after a failing file, then list the files that failed and exit non-zero. Individual files still stop at their own first failed assertion, so per-file isolation is unchanged, and a clean run still exits 0. The files are already independent of each other -- the set of failures is the same whether the run continues or stops at the first one -- so nothing was relying on the early abort. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
007d6fcd7d |
Use the gmux backlight instead of the Touch Bar on T2 Macs (#6597)
* Match display backlight candidates against real globs [[ ]] does not do pathname expansion, so amdgpu_bl* and acpi_video* only ever tested for files with a literal asterisk in the name. Every machine without intel_backlight silently fell through to the alphabetical first entry, which picks acpi_video0 over amdgpu_bl0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Use the gmux backlight instead of the Touch Bar on T2 Macs /sys/class/backlight on a T2 Mac holds appletb_backlight and gmux_backlight. Neither was a candidate, so the alphabetical fallback picked the Touch Bar and brightness keys dimmed it instead of the display. Add gmux_backlight and never fall back to the Touch Bar, which is not a display panel on any Mac. gmux ranks above the GPU backlights because apple-gmux only registers its device when the kernel has already selected it for the machine, and on dual-GPU Macs the GPU's own PWM stops driving the panel as soon as that GPU suspends. Fixes #6558 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
0b24b844df |
Scope BROWSER to interactive shells so xdg-settings can change the default browser (#6616)
Exporting BROWSER=omarchy-launch-browser into the whole uwsm session made xdg-settings refuse "set default-web-browser", which broke every browser's own "Set as default" button. The export only exists for terminal programs (like gh) to open URLs detached from the terminal process tree, so move it to default/bash/envs where interactive shells still pick it up. Fixes #6590 Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
f76d058a6d |
Force a database refresh before installing keyrings during the Quattro upgrade (#6615)
The upgrade repoints the mirrorlist and the [omarchy] server, then ran pacman -Sy. A plain -Sy keeps the legacy database whenever the new server's copy isn't newer, so the checksums stay stale and every re-download of a rebuilt package aborts as corrupted. Fixes #6576 Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
77cf58ccfe |
Add Fireworks balance usage panel (#6488)
* Add a Fireworks balance collector and teach the agents panel prepaid ledgers The omarchy-agent-usage-fireworks collector reads serverless token usage from the Fireworks billing API, grouped by day and model for the last 30 days, and reshapes it into the shared record contract. Fireworks does not expose its prepaid ledger through the documented API, so the record carries an estimated balance instead of rate limits: credits configured in ~/.config/omarchy/agents/fireworks.json minus rated account costs since the funding date. Credentials come from FIREWORKS_API_KEY/FIREWORKS_ACCOUNT_ID, the auth.ini that firectl set-api-key writes, or — last, so an explicit login wins — the key opencode stores for its fireworks-ai provider. The panel gains two generic capabilities any agent record can use: a balance object draws a BALANCE section — remaining credit, a fuel-gauge meter that drains toward empty and lights the bar alarm below 10%, and funded-versus-spent detail — and hasPromptStats: false keeps prompt and session counts out of today's tooltip for agents whose billing API only ever reports tokens, on this machine and through synced snapshots. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Feed Claude and Codex usage from pi, omp, and opencode sessions A subscription burned entirely through another coding agent leaves no native Claude Code transcripts and no Codex session files, so the panel showed nothing for it. pi and omp write compatible JSONL sessions, and opencode records per-message provider, model, and token usage in its message database; the claude and codex collectors now scan all three — filtered to Anthropic and OpenAI providers respectively — and merge those numbers into their local stats. Fireworks stays out on purpose: its billing API already sees that traffic server-side, and a local scan would count the same tokens twice. The collector tests pin XDG_DATA_HOME so a developer's real opencode history cannot leak into fixture runs. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
b85ae70ebd |
Stop pipefail from turning grep -q SIGPIPE exits into false negatives (#6614)
* Stop pipefail from turning grep -q SIGPIPE exits into false negatives grep -q exits at the first match, and when the producer is still writing it dies with SIGPIPE. Under pipefail that 141 becomes the pipeline's status, so hardware checks like lspci | grep -q read as "not found" on exactly the machines they target. The T2 defaults migration hit this and silently skipped real T2 Macs (#6608). Redirect grep to /dev/null instead of -q wherever a pipeline feeds grep in a pipefail context, so grep reads all input and the producer never gets killed. The install-time T2 checks aren't run under pipefail today but are switched too, since they're the same detection line the issue calls out. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Re-run the T2 defaults migration its broken hardware check skipped The SIGPIPE bug marked 1785944594 as applied without doing anything on affected T2 Macs. The original migration is idempotent, so a fresh migration can just source it now that the guard is fixed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Address Copilot review: fix OCR grep pipeline and prove the T2 repair screen_contains piped tesseract into grep -Fqi under the acceptance suite's pipefail, the same SIGPIPE false negative the rest of the branch fixes. The T2 test's lspci stub now keeps writing past the pipe buffer after the match so every scenario exercises the SIGPIPE case, and a new case runs the rerun migration against fixtures a bitten install would have. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
667d2d2f31 |
Open panel hotkeys on the focused monitor (#6613)
A bar surface is built per monitor, so panel routing had several live copies of the same widget to choose from and took whichever registered its slot first. Pick the one on the monitor Hyprland has focused instead, preferring an already-open copy so hide and toggle still reach the visible panel. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
3bfea9b840 |
Fail loudly when a pre-update snapshot isn't actually created (#6580)
* Fail the snapshot when Snapper is installed but has no configs omarchy-snapshot create loops over the configs snapper reports. With none, the loop body never runs, so it prints "Create system snapshot" and exits 0 without capturing anything. Every update then reports a snapshot it never took, and the absence only surfaces when a rollback is needed and the snapshot list turns out to be empty. * Say so when the update proceeds without a snapshot The update ignores exit 127 so a system without snapper updates quietly. Any other snapshot failure was being swallowed by the same expression, which let the update continue with no indication that it was now unprotected. Keep continuing, but say it out loud. * Point the snapshot repair hint at how the installer runs it Also hold the green header until a snapshot will actually be attempted, so the no-config failure doesn't open with a success banner. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Continue the quattro upgrade when the pre-upgrade snapshot fails The upgrade runs under set -e, so the new non-zero exit from an unconfigured Snapper would have aborted a re-run at the snapshot step instead of proceeding like omarchy-update does. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: David Heinemeier Hansson <david@hey.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
9d5c6e25e7 |
Keep root= in the kernel cmdline when upgrading to Quattro (#6579)
* Keep root= in the kernel cmdline when upgrading to Quattro The packaged drop-in /etc/limine-entry-tool.d/omarchy-defaults.conf sets KERNEL_CMDLINE[default] with the += operator. limine-entry-tool.conf documents what that costs: "+= appends parameters to an existing cmdline ... Ignores /etc/kernel/cmdline and /proc/cmdline". As soon as the drop-in lands, the tool stops auto-detecting the cmdline. Fresh installs are unaffected, because the ISO writes /etc/default/limine from default/limine/default.conf with @@CMDLINE@@ substituted. The upgrade path never created that file. A pre-quattro install that relied on the auto-detected root= therefore ends up with a cmdline that has no root= at all, in both limine.conf entries and in the cmdline embedded in the UKIs. The next boot fails with "ERROR: Failed to mount '' on real root" and drops to an emergency shell, where the error gives no hint that the cmdline is the cause. Capture the boot-critical parameters from /proc/cmdline before the reboot, while the still-correct cmdline of the running kernel is readable, and write them to /etc/default/limine, which is loaded last so += keeps the drop-in parameters instead of replacing them. Copy root=, rootflags, rootfstype, resume, resume_offset, the cryptdevice and rd.luks keys and rw/ro verbatim rather than reconstructing them, so LUKS and hibernation setups survive too. Re-running the upgrade on an already-broken system has no root= left to copy, so fall back to deriving it from the mounted root, including the subvolume on btrfs. Any config layer that already pins root= is treated as authoritative and left untouched. * Anchor the cmdline guard and harden the repair path The early-return guard searched for the bare string root=, which matches the commented example limine-entry-tool.conf ships at line 53: #KERNEL_CMDLINE[default]+=rw root=UUID=... That file is present on every stock machine, so the guard always fired and the function never wrote anything. Match assignments instead, and check /etc/kernel/cmdline separately since it holds bare parameters rather than shell assignments. Three fixes on the repair path: Assigning boot_params discarded every parameter the collection loop had just captured, so cryptdevice, cryptkey, resume and ro were dropped, and rw was forced over a captured ro. Prepend the derived root= instead, and only add rw when the booted cmdline stated no mount mode. On an encrypted root, findmnt reports the unlocked mapper device, whose UUID says nothing about which container to unlock. Emitting it produced a cmdline that still could not boot while satisfying the final check, so the user rebooted into the same emergency shell believing it was repaired. Warn and write nothing in that case. The allowlist gained rd.luks.key, rd.luks.crypttab, rd.md.uuid, rd.dm.uuid, rootwait, rootdelay and dm-mod.create. Verification now also reads the .cmdline section of each UKI. With omarchy-uki.conf among the drop-ins that embedded copy is what actually boots, so a green limine.conf alone did not prove the machine would come up. * Filter guard paths and narrow the dm-crypt and UKI checks The guard passed /etc/default/limine to grep unconditionally, and that file is absent on exactly the machines this targets. A missing operand makes grep exit 2 without -q, so a drop-in pinning a real root= went undetected and the function appended a second one, overriding the explicit setup it promises to leave alone. Rather than relying on -q returning 0 despite the error, which is a GNU grep special case and not true of every implementation, filter the paths first and only grep the ones that exist. The exit status is then unambiguous. The dm-crypt check gated on the /dev/mapper/* prefix, which also matches plain LVM, dm-raid and multipath. Those roots need no unlock parameters and were repairable before, so the prefix test denied them a working root=UUID= and told them they were encrypted. Gate on the device mapper target type instead. root_filesystem_encrypted() is not reused here on purpose: it treats every /dev/mapper/* path and any non-empty /etc/crypttab as an encrypted root, which suits its own call site but would reintroduce the same false positive. UKI verification now runs through as_root, since a restrictive ESP fmask would otherwise make find return nothing and the check pass in silence, and is scoped to the omarchy_linux*.efi images limine-entry-tool generates so a shared ESP or a stub without a .cmdline section cannot raise a false "do not reboot" warning. The allowlist gained rd.lvm.lv and rd.lvm.vg. * Strip the subvolume before resolving the root device type findmnt appends the subvolume for btrfs mounts, so the source read back for an encrypted btrfs root is /dev/mapper/cryptroot[/@]. lsblk cannot resolve that path, the device type came back empty, and the crypt gate never fired. The function then wrote root=UUID= with no unlock parameters, limine.conf ended up carrying a root= so the final check stayed quiet, and the machine still booted to an emergency shell. That is the layout Omarchy installs when encryption is picked, so the gate missed exactly the roots it exists for. The previous /dev/mapper/* prefix test matched the bracketed form by accident. Moving to the device mapper target type is still the right call, it just needs the unbracketed source, which findmnt --nofsroot provides. Also give root_type an explicit empty default. It is assigned inside a branch and read outside it, and set -u treats a declared-but-unassigned local as unbound, so a findmnt that cannot answer would abort the upgrade with the quattro packages already installed and everything from configure_snapper_policy onward skipped. * Look for the crypt layer across the whole device stack lsblk -no TYPE reports only the target's own type. On the standard full-disk encryption layout, LUKS container -> LVM PV -> root LV, that type is lvm and the crypt layer sits in the parents, so the gate never fired: the function wrote root=UUID= with no unlock parameters, the final check found a root= and stayed quiet, and the machine still booted to an emergency shell. Walk the parents with lsblk -s and look for a crypt layer anywhere in the chain. That keeps LVM, dm-raid and multipath roots on the repair path, since they carry no crypt layer and root=UUID= is enough once mkinitcpio assembles them. root_type is replaced by root_stacks_crypt, which says what is actually being tested and drops the LVM-versus-crypt caveat the old target-type check needed. Also drop a vacuous test assertion: piping a bracketed literal through grep -qv '\[' selects nothing, so the branch was unreachable and the case passed whatever the script did. The --nofsroot assertion above it is what holds that fix. * Keep the crypt gate off a pipeline exit status Capture the device stack and match it from a here-string rather than piping lsblk into grep -q. Under pipefail a short-circuiting grep can leave the producer with SIGPIPE and turn the pipeline into 141, which reads as "no crypt layer" and disarms the gate silently. lsblk writes its whole table in one go, so this is out of reach in practice, but nothing about the gate should depend on how much output a helper happens to buffer. Also correct a stale test comment that described the target-type check the previous revision used, four lines above the comment explaining why that check was insufficient. * Harden the kernel cmdline preservation against false root= pins The /etc/kernel/cmdline early return trusted a file limine-entry-tool ignores once a += drop-in sets KERNEL_CMDLINE[default], leaving exactly the targeted machines unbootable. The pin guard now reads only the *.conf layers the tool loads, only the default key, and tokenizes the assignment value so quoted decoys and volatile-root= cannot pin. /proc/cmdline is tokenized quote-aware so dm-mod.create="..." survives verbatim, the root= verification is token-anchored, and an unverified cmdline now blocks the reboot instead of only warning. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Ask limine-entry-tool for the effective cmdline instead of parsing its configs --get-cmdline default answers whether root= survives the tool's own config merge, replacing the glob, grep and quote-aware tokenizer walk over the config layers, and the quote-aware /proc/cmdline parsing reverts to plain word splitting. The verification and the reboot gate stay: they are what catches anything the simpler paths miss. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: David Heinemeier Hansson <david@hey.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
96bbe53634 |
Fix panel delegate segfault and the network panel's open stall (#6605)
* fix(network): drop the redundant rescan on the bar click Opening from the bar ran open() and then a bare refresh(). open() already triggers onOpenedChanged -> refresh(true), which defers the PHY scan by disabling the scanner and re-enabling it from scanRestart. The bare refresh() that followed defaults scanWifi to false, so it took the other branch and set wifiDevice.scannerEnabled synchronously on the click frame, undoing the deferral and stalling the open on NetworkManager's access-point flood. It also double-started the DNS and band probes. Co-Authored-By: shrijit <shrijitsrivastav@gmail.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(network): keep wifi rows QObject-free to prevent a delegate crash wifiRow() embedded the WifiNetwork QObject in the row it returns, and those rows are list-model data, so every delegate held a live QObject wrapper in a var property. When NetworkManager churns the list -- a scan's access-point flood, an AP disappearing -- the object can be destroyed while a delegate is still incubating, and quickshell segfaults in QObjectWrapper::wrap_slowPath on the dangling wrapper. Project primitives only and resolve the backend object at action time via the existing networkForSsid(). Both failNetworkAction() and checkActionCompletion() already no-op on a null network, so a row whose network has since vanished is handled the same way it was before. Co-Authored-By: shrijit <shrijitsrivastav@gmail.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(bluetooth): keep device rows QObject-free to prevent a delegate crash Same crash class as the wifi rows: scrollRows embedded the BlueZ Device QObject in list-model data, so every delegate held a live wrapper in a var property. Discovery churn -- a scan timeout dropping a device, an unpair -- can destroy the object while a delegate is still incubating, and quickshell segfaults on the dangling wrapper. Project primitives for both the scroll rows and the connected rows, and resolve the backend object by address in deviceFor() for the click actions. The keyboard flow already went through deviceAt(), which reads the live device arrays directly rather than model data, so it is untouched. Co-Authored-By: shrijit <shrijitsrivastav@gmail.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(network): guard row disconnects against a vanished network Row activation resolved the WifiNetwork with networkForSsid() and passed the result straight to disconnect(), which falls back to connectedWifiNetwork when handed null. A row is a primitive snapshot, so scan churn can remove its backing object while the row is still on screen -- activating it then tore down whatever happened to be connected at that moment rather than doing nothing. Route both row paths through disconnectRow(), which resolves first and only acts when the row still maps to a live network. disconnect() keeps its fallback for callers that mean "drop the current connection". Also covers the bar-click open path, which had no regression: the suite already asserts against Panel.qml source, so assert the closed branch calls open() alone and never a second refresh(). Co-Authored-By: shrijit <shrijitsrivastav@gmail.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: shrijit <shrijitsrivastav@gmail.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
f490b69a20 |
Reopen the wifi passphrase prompt after a wrong saved password (#6584)
* fix: reopen wifi passphrase prompt after a wrong saved password A failed first connection attempt leaves the network profile saved, so the network shows up as known. Clicking it again reconnects with the stored wrong PSK and fails with WifiAuthTimeout, but the inline passphrase prompt only reopened on NoSecrets, leaving no way to re-enter the password short of forgetting the network. Treat an auth timeout on a protected network as a wrong saved passphrase and reopen the prompt; connectWithPsk overwrites the stored PSK on submit. Fixes #6582 * Scope the wifi passphrase reprompt to panel-initiated connects Background auto-connect retries also fire connectionFailed; without a gate they would pop the passphrase prompt open unbidden, stealing focus and wiping a passphrase mid-entry when another network fails. For the gate to see the failure, the action safety-net timer must outlast NetworkManager's 25s supplicant timeout -- at 15s it cleared the action state before WifiAuthTimeout arrived, so a wrong saved password showed "Timed out connecting" instead of "Wrong password". Bump it to 30s. Also share the one ConnectionFailReason map between the Model.js helpers instead of building a second partial copy inline. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: David Heinemeier Hansson <david@hey.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
David Heinemeier HanssonandClaude Fable 5
|
d2b090f8fc |
Isolate XDG dirs in shell tests that launch quickshell with a fake HOME
Faking HOME alone was never enough: the shell QML and the agent usage updater read XDG_STATE_HOME and XDG_CACHE_HOME directly, so a test quickshell inherited the session's real paths. The bar widget contract test instantiated the agents widget, whose refresh ran the real collectors against the empty fake HOME and wrote hollow "Waiting for auth" records into the developer's real usage data files — hiding the agents widget from their bar — while littering the real cache with per-tmpdir scan files. Point XDG_CONFIG_HOME, XDG_CACHE_HOME, and XDG_STATE_HOME under the fake home in every test that boots quickshell with one. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
bb8d2f2cb3 |
Split agent usage into data files and rename the plugin to omarchy.agents (#6603)
* 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
|
||
|
|
48d77b5738 |
Persist on-screen notification popups across shell restarts (#6600)
* Persist on-screen notification popups across shell restarts Mirror every popup to its own file under ~/.local/state/omarchy/notifications/ for exactly as long as it is on screen: written when the toast appears, deleted when it expires, is dismissed, is acted upon, or is replaced via freedesktop replaces_id. On startup the directory is read back and still-valid popups re-shown, so toasts survive the restart omarchy-update performs — critical alerts, which never expire, always make it across. Restored popups keep ids from the previous server generation, so the replaces_id cleanup tracks them separately instead of mistaking a fresh notification's reused id for a replacement, and the startup restore only discards a persisted file when a live row with a different timestamp has superseded it. Files are read back with awk so a torn write can't glue itself onto the next file and take a valid popup down with it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Close the remaining cross-generation id collisions in popup persistence Notification ids restart from 1 with every server process, so an id alone never identifies a notification across a shell restart. The first round of fixes guarded row removal, but review (and a live repro) showed the same collision biting everywhere else an id was used on its own: - Dismissing or clicking a restored toast resolved liveRefs by id and could dismiss, or fire the action of, an unrelated fresh notification, and archive its pending row. Restored rows now never resolve to a live object, and pending rows are matched by id plus timestamp. - parsePopupFiles deduped files by id, so a fresh notification reusing a restored critical alert's id got that alert's file deleted as a "stale duplicate" on the next restore. Files are never deduped now: each one is a popup that was on screen, and the rare genuine leftover from a crash re-shows once and cleans itself up. - The restore only skips an entry when a live row matches both id and timestamp (it is that entry); an id-only match shows both toasts rather than guessing which one to drop. - A same-millisecond replaces_id update shares its predecessor's filename; the replacement's file is no longer deleted alongside the replaced row. - A restored popup's reset lifetime is persisted as an absolute deadline, so a second restart judges it by the clock that actually governs its display instead of dropping it while still on screen. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
David Heinemeier HanssonandGitHub
|
3d033d1b00 |
Stop the menu from opening on the previous evaluation's answers (#6601)
* Evaluate menu guards one run at a time A second evaluation starting while one was in flight could not replace it. Process ignores a command change until the next run and `running = true` is a no-op while running, so setting them did nothing -- but clearing `collected` first threw away the lines the running script had already emitted. Its tail then landed as the entire result, and every id missing from it went back to showing, since `when:` only hides a row on an explicit false. That is how Setup > Defaults > Browser ends up listing browsers that are not installed. Queue the evaluation instead and run it once the one in flight lands, the way provider enumeration already waits its turn. * Answer repeated menu guard questions once per evaluation The menu opens on the last evaluation's answers, so however long the guard batch takes is how long a row can contradict the state it describes: stop a recording and Screenrecord still offers to stop it, because the `pgrep` that would hide it is queued behind fifty package lookups. Almost none of that time is the questions, it is asking them one process at a time. The shipped menu runs `omarchy-pkg-present` 54 times and `omarchy-cmd-present` 23, and reads `omarchy-default-browser` once per row in Defaults > Browser. Prepend a prelude that answers all of it inside the one guard process, off a single package listing, bash's own PATH lookup, and one capture per reader command. The captures are eager because `checked:` reads them inside `$()`, where a lazy memo would not outlive the subshell. Takes the shipped batch from 1.49s to 0.25s with identical answers for all 175 guards. * Make the guard prelude answer exactly as the commands it stands in for The prelude only helps if it is indistinguishable from the commands it shadows, and it was not: - `pacman -Q` resolves a name through what installed packages provide, so with gvim installed it reports `vim` as present. A set built from `pacman -Qq` sees only names, so `install.editor.vim` came back and offered to install what was already there. Build the set from provides too, and send version constraints, which no set can answer, to pacman. - `omarchy-cmd-present` uses `command -v`, which finds builtins; `type -P` searches PATH alone and disagreed on every one of them. - Shadowing a reader with a function caught far more than the plain `$(reader)` the rows use: `command -v omarchy-dns` got the function name, and `VAR=x omarchy-channel-current` got an answer captured without the variable. Substitute the captured value into the expression instead and leave every other form to run the real command. - A reader that exits nonzero could take the batch down under a login shell with errexit set. Also keep the results of a batch that was killed rather than finished, since a row whose `when:` went unanswered shows, which is the failure this set of changes exists to remove. Costs 0.25s -> 0.33s against 1.49s before any of this, still with answers identical to evaluating each guard on its own. * Read every provide pacman reports, wrapped or not `pacman -Qi` wraps a long list onto indented continuation lines whenever COLUMNS is set in the environment, which the login shell the batch runs under may well have done. Reading only the line that starts with `Provides` dropped the rest: at COLUMNS=80 that is 537 of 856 provides on this machine, which puts back exactly the "offers to install what is already there" failure the provides lookup was added to prevent. Follow the continuation lines instead. The version-constraint case was also not testing what it claimed. Interpolating the argument into the shadow's script text let `bash>=1` parse as a redirection, so the shadow was handed `bash` and quietly agreed for the wrong reason -- and left an `=1` file behind, which got committed. Pass arguments as argv to both sides, drop the file, and wrap gvim's provides in the stub so the parser is held to the format pacman actually emits. |
||
|
|
018f881840 |
Extract the Wi-Fi QR share card into its own omarchy.wifiqr panel plugin (#6598)
* Extract the Wi-Fi QR share card into its own omarchy.wifiqr panel plugin omarchy-network-qr now leads with an iface/security/ssid meta line, so a bare summon self-detects the connection and the plugin owns the whole share flow. The network panel loses its overlay lifecycle: with no centered card left inside it, the shadowed open/close collapses back to the stock panel behavior, and the QR button just summons the plugin -- which a clone or third-party plugin can replace, like the speed test. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Keep canceled QR and password runs from leaking into their replacements Copilot review: the cancellation guards dropped in onExited while the canceled run's collectors were still allowed to fire, so a stale stderr could shadow a successful regeneration and a stale password could be revealed under a new network's card. The guards now stay up until the next run launches, good output settles any earlier error, and a bare re-summon no longer inherits the previous card's SSID. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
David Heinemeier HanssonandClaude Fable 5
|
bc75b03114 |
Show plugin ids as subtext in the plugin picker menus
Select-menu options gain an optional third field rendered under the label, filtered alongside it, and returned with the selection. The plugin picker uses it to show every plugin's id and act on the id the selection hands back, replacing the duplicate-name label suffix. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
David Heinemeier HanssonandGitHub
|
9cb3640c9f |
Fix T2 Mac suspend and fan defaults (#6562)
* Fix T2 Mac suspend and fan defaults * Avoid repeated T2 boot image rebuilds * Harden T2 migration test matching |
||
|
|
0269fe0031 |
Route menu ids ahead of app keyword aliases (#6563)
An installed app whose .desktop Keywords contain a menu id captured the route: htop ships Keywords=system;..., so SUPER+ESCAPE opened an empty "Htop" menu instead of the System menu once the Apps menu had merged its rows. Exact ids now win, and app rows are no longer routable at all — their keywords remain search-only. Fixes #6554 Reported-by: Craig Derington (https://github.com/craigderington) Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
David Heinemeier HanssonandClaude Fable 5
|
633f20f408 |
Move Plugins under Defaults and Direct Boot to the end of Setup
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |