8ca61d6b8b84bd0f372fb5db9729e1c2fcfe3693
422
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
c8fb5be42e |
Explain an expired Claude sign-in instead of hiding the limits (#6795)
Only the Claude Code CLI can refresh the OAuth token it saves; the collector just reads it. A machine left alone long enough finds the token lapsed, and that branch returned an empty limits list with no status text at all, so the panel hid its whole limits section and explained nothing. Say what is wrong, and fall back to the cached limits already on disk rather than discarding them. Cached windows are kept only until they reset: a percentage from a window that has rolled over describes a period that is over, and pinning a stale 78% on an allowance that is now untouched would be worse than showing nothing. The probe-failure path gets the same filtering for the same reason. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
ecd57bceee |
Drop the kms hook when the proprietary NVIDIA driver handles early KMS (#6791)
* Drop the kms hook when the proprietary NVIDIA driver handles early KMS install/hardware/nvidia.sh early-loads nvidia_drm (modeset=1) for early KMS, but HOOKS still carried the kms hook, so autodetect pulled nouveau and ~100 MB of its GSP firmware into every initramfs for a driver that never runs. On a Limine UKI setup that meant a 256 MB image where ~144 MB is normal, doubled again by the fallback history on /boot. Filter kms out of HOOKS when nvidia_drm is in MODULES (nvidia.conf sorts before this drop-in) and every PCI display controller is NVIDIA. Hybrid systems keep kms so the iGPU retains early KMS at the LUKS prompt. Verified on an RTX 4090 (nvidia-open-dkms 610.57.04): UKI shrinks 256,183,296 -> 144,066,048 bytes, nouveau and its firmware gone, the nvidia-utils GSP blobs and all four nvidia modules retained, Plymouth still owns the LUKS prompt via nvidia_drm. Fixes #6790 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Address review: quote literals, harden PCI detection, add shell tests Quote fixed string literals in the [[ ]] comparisons per AGENTS.md, and read the PCI tree through OMARCHY_PCI_DEVICES_PATH, the same seam bin/omarchy-hw-nvidia already uses. Require a positively identified NVIDIA display controller before dropping kms: an empty or unreadable PCI tree previously counted as "no non-NVIDIA GPU" and would have dropped the hook. Unexpected trees now keep kms. Cover the conditional in test/shell.d/nvidia-kms-hook-test.sh: nvidia-only, hybrid, no nvidia_drm, MODULES unset under set -u, audio-function-only, empty tree, and a device directory missing its sysfs attributes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Treat unreadable PCI devices as inconclusive and make the test hermetic A device whose class/vendor attributes cannot be read could be another GPU, so skipping it let a readable NVIDIA GPU beside it drop kms without having verified the whole tree. Count it as a non-NVIDIA sighting so kms stays, and cover the mixed case in the test. The test also sourced the host's /etc/vconsole.conf under set -u, where a valid KEYMAP-only file makes the XKBLAYOUT expansion fail in the subshell and ties the result to the machine running it. Predefine XKBLAYOUT and FILES before sourcing the config. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Rebuild existing initramfses once the kms hook no longer applies The settings package deploys the new omarchy_hooks.conf conditional, but nothing rebuilds the initramfs when only a mkinitcpio drop-in changes, so existing NVIDIA-only installs would carry nouveau's ~100 MB of GSP firmware until their next kernel update. Following the precedent of 1784476564, add a migration that rebuilds via limine-mkinitcpio — once per machine, and only where evaluating the installed drop-ins shows the conditional actually dropped kms, so hybrid machines, non-NVIDIA machines, and user-edited configs are left alone. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Document the mid-sourcing MODULES caveat in the kms conditional A later-sorting drop-in that resets MODULES outright (as surface_device_modules.conf does) would strip nvidia_drm after kms was already dropped. Every machine Omarchy writes such a file for is hybrid Intel and keeps kms through the PCI scan, but that is worth stating so the invariant is not broken by accident. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: David Heinemeier Hansson <david@hey.com> |
||
|
|
457aec6a8c |
Stop Bluetooth discovery when the panel closes (#6794)
The discovery retry timer turned adapter.discovering on every second while the panel was open, and nothing ever turned it off. The BlueZ discovery session behind it is held by quickshell's D-Bus connection, so one visit to the panel left the radio in inquiry until the next shell restart — continuously starving A2DP audio on the same controller into stuttering, and 'bluetoothctl show' kept reporting 'Discovering: yes' long after the panel was gone. The panel now tracks the StopDiscovery it owes BlueZ and settles it once closed. A timer bound to the confirmed discovery state does the stopping, rather than a write in the close handler: quickshell only forwards a discovering write that differs from the last state BlueZ reported, so a stop issued while a just-fired StartDiscovery is still awaiting confirmation would be swallowed and leak the session. Binding to adapter.discovering re-arms the stop whenever the confirmation lands, a reopen inside the first interval keeps the scan running uninterrupted, and attempts are bounded so a session another BlueZ client holds up cannot draw StopDiscovery calls forever. One widget instance exists per monitor and they all share the default adapter — the same shared-backend shape the network panel's wifi scanner fix (#6772) dealt with — so the debt follows the session: an instance opening onto a running scan adopts it, a closing instance hands it to a panel still open on another monitor (the popout handoff closes one instance as it opens the next), and a destroyed instance passes it to a surviving sibling. Fixes #6789 Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
f075a789f4 |
Recover the wallpaper picker after interrupted thumbnails (#6775)
* Recover image picker after interrupted thumbnails * Use arithmetic assertions in image cache tests * Bound thumbnail lock waits and reap partial thumbnails A hung generator (vips stuck on a corrupt file or slow mount) held its flock forever, wedging every later picker open; the directory-lock era capped that wait at 30 seconds, so keep the same bound. A generator killed mid-write also stranded its partial .jpg.<pid>.jpg forever, since nothing prunes the cache directory; only the lock holder writes those, so reap them right after taking the lock. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Harden thumbnail locks and cache publication against races Adversarial review caught three holes. The lock fd leaked into vipsthumbnail, so an orphaned or hung vips kept holding the lock after its shell died; close it for the child. Reaping legacy lock directories unconditionally raced a still-running legacy generator through an upgrade; only reap ones older than the longest plausible generation. And cache publication was neither atomic nor exclusive, so a picker killed mid-write, or two interleaving, could leave truncated or mismatched rows behind signatures that still validated - the same permanent hiding this branch set out to fix; publish via renames under a per-key lock, rows first. 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 HanssonandGitHub
|
38542a1f51 |
Open the agent in a normal tiled window (#6769)
The floating rule pinned every agent terminal to 1200x800, which overflows small and scaled displays: window rules see logical pixels, so a 2560x1440 monitor at scale 1.6 is only 1600x900 and the window covered 89% of its height. Tiling drops the fixed size along with the rule, and the shared app-id still earns the terminal tag from terminals.lua. |
||
|
David Heinemeier HanssonandGitHub
|
438f7b3340 | Stop ttfx before closing the screensaver terminal (#6764) | ||
|
David Heinemeier HanssonandGitHub
|
f5893ddd9e | Launch the default agent from the agents widget right-click (#6759) | ||
|
David Heinemeier HanssonandGitHub
|
2cc3510d2a |
Offer an AI diagnosis when a process crashes (#6746)
* Offer an AI diagnosis when a process crashes systemd-coredump journals every core dump under a known MESSAGE_ID with the crashing program, pid, and signal as structured fields. omarchy-crash-watch follows that stream and raises a "Process crashed: <program>" toast; clicking it opens omarchy-agent-crash, which briefs the default agent on the crash. The toast goes through omarchy-notification-send --exec rather than a libnotify action, because the shell runs clicks from its own omarchy-exec hint and never emits ActionInvoked. It keeps the default "omarchy-action" app name too, the only one shouldBypassDnd() lets through -- a crash being the last notification worth swallowing. It stays quiet until an agent is configured, since a diagnosis is all it offers. The method lives in a diagnose-crash skill rather than the prompt, so it is edited in one place and works with whichever agent is default. It covers investigating the core, and reporting a confirmed Omarchy bug upstream: scoped to bugs Omarchy controls, searched for duplicates first, only with the user's agreement, and signed with the model and harness that produced it. A migration reaches existing installs, whose skill symlinks and unit enablement would otherwise sit behind one-time setup paths. * Let the diagnosis clean up the core it extracted "Do not modify or delete anything" contradicted the symbolization step right above it, which writes a core to a temp file and deletes it on exit. Read literally, the core survives -- and the same section warns it holds passwords and tokens. The prohibition is about the system, not about your own scratch. * Do not spend a crash toast on a dead notification server The shell owns org.freedesktop.Notifications, so its own crash takes the notification server down with it -- and a shell crash is exactly what you want told about. The toast was sent once into that gap and the dedupe window was recorded regardless, so the rest of the crash loop went quiet for a minute and `journalctl -n 0` never replays what was missed. It now waits for the restarted shell to reclaim the bus name, as omarchy-migrate-notify already does, and only a delivered toast starts the dedupe window. |
||
|
David Heinemeier HanssonandGitHub
|
9502b81f3b |
Reshape the agent launcher into omarchy agent (#6757)
* Reshape the agent launcher into omarchy agent omarchy-launch-agent becomes omarchy-agent, with prompts on omarchy-agent-prompt rather than the bare route: `omarchy agent` is both a command and a group, so a positional prompt there would shadow any subcommand under it. The launcher takes flags only and points at `omarchy agent prompt` when handed one. Every agent window now launches under a fixed org.omarchy.agent app-id instead of omarchy-launch-tui's default of org.omarchy.<binary>, so one rule floats them all whichever agent is default. Omarchy also stops picking an agent for you. omarchy-default-agent prints nothing until one is chosen, leaving every entry under Setup > Defaults > Agent unchecked, and a first-run invitation offers to take you there. * Wordsmith * Cover the agent routes and the invitation The route split is the point of the change, so exercise `omarchy agent`, `omarchy agent prompt`, and a rejected positional prompt through the router rather than only the binaries behind them. The invitation gets the same treatment as the Voxtype and fingerprint ones: it notifies once, opens the agent defaults menu, and leaves both the notification and the marker alone for anyone who already chose an agent. * Offer the agent choice from the keybinding Super + Shift + Ctrl + A now runs `omarchy-agent --pick`, which opens Setup > Defaults > Agent when nothing is chosen yet. A keypress that writes to stderr and opens nothing just looks broken. * Reach existing installs with the agent invitation first-run installs the invitation hook, and existing accounts marked it complete long ago, so they would never see it -- while being the accounts most likely to need it, since the old getter returned opencode implicitly and most have no agent recorded at all. Post-update hooks run later in the same update, so the invitation arrives without waiting for another one. * Say what the Defaults submenus set Setup > Defaults lists Agent, Browser, Terminal, Editor, but the header inside each repeated the same bare word, which reads as a category rather than a setting -- and says nothing at all when the menu is summoned straight into it. The list keeps its short labels; the headers now name the setting. |
||
|
|
b97a1480dc |
Treat the guard test's socket fixture as optional (#6755)
Standing in for an abandoned compositor means binding a Unix socket, and the sandboxes this guard exists for are the ones that deny it: the fixture raised PermissionError and took the whole file down with set -e, adding a failure in the environment the guard was written to keep clean. Run the cases that need no socket first and skip the rest when one cannot be bound. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
66e3f479a6 |
Follow the keyboard being typed on in the layout widget (#6740)
* Read the keyboard being typed on rather than the one holding main The main flag names no keyboard for long. fcitx5 takes it with the virtual keyboard it binds to inject, and those are filtered out, so on a seat running an input method the pick lands on nothing at all: no label, and the widget hides itself off the bar. #6727 keeps polling in that state rather than settling it, and the poll has nothing new to read. Once fcitx5 unbinds, the flag lands on whichever device libinput listed last, as easily a lid switch as a keyboard, and a device that never receives the toggle reports the layout it started on forever, which is the reading #6574 opened. Every device carries the seat's layout list, but only the keyboard being typed on advances through it, so read the furthest-advanced one. activelayout names the keyboard it moved ahead of the layout, so take that name and let it settle the pick, and the click that switches it. * Leave the buttons out of the seat the widget reads Reading the keyboard being typed on left keyboardName standing for two things at once: the device a click switches, and the device activelayout last named. Only the second was still being set, so the first went empty until a switch happened -- which left the click doing nothing on a seat whose only switch is the click, and left the poll running forever on the one-keyboard install it was written to leave alone. Give each its own property, and set the switch target from the reading that confirmed the keyboard is there. Layout progress only points at the keyboard being typed on while the other devices stay where they started, and the ACPI power button, lid switch and sleep key never do move on their own -- but they answer to switchxkblayout and can hold the main flag, so anything that reads or switches whatever the seat hands back can end up describing a button, and unplugging the keyboard beside one leaves it standing in for the seat. Drop them where the virtual keyboards are already dropped. A reading that reaches hyprctl and finds no keyboard now clears the label rather than leaving a device that is gone described on the bar, told apart from the empty output a killed query leaves by the device list itself, and the watchdog asks again rather than waiting for a poll that a settled seat has already stopped. 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> |
||
|
|
0fa3170504 |
Skip shell tests when the compositor can't be reached (#6749)
* Skip shell tests when the compositor can't be reached, not just when WAYLAND_DISPLAY is unset A set variable only proves the environment was inherited. Sandboxes pass it through while blocking $XDG_RUNTIME_DIR, so Quickshell cleared the guard and aborted inside QGuiApplication, leaving two core dumps per launch instead of a clean skip. Probe the socket and, when there's a signature to ask with, Hyprland itself. Disable core dumps on the way through for the compositor that dies mid-run, which no probe can catch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Retry the compositor query before calling it dead Hyprland can miss a query while it reconfigures outputs, and one miss was enough to skip a whole file's runtime coverage. Retry the way omarchy-launch-shell does. Only a leftover socket reaches the query at all, so the ordinary skip still returns immediately. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
0900855a28 |
Stop hot-reloading the shell when a package upgrade rewrites it (#6751)
Quickshell watches the QML it loaded and reloads on change, so pacman replacing /usr/share/omarchy/shell mid-transaction makes the running shell reload against a half-written tree. That reload fails, and a failure that reaches the config load is not harmless: it raises the reload popup, which is a second engine generation. EngineGeneration::currentGeneration() returns null unless exactly one exists, so the IPC kill that omarchy-update sends moments later takes the QCoreApplication::exit(0) branch instead of the generation's own quit, and Quickshell tears the QML graph down after deleting the QGuiApplication. The first GUI resource touched on the way out aborts: FATAL: QPixmap: Must construct a QGuiApplication before a QPixmap The user gets the crash dialog after an update and a coredump per occurrence. Reported in #6748 with 3 crashes across 10 updates, always following a failed reload. Fixing this in omarchy-update — stopping the shell around the pacman step — would cover one caller and cost the polkit agent and the notification server for the length of the transaction, which the migrations that run next still notify through. It would also have to carry omarchy-restart-shell's refusal to restart a locked session, or reintroduce the hazard that refusal exists for. And omarchy-update is not the only thing that rewrites the tree. The pacman guard turns away a bare pacman -Syu, but nothing turns away a targeted pacman -S omarchy, a pacman -U of a locally built package, the documented OMARCHY_ALLOW_DIRECT_PACMAN bypass, omarchy-dev-pkg-test, or a checkout in a dev-linked tree. Turn the watcher off instead. Omarchy has never reloaded through it: omarchy-restart-shell is what picks up QML changes, and config and plugin changes go through the shell's own IPC. Third-party plugin hot reload is PluginRegistry's own inotifywait and FileView watches its own files, neither of which this touches — QuickshellSettings::watchFiles() gates the config scanner and nothing else. The popup goes off with it, because QML can still ask for a reload directly and leave the same extra generation behind. Environment reaches Quickshell only at launch, so the update that delivers this still runs under a watching shell. It takes effect from the next one. Verified against an isolated instance: breaking a config in place and then sending the IPC kill reproduces the FATAL, and it stops with either variable set. QS_DISABLE_FILE_WATCHER also keeps the failed reload from happening at all. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
970ec26bb0 |
Don't let a usbfs claim count as a kernel driver (#6744)
The vendor-ID guess rejects any device with a driver bound, on the reasoning that libfprint drives readers from userspace so a real one sits there unbound. But libusb claims interfaces through a synthetic usbfs driver, so the reader binds one for as long as fprintd holds the claim — which is exactly while it is being enrolled or verified against. Readers that name themselves take the product-string branch and never reach this, so the exposure is the ones that don't: Goodix 27c6:6594 reports "Goodix USB2.0 MISC", matches on vendor ID alone, and drops out of detection mid-authentication. The menu entry disappears and the first-run invitation stops firing while the reader is in use. Ignore a driver link that resolves to usbfs, and keep rejecting the real ones — usbio-bridge, usbhid, uvcvideo — including on a device that has both. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
a9c159a1f4 |
Restore FPC fingerprint detection in Quattro (#6737)
* Restore FPC fingerprint detection * Anchor the FPC product match to a prefix *fpc* is an unanchored three-letter token on the one branch that is trusted outright, with none of the kernel-driver checking the vendor guess gets. Every FPC reader on record leads with it — "FPC Sensor Controller", "FPC Sensor Controller L:0002 FW:25.26.23.14", and this branch's "FPC L:0000 FW:1425046" — so requiring the prefix costs no coverage while keeping three letters from matching mid-string, where FPC abbreviates unrelated things like flexible printed circuit. Also restore the note about why Elan is kept out of the vendor list, so the two signatures read as the same deliberate exception. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Write no product descriptor for a two-field device spec ${remainder#*:} returns the string unchanged when there is no second colon, so a spec meant to describe a device with no product descriptor wrote the product id out as its product string instead. Every call site happened to pass a trailing colon, so the suite was right by accident. Guard the split and drop the trailing colons, so the two vendor-match cases exercise the path they were written for. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Bind a named driver in the kernel-driver fixture Touching a bare `driver` file asserts that any driver at all disqualifies a vendor guess, which is more than the detector should promise: libusb claims an interface through a synthetic `usbfs` driver, so a reader in active use looks bound by that rule. Link the interface at a named driver directory instead, the way sysfs does. The case still covers what it was written for — a Synaptics bridge or a camera on a fingerprint vendor ID — without fixing the shape of the answer for drivers it was never about. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: David Heinemeier Hansson <david@hey.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
9b8bf1da71 |
Fix two races in the notification popup and history handling (#6735)
* Replay the history a dismissal or a clear was still being written into The popup files a replay reads are written by a serialized queue of shell jobs, and the read ran as its own process alongside it. A dismissal issued a moment earlier could still be queued when the directory was read, leaving the notification out of the replay it was the newest entry of, and a clear issued a moment earlier could still be queued too, replaying entries it was about to remove. The read now waits for the queue to go idle, so the replay shows the history as of the moment it was asked for rather than whichever jobs happened to have landed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Catch up on an update that arrived before its popup had a row Watching a notification for in-place updates starts the moment it is handed over, but the row those updates write to is inserted a tick later, deferred to keep a mid-incubation Repeater from being mutated underneath. A client fast enough to update inside that window found no row to write to, and a property that has already changed does not change again — so the toast and its file sat on the superseded content until something else moved. The row is now refreshed from the live notification once it exists. That reads the same object the signals would have, so an update that beat the insert is picked up and one that did not costs nothing: a refresh whose content matches the row it would write is dropped, which also collapses the several signals a single multi-property update emits into one rewrite. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Hold queued file work behind the replay's read, not just ahead of it The read waited for everything queued before it, but nothing stopped the queue from running on while it worked. A clear or an archive issued during the read could delete or move files out from under awk mid-glob, so a replay could still show a partial history — some of what a clear was in the middle of emptying. The read is a barrier in both directions now: the queue holds until it exits, and it releases on exit rather than on output, so a read that comes back empty or fails cannot park the queue behind it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Queue the replay's read instead of waiting for the queue to empty Waiting for the queue to go idle before starting the read still let work overtake it. A clear or an archive enqueued after the replay was asked for, while the current job was running, was dequeued the moment that job exited — the read only starts once nothing is left — so the replay showed the state after those jobs, which is the race this was meant to close. Unbroken file traffic could postpone the read indefinitely for the same reason. The read is now an entry in that queue rather than a process running beside it. It takes its place in line behind the work queued before the request and ahead of everything queued after, so no later job can overtake it and no amount of traffic can push it back. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
fd23ca023a |
Prune the package cache before updating (#6734)
The pacman cache grows without bound across updates, and nothing in the update flow ever reclaimed it. On a machine that has been updating for a while it reaches several gigabytes of superseded versions that nothing will ever install again. Prune it with paccache -rk2 as the first step of an update. Both halves of that placement are load-bearing. Keeping two versions rather than one preserves the rollback path. The cache is Arch's only offline downgrade: when an update breaks a single package, reinstalling its predecessor from here is the surgical fix, where a snapshot rollback would revert every other package too. Pruning before the packages update means the installed version is still the newest cached, so it survives along with a spare. Retention is by version order and never consults what is installed, so that holds while the installed version is among the two newest cached; a deliberate downgrade or repeated failed transactions can stack newer archives on top of it. Running before the snapshot is what actually frees the space. The cache sits on the snapshotted root subvolume, so a prune taken afterwards leaves the fresh snapshot holding those extents and reclaims nothing until it ages out of the number cleanup. A failed prune warns and continues. Cache housekeeping should not trip the update's ERR trap and tell the user their update went wrong. This runs after omarchy-update-requires-free-space, so it reclaims space during healthy updates but does not rescue a machine already under the 10 GiB gate. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
David Heinemeier HanssonandClaude Opus 5
|
cd84583b56 |
Show a notification the sender updated, instead of the version it replaced
A client that updates a notification through replaces_id does not produce a second onNotification: Quickshell writes the new content onto the Notification object the shell is already holding. The card draws a snapshot copied out of that object — deliberately, since a live QObject in a ListModel role becomes a dangling pointer the moment the server destroys it — so the toast kept showing the superseded text, and archived it to history when it left the screen. A Slack thread that updates in place read as stuck. Every property the card draws is now watched on the notification we hold, and a change rewrites both the model row and the file the popup was persisted under. The file name is that popup's identity, so the rewrite lands in place: a shell restart restores the version last shown, and so does the copy that reaches history. The countdown starts over when the content changes. New text arriving a second before the toast was due to expire deserves a full look, not the remainder of the clock the text it replaced had nearly run through. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
David Heinemeier HanssonandClaude Opus 5
|
ab57ad65fd |
Make notification history the last ten notifications on disk
History was a pair of in-memory lists mirrored into notifications.json, split into "pending" and "past" by a seen/unseen distinction no surface exposed, capped at 100, deduped by an id that repeats across server generations, and pruned by a 15-minute TTL. Replaying it showed five rows drawn from whichever list happened to hold them. Every toast already writes a file under ~/.local/state/omarchy/notifications so it can survive a shell restart. That file is now the history record: when the popup leaves the screen it moves into notifications/history instead of being deleted, the newest ten are kept, and showHistory replays exactly what is in there, including the toasts still on screen when it is asked for. A notification DND silenced is written straight into the same directory, since a toast that never showed is the one worth looking back at. That leaves the models, notifications.json history payload, past pruning, and the /tmp image cache that existed to keep century-old history thumbnails alive with nothing to do, so they go. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
d6b21f8075 |
Launch the default coding agent without permission prompts (#6729)
Every supported agent spells it differently, so map each one to its own bypass flag instead of leaving the launcher at each agent's default. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
David Heinemeier HanssonandClaude Opus 5
|
2fa490dc96 |
Rebuild boot images the Plymouth migration left stale
1784917531 gated its UKI rebuild on initramfs_async=0 being present in the Limine config, but omarchy-settings ships omarchy-defaults.conf with that parameter already in it. Any machine that installed the package and ran the migration in the same update matched the config the package had just written, skipped the rebuild, and kept booting an image baked before the config existed — without initramfs_async=0, so encrypted boots still fell back to an unthemed text LUKS prompt. Compare the booted command line against the configured one and rebuild when they disagree. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
David Heinemeier HanssonandClaude Opus 5
|
4727bad5eb |
Stop the update-lock stub racing the holder it spawns
The stub polled for the lock with its own flock, competing with the holder it had just started. The holder took the lock non-blockingly and never retried, so a lost race killed it and left the lock free. The notifier then saw no update in progress and sent the toast the test asserts it withholds. Wait on the holder's own signal instead. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
David Heinemeier HanssonandClaude Opus 5
|
3888dca7e8 |
Stop script hanging up the inhibitor before it starts
The sleep inhibitor deliberately outlives the start that spawns it, but script tears its pty down as soon as the command returns, and the SIGHUP that follows could kill the inhibitor before it managed to exec. The sudo stub then never logged and the test failed about half the time. Hold the session open from inside until the inhibitor has started. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
David Heinemeier HanssonandClaude Opus 5
|
1e3c43a59b |
Assert the focused monitor the panel actually reports
omarchy-monitor-state stopped shelling out to omarchy-hyprland-monitor-focused when it started deriving the focused name from its own hyprctl snapshot, so the stub the test installed was never called and the assertion could never pass. Expect the focused monitor from the fixture instead, and drop the dead stub. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
b99fd91cf1 |
Simplify the Quattro upgrade, and stop it leaving an error bar behind (#6716)
* Accept either name for the lock authentication command
omarchy-setup-lock was renamed to omarchy-apply-lock in
|
||
|
|
08204846ef |
Detect NVIDIA GPUs without waking them (#6712)
lspci reads PCI config space, and the kernel resumes a runtime-suspended device to serve that read. On a hybrid laptop the discrete GPU idles in D3cold, so the first lspci of a Hyprland config load spends over a second waking it — longer than the 1.5s budget Hyprland gives the whole load. The reload then fails at whichever line runs next, which is why the error pointed at default/hypr/apps/1password.lua rather than at nvidia.lua. Read the vendor, class, and device IDs from sysfs instead. Those are served from cached fields and never touch config space, so nothing wakes up. Classify by device ID while we're here: Turing is both the first generation with GSP firmware and the first at 0x1e00 or above, and Maxwell opens at 0x1340, one ID past the last Kepler part. Bounding the older detector at both ends keeps pre-Maxwell cards off the 580xx driver that cannot drive them, and picks up the Maxwell and Pascal parts the lspci name regex used to miss. omarchy-hw-nvidia was also checked in without its executable bit, which it needs now that nvidia.lua runs it. Fixes #6660 Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
f4b832eba5 |
fix(monitor): fix display mirroring recovery and UI state (#6457)
* fix(monitor): prevent mirror toggle deletion during recovery and fix UI state * Assert the external monitor helper counts mirrors as active The helper now asks `hyprctl monitors all -j`, so the test that pinned it to plain `monitors` failed. A mirrored external is absent from plain `monitors`, which reads as a disconnect and hands the mirror toggle to recovery. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Keep the mirror state line when nothing is mirrored Piping the first mirroring monitor into the branch fed jq's test() a null whenever no output mirrored, and jq aborts there rather than falling back to "". The panel reads this output by line, so the missing line shifted the focused monitor, the scale, and the display list up one, and left mirroring reading as on whenever the external display had focus. Select first and branch inside the pipeline, so the branch only ever sees a monitor and the empty case falls to "" as the lines around it do. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Cover the monitor panel state the shell reads by line Nothing exercised omarchy-monitor-state, so both the mirror direction it reported and the jq that reported it went unguarded. The panel reads the output by line index, where a helper dying mid-script costs a line and shifts every field below it into the wrong property without failing. Assert the line count alongside the fields, over extended, mirrored both directions, and clamshelled displays. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: David Heinemeier Hansson <david@hey.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Ryan Hughes
|
05bb82b34e | Add checkout bin to sudoers path | ||
|
|
27d1b6bebc |
Resolve omarchy_monitor_scale variable reference in clamshell recovery (#6688)
A pinned internal monitor rule that referenced the omarchy_monitor_scale local had the variable name captured as the scale, so clamshell recovery fell all the way to the hardcoded 2. Read the config the way Hyprland writes it: a key's value is whatever sits between the `=` and the next separator, and a bare word resolves against a local only when one exists, so a quoted string stays a string. Comments are cut before anything is matched, and position gets the same resolution since it had the identical bug. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
3b08a85ad1 |
Recover monitors Hyprland brought up with no mode (#6701)
A monitor powered off when the machine boots — a smart strip cutting AC, the PC coming back on its own — still answers DDC, but with a partial EDID that carries no video modes. Hyprland takes the connector as present and brings the monitor up at 0x0. Powering it on afterwards changes nothing: the connector never dropped at DRM level, so no hotplug fires, nothing re-reads the EDID, and the screen stays black until a reboot. Only a reload re-reads it. Forcing a DRM re-probe would work too but needs root, and the kernel's cached mode list stays empty without one, so there is nothing cheaper to poll: the reload is both the fix and the only way to learn whether it was needed. Poll only while a monitor is in that state, back off from three seconds to a minute, and stop as soon as one reports a mode — the machine can sit black all night, and powering the monitor on fires no event to stop on. Nothing will ask again if this loop gives up, so an unreadable answer is not taken for a healthy monitor. It is also not waited on forever: a compositor that stays silent has gone, and with it the session and any reason to keep asking. Reloading on our own schedule means minding the reload guard, which exists to keep Hyprland out of package-owned config mid-transaction, and which only disables the automatic reloads. The guard can now be asked, and recovery holds off while a transaction is in flight. A reload lands a monitor at 0x0 the same way a boot does, so configreloaded is watched alongside the hotplug events. The recovery's own reload comes back through it, and a lock keeps that from stacking a second loop. Contention waits rather than drops: a trigger arriving while a loop is exiting is the last one that will come, and one arriving while a loop is running is answered by its next pass anyway. Mirrors are dropped from `hyprctl monitors`, so the check asks for all of them and filters the disabled ones itself. Monitors turned off on purpose sit at 0x0 too, and re-applying config would fight the user over those. The existing poll here recovers internal panels on docked laptops and never runs on a desktop, which is where this happens. Reported in #6668. Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
David Heinemeier Hansson
|
9f0c4b9792 | Ensure we don't register duplicate bindings | ||
|
|
66f3155f0c |
Label the keyboard widget with the xkb language code (#6699)
* Label the keyboard widget with the xkb language code The label was the first word of the layout description cut to three characters, so a US layout read ENG and a Portuguese one read POR. xkb already pairs every layout and variant with a short language code, which is the code GNOME shows in its own indicator. Read that table once at startup from xkbcli list and key it by description, which is what hyprctl reports as the active keymap, so the same layouts read EN and PT. The code is a language rather than a country, so it stays sensible for the layouts named after neither: Esperanto is EO, Arabic is AR, and Latin American Spanish is ES. Layouts missing from the table keep the old truncated description. * Read the exotic xkb rulesets for the keyboard label xkbcli list leaves out the exotic rulesets, so layouts like trans were missing from the table and fell back to the truncated description: the IPA layout read INT rather than IPA. Those layouts ship in the same xkeyboard-config package and set just as well, so read them too. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Keep the keyboard label to three characters The brief was used verbatim while the fallback was truncated, but not every brief is two or three characters: Burmese (Zawgyi) is my-zwg and Shan (Zawgyi) is shn-zwg. Selecting either widened the widget past its neighbours on the bar. Drop the script suffix and cap the brief the same way the fallback is capped, so those read MY and SHN. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Stop an xkb brief carrying past its own block The brief was only cleared once a description consumed it, so a block printing a brief without one would hand its code to the next block's description and label it wrongly rather than falling back. Nothing in the current xkb data does that, and the option groups were skipped only because the last layout happened to consume its brief first. Clear the brief when a line starts a new block so the pairing is explicit, and cover the option list the 2-space match is what keeps out. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Fall back when a layout description names a built-in A custom xkb group called constructor or toString reached an inherited member of the lookup rather than a brief, and splitting it threw a TypeError that took the whole label binding down instead of falling back to the truncated description. Take the lookup only when it returns a string. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: David Heinemeier Hansson <david@hey.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
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> |
||
|
|
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> |