c5a5e14e99d702bd126a91c7964e4eacd808f67a
499
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
ea6ee9440a |
Add omarchy-crash-mute to mute and unmute one program
The mute was reachable only as `omarchy-toggle crash-ignore/<program>`, which asks whoever runs it to know the flag layout, to reduce a binary's path to the name the watcher keys on, and to have read the rule that a name climbing out of that directory writes an unrelated toggle. All of that was carried in the skill's prose, which is the wrong place for a rule that has to hold: prose is advice, and the thing being advised about is a name the crashed program chose. So it is a command now. `omarchy crash mute hyprland` silences that program, `off` lifts it, `toggle` flips it, and no argument lists what is muted. It takes the binary's path as readily as the name and reduces it the way the watcher does, so the `Executable:` line from `coredumpctl` can be handed straight to it; it refuses what is not one component of a name, so it cannot be talked into writing outside its own directory whatever it is given; and it re-reads the flag afterwards and reports what is now true rather than what was asked for. The listing counts only regular files, because that is all the watcher honours -- anything else in there would read as muted while the crashes kept arriving. A leading `--` is consumed so a program named `-h`, which the router would otherwise answer with its own help, can still be muted. The watcher gained an unrelated fix that this uncovered. Its fields are read with `IFS=$'\t'`, and tab is IFS whitespace, so an empty field collapsed into the next delimiter and shifted every field after it along one: a crash whose comm was empty had a path read as its pid and was discarded as somebody else's. A process can set its comm to nothing, so that was reachable. Empty fields now arrive as a dash like missing ones, and a dash joins the empty and dot cases that fall back to `unknown`. Co-Authored-By: Codex XHigh <noreply@openai.com> |
||
|
|
8d14869689 |
Let a crash diagnosis mute that program's notifications
A crash that is understood is not a crash that stops: an upstream bug waiting on a release, a program that dumps core every time it exits. The diagnosis explains it once and the toast keeps arriving, and the only answer Omarchy had was Crash Capture, which turns off every program's notifications in order to silence one. The watcher already resolves a name to dedupe on and announces that same name in the toast, so the mute is keyed on it: a flag file under toggles/crash-ignore/, written by the existing omarchy-toggle and read by the existing omarchy-toggle-enabled. One flag per name rather than one list, so `on` mutes, `off` un-mutes, and `ls -A` shows what is muted, with no new file format and nothing to parse. It is the executable's basename wherever one was recorded, falling back to the process name, which the kernel truncates to fifteen characters -- muting the truncated form would match nothing, forever, while looking like it worked. The name is not always a name, though, and the mute turns it into a path. A program picks its own comm and prctl takes anything, including slashes, and the watcher falls back to comm whenever a crash carries no absolute executable. So it is stripped to its last component first: without that, `a/../bar-off` is a legal comm aimed at an unrelated Omarchy flag, letting a crashing program suppress its own notification and letting a user who accepted the offered mute hide their bar instead. Stripping does not always leave a component either -- `/` leaves an empty string, which is no kind of array subscript and no kind of toast, and `.` or `..` names a directory that omarchy-toggle would touch and report success on, leaving a mute that never matches. Both fall back to `unknown`, the word omarchy-agent-crash already uses for a name it does not have, and which mutes like any other. The skill offers this at the end of a diagnosis and never runs it unprompted, which makes it the single change a diagnosis may make to a system it otherwise only reads. It tells the agent to use the name it was handed rather than re-derive one, since the watcher resolved that name already and the two agree for ordinary names and not for strange ones; a diagnosis started by hand from `omarchy agent crash <pid>` is given no name and gets the derivation instead. It also says to treat the name as hostile text rather than as a word -- it is whatever the crashed program's author called a file, so a single quote inside one closes the quotes around it and the rest runs as the shell -- and to check the flag arrived rather than assume it. Co-Authored-By: Codex XHigh <noreply@openai.com> |
||
|
Luke ParkeandGitHub
|
eb7ecd13f3 | Keep Ori interactive when launched with a prompt (#8455) | ||
|
|
0ae1694830 |
Constrain the tzupdate sudoers rule to a single timezone argument (#8194)
The wildcard granted passwordless root for timedatectl set-timezone plus any trailing arguments, so -H/--host and -M/--machine reached the SSH and machine transports as root. Systemd 261 guards argv injection into ssh, but -H still drives root's SSH client at an attacker-chosen host, and the transport resolves its helper through PATH; only Defaults secure_path stands between that and a planted ssh running as root. Match the argument with an anchored POSIX ERE that admits exactly one timezone token (no whitespace, no leading-dash segment, no traversal component), so no second argument and no option can ever match. The sole caller, omarchy-menu-timezone, passes one list-timezones value and is unaffected. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: Codex XHigh <noreply@openai.com> |
||
|
|
77305ed3b9 |
Enable Dell XPS 13 sidecar speaker amplifiers (#7032)
The Dell XPS 13 DX13260 drives its two CS35L56 sidecar speaker amplifiers through a quirk that Linux only gains in 7.2, so until Arch ships that kernel the machine plays through one amplifier with no bass. The dell-xps13-sidecar-amps package selects the same driver path with a module override; this installs it on that exact machine and nowhere else. The detector requires both the DX13260 product name and SKU 0E53, because the override forces a quirk value rather than merging into one, and a machine that gets it wrong loses whatever quirk the kernel would have chosen for itself. Pacman registers a package even when its post_install scriptlet fails, so the leaf calls dell-xps13-sidecar-amps-apply itself instead of trusting the install to have applied: a failed cleanup or boot-image rebuild has to reach the caller rather than hide behind a package pacman considers installed. That is also why the migration marks reboot-required only after the apply succeeds — a migration that exits non-zero keeps no completion marker and retries the apply on the next run, even though pacman already has the package. The leaf runs after intel/ptl-kernel.sh rather than beside the other Dell leaf at the top of install/hardware/all.sh, so its boot-image rebuild sees the Panther Lake kernel that step swaps in rather than the stock one it removes. Co-authored-by: Codex XHigh <codex@openai.com> |
||
|
|
4cd8a081cb |
Fix Codex usage collection on 0.149 (#7649)
* Fix Codex usage collector approval policy * Capture codex argv with boundaries in the scanner test The stub joined its arguments with "$*", so the assertion compared one flattened string and could not tell five arguments from fewer containing spaces. Passing "-s read-only" and "-a on-request" as single arguments -- which codex rejects as an unexpected argument -- passed the test. NUL separation and an array comparison keep the boundaries the assertion is about. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Codex XHigh <noreply@openai.com> --------- Co-authored-by: Omabot <omabot@omarchy.org> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Codex XHigh <noreply@openai.com> |
||
|
|
23dab9ec4d |
[Security] Stop the FIDO2 setup staging its authfile at a predictable /tmp path (#7904)
* [Security] Stop the FIDO2 setup staging its authfile at a predictable /tmp path pamu2fcfg wrote to /tmp/fido2 and the registration was then moved into place with `sudo mv`. Any other local user can pre-create /tmp/fido2, and rename(2) does not dereference the final component, so the privileged move installed the attacker's symlink itself as pam_u2f's global authfile -- a file consulted by `sufficient` lines in /etc/pam.d/sudo and /etc/pam.d/polkit-1. The same move also carried the staged file's ownership into /etc, so on every install to date /etc/fido2/fido2 is owned by the invoking user at mode 0644. That needs no attacker: anything running as that uid can add its own credential and satisfy the machine's sudo prompt without root. Stage under mktemp and hand the bytes to `install` instead, so the authfile is always a fresh root-owned regular file rather than an inode a non-root user still controls. Guard the already-registered check with -L, which -f would otherwise follow, and reject a symlinked /etc/fido2 in the remove path for the same reason. A migration takes ownership of authfiles left behind by the old code; it reports a symlink rather than repairing one, since chown would follow it and removing it would strip sudo from anyone whose only credential is the token. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012e6WagC5iUigCGoK1tQeFz * Install the FIDO2 authfile with -T and refuse a non-regular path `install SRC DEST` without -T treats an existing directory at DEST as a destination directory: it drops the credential inside as /etc/fido2/fido2/tmp.XXXX, exits 0, and setup reports a successful registration while PAM goes on reading a path that is not a file. -T makes that an error. The already-registered check has the same blind spot from the other side. -f follows symlinks, so it reads a symlinked authfile as a registration and leaves it in place, and is false for a directory, so it tries to register over one. Only a regular file is a pam_u2f authfile; anything else is now refused with the same advice to remove it and set FIDO2 up again. The test deleted every staged path that fell outside its scratch directory, taking the path from the script under test and already resolved through any symlink -- so a script staging through one would have named a file of the user's and had it unlinked. It now unlinks only a file its own stub wrote into. On a machine that already has /etc/fido2/fido2 the staging assertions cannot run at all, and the file used to pass without exercising one of them. That branch now asserts what the host state promises instead: a regular authfile still has to be recognised as a registration and left alone, and anything else has to be refused. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> * Replace the FIDO2 authfile inode rather than chowning it in place Permission is checked at open(2), not at write(2), so a descriptor the registering user opened on the authfile while it was still theirs stays writable through chown and chmod alike. pam_u2f resolves /etc/fido2/fido2 to that same inode, so the repair left the account it authenticates able to append a credential it controls -- the exact state the migration exists to end, now recorded as migrated and never revisited. Installing a fresh root-owned copy and renaming it over the path leaves any such descriptor writing to a file nothing reads. Credit to #7703, which reached the same conclusion independently. An interrupted run heals: the staged copy is root-owned 600 and inert, no marker is written, and the next run replaces it. A directory or device at the authfile path is no more ours to rewrite than a symlink is, and chmod 600 on a directory would only make it untraversable, so both are now reported rather than repaired. The repair had no test, because it names an absolute path no unprivileged suite can write. It is exercised through a scratch copy with that one literal retargeted, rather than by reading the path from the environment: the migration hands `install` and `mv` root, and an operand the caller can choose is a privileged write to anywhere. The copy is only as honest as the substitution, so the test fails if the migration stops naming the path exactly once. Covered: the no-op on a machine that never registered a key, which must not cost a password prompt; the repair itself; the new inode; the absence of a staged copy afterwards; a second account finding it done; and the symlink and non-regular cases. Each assertion was checked against a mutation that defeats it -- notably a repair with the right install call, mode, content and cleanup that writes through the old inode, which only the inode assertion catches. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> * Finish hardening FIDO2 authfile installation * Guard the FIDO2 directory and the stage path the setup writes through install -d follows a symlink at /etc/fido2 and applies the mode and ownership to whatever it points at, so the credential would be staged and published inside the link target and that directory silently reopened to root:root 755. The leaf guard above it only covered fido2 itself, and this is the same threat omarchy-remove-security-fido2 already names on its side. mktemp's output is an operand for a privileged tee, chmod, mv and rm. The migration validates it before any of them run; the setup did not, so take only the name it asked for there too. The suite was guarded on the host's own /etc/fido2/fido2 and exited early when one existed, which meant the staging assertions asserted nothing on exactly the machines that use FIDO2. Drive a retargeted copy the way the migration suite already does, so every branch is a fixture and all of them run everywhere. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Stop the FIDO2 migration recording a repair it never made omarchy-migrate writes the per-user completion marker on any zero exit, so the two states this migration cannot repair got one line in the update terminal and were then silenced for good: no login notice, no re-run, the migration recorded as done having repaired nothing. Those are precisely the machines where the authfile may already be under someone else's control, so raise them through omarchy-notification-send as well, where they outlive the scrollback. Delivery is best-effort: a machine with no user bus or no notification server must not abort the migration and take every later one with it. The early exit had the same shape of problem. It read the authfile unprivileged, and the old setup created /etc/fido2 with `sudo mkdir -p`, which took the union of the caller's umask and sudoers' 0022 — so registering under `umask 077` left the directory mode 0700 with the user-owned authfile still inside. Absence and "cannot look" are the same answer to those tests, and the migration exited 0 and marked itself complete. Ask root whether a registration is actually behind an untraversable directory before reopening it, so an aborted setup that left an empty directory, or one an administrator keeps private, does not have its mode widened and its group and special bits discarded for a repair it does not need. A machine that never set FIDO2 up has no directory here and still reaches exit 0 without a password prompt. The notification assertion checks argument shape rather than a substring of the command line. The glyph is a private-use codepoint, and losing it shifts every argument left: -g swallows the headline, the body becomes the title, and the message goes out with no description — which a substring match reads as a pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> * Cover the FIDO2 removal's symlink guard The -d to -e || -L change is load-bearing for the threat its own comment names — a dangling link at /etc/fido2 that -d reads as absent, left for the next setup to install an authfile through — and it was the one part of this work with no test behind it. Name the directory once so the suite can retarget a copy, the same seam the setup and migration suites use, and assert both halves: the link goes, and the directory it pointed at does not. 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> Co-authored-by: Codex XHigh <noreply@openai.com> |
||
|
|
9285b19d6a |
[Security] Stop USB device names from being executed as Hyprland Lua (#8129)
* Stop device names from being executed as Hyprland Lua Hyprland input-device and monitor names come from USB descriptors and hyprctl output, so they are attacker-influenceable, yet the toggle and monitor commands interpolated them straight into hyprctl eval and into generated Lua that Hyprland re-executes on every reload. The input-device toggle keys are bound with locked = true, so a malicious USB name reached Lua code execution from the lock screen; a persisted disable made it run on every start. This closes that class everywhere it appeared. - The touchpad/touchscreen disable is now the device name in a plain-text sidecar file, read back by a packaged Lua module on reload, never a generated Lua file. hyprctl eval Lua-quotes the name and control characters are rejected outright. - Dropped the shipped *-disabled.lua templates so nothing seeds a disabled state to /etc/skel, making the name file the single source of truth read from a hardcoded ~/.local/state to match the sibling tools. - The reload loader excludes those two legacy filenames, so a leftover generated *-disabled.lua on a not-yet-migrated install can never be sourced as code again; a migration then recovers the device name from it and deletes it, sanitizing installs that ran the vulnerable version. - All four monitor scripts (internal, mirror, clamshell, scaling) now validate an output name against a plain-connector-name pattern before writing it as Lua, closing the same latent pattern in the siblings. - paths.lua treats a set-but-empty XDG_STATE_HOME as unset, matching the bash side so state is never read from the filesystem root. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0144ZDt44vtxjyF8j9Y88NrM * Let a failing Lua assertion fail the test lua discards the status of a chunk read from stdin, so a blown assert printed its traceback and still exited 0: the surrounding `set -euo pipefail` never fired and the following `pass` printed `ok`. Every Lua block in these two files was unenforced, including the assertion that a quoted `hyprctl eval` cannot reach `os.execute` and the negative control that proves the test can detect the injection at all. Passing the chunk as a script argument makes lua report the failure. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Re-apply a recovered input-device disable to the running session The package hook reloads Hyprland during `omarchy-update-system-pkgs`, before `omarchy-migrate` runs, and at that reload the generated Lua is already excluded while the name file does not exist yet — so a touchpad or touchscreen the user had switched off comes back on, and stays on until their next login. Reload once more once the name has been recovered, which is the same path a login already takes to read it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Codex XHigh <codex@openai.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: Omarchybot <omabot@omarchy.org> Co-authored-by: Codex XHigh <codex@openai.com> |
||
|
|
4637735aa2 |
Pin trusted PATH in privileged DNS helper (#8172)
* Pin PATH to trusted dirs when omarchy-dns holds root A dev link prepends a user-writable checkout bin/ to sudo's secure_path, so the passwordless `omarchy-dns Cloudflare` sudoers rule lets root resolve a bare helper (dirname, install, tee, nmcli, ...) out of that checkout — turning checkout-write access into arbitrary root execution. Pin PATH to trusted system directories once EUID is 0, leaving the unprivileged wrapper phase free to locate sudo/pkexec on the caller's PATH. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YUWoHbBoKMjsjV6X3nu1H5 * Assert the trusted-PATH pin is gated on root, not merely present The EUID assertion matched `(( EUID == 0 ))` anywhere in the file, and require_root has carried that exact test since long before the pin existed. Deleting the pin left the assertion passing, so it stood for nothing: a run with the pin neutered reached the behavioural probe with both greps green. Anchor on the unindented guard and require the pin to be the line it opens, which no other construct in the script satisfies. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> * Skip the DNS trusted-PATH probe where user namespaces are unavailable `fail` ends the file, so a sandbox or hardened kernel that refuses unprivileged user namespaces did not just lose the probe — it took the two elevation assertions below it down as well, reporting a product defect where there was only a missing capability. The non-graphical suites are meant to run on any machine and treat a skip as a passing test, the way require_compositor and plugin-add-test.sh already do. Gate the probe on the namespace it needs and say so when it is absent; the static checks above and the elevation checks below run either way. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: David Heinemeier Hansson <david@hey.com> Co-authored-by: Codex XHigh <noreply@openai.com> |
||
|
|
68ab12f77d |
Share the git URL check, and refuse the transports Omarchy does not clone from (#8174)
* Share the git URL check between theme-install and plugin-add Both commands clone a URL a stranger can choose, and each carried its own copy of the rule that refuses a git option or a `<helper>::<address>` transport helper before cloning. Two copies of a security check drift: the second one arrived four months after the first, and only because someone went looking for it. The rule now lives in omarchy-git-url-check and the callers ask it. Its absence refuses the URL rather than waving it through, since the callers read a non-zero status as a refusal and a missing command exits 127. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> * Refuse a git URL naming a transport Omarchy does not clone from `<helper>::<address>` is only one of the two ways a URL reaches a remote helper. git also resolves git-remote-<scheme> for `<scheme>://<address>` whenever the scheme is not one it connects itself, so `ext::sh -c id` and `ext://sh -c id` arrive at the same helper while only the first was refused. That shape cannot be refused outright, because it is also how every legitimate URL arrives, so the scheme is checked against the transports git still connects itself. `git+ssh` and `ssh+git` are on that list: they are spelled like a helper and read as plain ssh, and leaving them off would refuse a URL that clones today. `ext` and `fd` are off it deliberately -- git ships a helper for each, and `ext` runs whatever command the URL carries. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> --------- Co-authored-by: David Heinemeier Hansson <david@hey.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: Codex XHigh <noreply@openai.com> |
||
|
BastiandGitHub
|
30471bf35a |
Guard plugin-add against git transport-helper URLs (match theme-install) (#8067)
* Guard plugin-add against git transport-helper URLs omarchy-plugin-add cloned a user-supplied git URL without the transport-helper guard that omarchy-theme-install already applies (added in #7884, which did not touch plugin-add). Port that guard (reject ext::/fd:: and leading-dash forms, keep https/ssh/scp-style incl. IPv6) and add a regression test. Stock systems are unaffected (git default protocol.ext.allow=never); this removes the silent dependency on that default and aligns the two install paths. * Test the plugin-add guard's leading-dash arm via the gum input path The prior leading-dash cases only exercised the argv option parser, not the guard (removing the guard's -* arm left them green). Drive a dash value through the interactive gum prompt under a pty so the post-input guard is actually covered; skip cleanly where util-linux script is unavailable. |
||
|
|
06a3dbca42 |
Offer to reboot when toggling sudoless Docker; show only the relevant menu entry (#8098)
* Offer to reboot when toggling sudoless Docker; show only the relevant menu entry Group membership only takes effect on a fresh session, and in practice a logout or newgrp isn't enough — only a reboot reliably applies it. So the setup/remove commands now flag the reboot and offer to do it now with a gum confirm (like the GPU toggle), and the notices say "after a reboot" instead of pointing at logout or newgrp. The existing-user migration passes OMARCHY_DEFER_REBOOT so it does not prompt mid-update — omarchy-update-restart still handles the reboot once the whole update finishes. The Setup > Security menu also showed Sudoless Docker under both Setup and Remove. Condition the Setup entry on the group being absent (Remove already conditions on it being present), so only the applicable one appears. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Gb7x6poap4hGCndPx5qt5T * Ask omarchy-sudo-docker whether Docker needs sudo Every place that chooses between talking to Docker directly and elevating was testing group membership by hand, and the menu guards tested the wrong thing: they read the running session's groups, which do not change until the reboot, so after enabling sudoless Docker the menu still offered Setup — the one action that could no longer do anything — while Remove stayed hidden. Add omarchy-sudo-docker as the single answer, with the two questions that actually differ in that window. By default it asks whether this session can reach the socket, which is what decides if a command must elevate: lazydocker and the Windows VM keep prompting until the reboot lands. With --configured it asks whether the account is set up for sudoless Docker, which is what the menu and the toggles need, so the menu switches to the action that can change state as soon as the group is written. Also correct a comment: nothing surfaces reboot-required in the bar; it is omarchy-update-restart that reads it during a later update. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Gb7x6poap4hGCndPx5qt5T --------- Co-authored-by: David Heinemeier Hansson <david@hey.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
|
1565919c87 |
Flag a reboot when the docker group changes (#8080)
Group membership is fixed at login, so removing (or adding) the docker group does not take effect in the running session. The existing-user migration and the Setup > Security toggles now call `omarchy-state set reboot-required`, so omarchy-update-restart prompts for the reboot that actually applies the change (and the bar shows it pending). A plain log out and back in still works. The migration test now exercises the real removal command and omarchy-state rather than a stub, asserting the reboot flag is set on removal and left alone when the user is already out of the group. Claude-Session: https://claude.ai/code/session_01Gb7x6poap4hGCndPx5qt5T Co-authored-by: David Heinemeier Hansson <david@hey.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
|
b5ded31e2f |
Don't put the user in the docker group; make it opt-in (#8056)
* Don't put the user in the docker group; make it opt-in The docker group is root-equivalent: anything in it can `docker run -v /:/host` and rewrite the host as root with no password. On a single-user box that's not an escalation (the owner is already a wheel/sudo user), but it hands any code running as the user — a rogue plugin, a poisoned dependency — a silent, headless, passwordless path to root that sudo's password prompt would otherwise gate. Stop granting the docker group by default. The daemon still runs (docker.socket); the Docker TUI and the Windows VM reach it through a polkit prompt, and the plain `docker` CLI runs under sudo. Sudoless Docker is a warned opt-in via Setup > Security (omarchy-setup-security-sudoless-docker). No automatic path may re-grant it: install and first-boot provisioning never record or apply the group (provisioning also filters a docker line left in an older factory snapshot), and the Quattro upgrade no longer adds it. The Windows VM keeps needing the root daemon for a privileged container (KVM, NET_ADMIN), so it is reworked to run without the group and without becoming a new way in: - The compose lives in a root-owned dir and is only written by an elevated, input-validated writer. A root-invoked bring-up must never consume a file a user-process could rewrite to bind-mount / into the guest — the old ~/.config/windows compose was exactly that. Volume paths are rebuilt from $HOME on migration rather than trusted from the (user-writable) legacy file, path validation rejects traversal, and the privileged sub-action is checked against an allowlist before dispatch (a slash in it would otherwise run as a path). - pkexec elevates a verified root-owned command path, not a PATH-resolved one, so an authorized prompt can't be redirected to an attacker's binary. - The guest password is kept in a private 0600 per-user file for RDP instead of a world-readable compose, and a declined authorization is reported as such, never as a completed stop. Existing installs auto-migrate the VM (no redownload) and refresh the stale Docker launcher entry. 🤖 Generated by Opus 4.8 in Claude Code. Reviewed by Codex XHigh. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Co-Authored-By: Codex XHigh <codex@openai.com> Claude-Session: https://claude.ai/code/session_01Gb7x6poap4hGCndPx5qt5T * Migrate existing installs off the docker group The default flip only reaches new installs; existing users keep their docker group membership and stay exposed. Extend the migration that already refreshes the Docker launcher to also remove the current user from the group when present, reusing omarchy-remove-security-sudoless-docker so there is one source of truth for the change and its notice. It takes effect at next login (the current session keeps working), and passwordless docker can be turned back on from Setup > Security > Sudoless Docker. Migrations run with sudo available — during `omarchy update`, or in the terminal the pending-migrations notification opens — so the privileged removal does not prompt at an unattended login. The no-op path (already out of the group) needs no privilege. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Gb7x6poap4hGCndPx5qt5T * Refuse symlinked VM mount sources; correct the docker CLI docs Review follow-ups. valid_path keeps a traversal string (/./, //, ..) out of the compose, but it is a string check: a symlink planted at ~/.windows or ~/Windows redirects the privileged bind mount exactly as traversal would, because docker follows it. So verify the mount sources as root immediately before bringing the VM up — refuse a source that is a symlink or resolves through one — which is where the string check cannot help. A missing source stays fine (docker creates a plain dir). Also correct the development-tools manual: the CLI is not transparently elevated (there is no docker wrapper and `d` is still plain docker), so say plainly that docker on the command line takes `sudo` until sudoless Docker is enabled. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Gb7x6poap4hGCndPx5qt5T --------- Co-authored-by: David Heinemeier Hansson <david@hey.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: Codex XHigh <codex@openai.com> |
||
|
|
4baae6bf2a |
Draw text as ASCII art in the Omarchy logo font (#8037)
* Add omarchy-ascii for drawing text in the logo font Renders text as ASCII art in Delta Corps Priest 1, the FIGlet font the Omarchy wordmark itself is drawn in, so branding art can be words rather than a picture. The font is embedded in the script and the layout is done in awk, so the command adds nothing to the default package set. The layout runs on one-byte stand-ins for the five block characters the font draws with. Column arithmetic over the characters themselves counts bytes in one locale and characters in another, and the stand-ins keep length() and substr() counting columns either way. Delta Corps Priest 1 carries letters and spaces only, and every mirror of it ships the same file with the digit and punctuation glyphs empty. Anything else is dropped and named on stderr, and text with nothing drawable at all exits 1 rather than printing silence. 🤖 Generated by Opus 5 in Claude Code. * Correct what the renderer did with input it could not draw The route never ran on piped text. The metadata declared `<text...>` as required, so `omarchy ascii` with nothing on the command line resolved to the router's help while `omarchy-ascii` run directly worked, which is why the tests missed it: they all called the binary. The argument is optional now, and a test goes through the route. Text reached awk as a command-line variable, where awk reads backslash escapes of its own, so `omarchy ascii 'A\nB'` drew two blocks instead of naming the backslash as a character the font lacks. A text longer than the argument list could not be passed at all. It arrives as awk's input now, with the font on a descriptor of its own. A line with nothing drawable printed nothing at all, so a blank line between two words closed the gap up rather than keeping it. Every line draws its block now, blank ones included, which is what figlet does with a newline. Placing a glyph scanned and copied the whole width of the art so far, costing the square of the line's length: four thousand characters took forty-six seconds. A row is now held without its trailing blanks, counted separately instead, so a glyph costs its own width and those four thousand characters take a tenth of a second. A skipped control character was named on stderr by writing it out, which sends it to the terminal as a control character; those are named by code now. An unknown option was drawn as art rather than refused, so a mistyped `--width 40` quietly rendered the word "width". figlet.c trims the column of blanks that every row of an `M` shares when it is the first glyph on a line, and figlet.js keeps it. asciiart.eu runs figlet.js, so the rendering follows figlet.js and a test pins that `M`, because the wordmark alone does not catch the difference and the next reader would have no way to tell the choice from an oversight. 🤖 Generated by Opus 5 in Claude Code. Reviewed by Codex XHigh. Co-Authored-By: Codex XHigh <codex@openai.com> --------- Co-authored-by: David Heinemeier Hansson <david@hey.com> Co-authored-by: Codex XHigh <codex@openai.com> |
||
|
|
20400badda |
Stop a psmouse quirk from failing every install (#7236)
* Stop a psmouse quirk from failing every install install/hardware/fix-synaptic-touchpad.sh calls modprobe against the running kernel. Under 4.0 the only thing that runs it is the ISO finalizer, inside arch-chroot, where uname -r still names the live ISO's kernel while /lib/modules holds the target's. The live ISO always boots linux-t2 and the configurator gives every machine that is not a T2 Mac stock linux, so those two never match: modprobe exits 1 with "Module psmouse not found in directory /lib/modules/<live kernel>". run_logged returns that status and omarchy-apply-hardware runs under set -euo pipefail, so a fresh install stops on the first machine with a device named "synaptics" and no psmouse loaded -- reported from a ThinkPad in #6985, but nothing about it is Lenovo-specific. Skip the load when the running kernel's modules are not reachable, and warn instead of failing when modprobe declines for any other reason. An optional touchpad improvement should never be able to halt an install. This does not make InterTouch reach the installed system: a module loaded into the live kernel is gone at reboot, so on 4.0 this script has never applied anything to an installed machine. Persisting it means writing options psmouse synaptics_intertouch=1 to /etc/modprobe.d, which forces the SMBus transport past the kernel's own allowlist on any touchpad merely named "synaptics" in /proc/bus/input/devices. That is a hardware-behaviour change on a wide class of machines, so it is left for a maintainer to decide separately. Fixes #6985 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Ask modprobe whether psmouse resolves rather than guessing at /lib/modules The reachability check ran through OMARCHY_SYNAPTIC_MODULES_DIR, an override modprobe itself never saw: it decided whether the load was attempted but could not change where modprobe looked, so the guard and the load consulted different places and the seam read as though it configured module lookup. modprobe -qn answers the same question directly -- it resolves psmouse against the running kernel without loading it -- so the guard and the load now agree by construction and the override goes away. The arch-chroot case that broke installs is still skipped silently, for the same reason it always was: the live kernel's modules are not the ones on disk. Inline the remaining /proc/bus/input/devices override at its only use. These leaves are sourced one after another into a single shell, so a variable left at the top level outlives the script that set it. Pin the wiring assertion to the run_logged call instead of any mention of the path. A commented-out line satisfied the old grep, so the test could pass with the quirk no longer running at all. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013L5zwTiZ2CsgazyxXBiPa8 --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
535d8f3485 |
Regenerate mise wrappers that still print mise's output to stdout (#8041)
omarchy-mise-install gained --quiet on its `mise use -g` line so a wrapper no longer prints mise's "tools: pkg@version" ahead of the tool's own output. That only changes wrappers written from then on, and the migration that installed the current ones is already marked complete, so every wrapper already on disk keeps polluting stdout: `claude --version` still answers with two lines, and a wrapper for a protocol-speaking command answers with a line its caller cannot parse. Rewrite them through omarchy-mise-install so the template stays in one place. Wrappers were written by four different generated forms over time and only the ones a later migration happened to regenerate moved forward, so all four are recognized. The whole file has to match one of them exactly, which leaves a wrapper someone has added a line to alone and makes a second run a no-op. Claude-Session: https://claude.ai/code/session_01Mv1FyKG2VGZRdtknQ7YjU8 Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Ryan Hughes
|
3b0d9b5734 |
Merge remote-tracking branch 'origin/quattro' into harden-notification-exec-argv
# Conflicts: # test/shell.d/notification-send-test.sh |
||
|
Ryan Hughes
|
8f245e59dc |
Restore notify-send option parity and prove legacy fail-closed
The direct-Notify rewrite dropped notify-send options that callers rely on, which the momus review caught: omarchy-display-text-size uses -r/-p to refresh one toast in place, and the acceptance suite uses the --expire-time=15000 equals form. Re-add -r/--replace-id (replaces_id), -p/--print-id (emit the returned id), and the --flag=value form for every long option; a dash-leading description like "-50% off" is now kept as body text rather than erroring, and --exec "" is rejected. Add a fixture proving the deliberate upgrade behavior: a popup persisted by a pre-upgrade shell with a legacy `exec` shell string restores with an inert click (execArgv empty, the old string never run) rather than executing it. |
||
|
Ryan Hughes
|
e3729a385b |
Send notifications via the Notify D-Bus method, never notify-send
omarchy-notification-send now calls org.freedesktop.Notifications.Notify directly with `busctl --user`, instead of shelling out to notify-send. Each value is one typed D-Bus parameter, so there is no argv/option layer that could reinterpret a relayed headline like `--hint=…` or `-rf` as an option or a hint: the summary and body are strings, and omarchy-exec-argv is built only from --exec. A leading `--` keeps busctl's own getopt from reading a dash-leading value as a busctl option. Map -i to app_icon, -t to expire_timeout, and urgency to the byte hint; unknown options are now a hard error rather than a silent pass-through. Route the unused hypr o.notify helper and the sample hooks through the wrapper too, and tighten the bin-style test so nothing under bin/ may call notify-send. The test stubs busctl and trips if notify-send is invoked. |
||
|
|
7e469f962d |
Let a received Taildrop file wait to be answered (#7953)
* Let a received Taildrop file wait to be answered A delivery can land hours after it was sent, and the toast announcing it was expiring after five seconds -- so a file that arrived while nobody was at the machine was gone from the screen before anyone could click it open. Critical urgency is what the shell reads as a popup that lives until it is clicked or dismissed, the same thing omarchy-crash-watch uses to keep its click-to-diagnose toast around. The wrapper takes options after the headline and description as well as before, which is how this argument list is built. That path had no test, and it fails quietly rather than loudly: the wrapper appends its own default urgency last, so an urgency it stopped parsing would reach notify-send as `-u critical ... -u low` and the toast would go back to expiring. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> * Say it in the commit message, not above the code `-u critical` next to a line that builds a notification says what it does, and the five lines explaining why it is there were a recap of the change rather than something the code could not say. The reasoning stays where it belongs, in the commit that made the change. 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> Co-authored-by: Codex XHigh <noreply@openai.com> |
||
|
Claude Opus 5 (1M context)andCodex XHigh
|
1b15120d27 |
Keep relayed text out of notify-send's option parser
The argv click command closed injection through the hint's value, but the sender still handed the headline and description to notify-send bare. A value beginning with a dash is parsed there as flags, and one shaped like `--hint=string:omarchy-exec-argv:[...]` is read as a hint of its own -- libnotify keys hints in a hash table, so the later of two replaces the earlier and a forged headline outranks the vector --exec built. That is reachable without any --exec in sight: omarchy-tailscale-send passes a single file's basename verbatim as the description, so a file named like the hint gives its click action to whoever chose the name. Put the headline and description behind a `--` so notify-send reads them as text, and refuse any pass-through word carrying omarchy-exec-argv -- --exec is the only thing that may build a click command. Co-Authored-By: Codex XHigh <noreply@openai.com> |
||
|
Ryan Hughes
|
21cbbf8194 |
Recognize --exec only after the positionals
A greedy pre-scan matched the first --exec token anywhere on the line, so an untrusted headline or description literally equal to "--exec" could be mistaken for the delimiter. It always failed closed (the following token became a dash-option argv[0] that parseExecArgv rejects), but it was a latent footgun surfaced by an adversarial review. Detect --exec only in the trailing-option loop, after the headline/description positionals are captured. A headline that is the string "--exec" is now kept as text and the real trailing --exec still wins. The residual — a description exactly equal to "--exec" losing its click action — is an inherent, harmless CLI ambiguity for a value identical to the delimiter. |
||
|
Ryan Hughes
|
bf2013e6f3 |
Make --exec take the command as rest-of-line words
Replace --exec-arg with an ergonomic --exec that consumes the rest of the line as the click command. The caller's shell tokenizes the words into discrete arguments before the tool sees them, and the shell runs them as positional parameters (never a re-parsed string), so safety is identical to the argv form while the call sites read naturally: `--exec omarchy toggle something`. Crucially the tool never splits a string itself — a single quoted whole-command argument is rejected and points at the unquoted form, because whitespace- splitting a string hands argument boundaries to whoever controls its content (the injection we are avoiding). --exec must come last; migrate every caller. |
||
|
Ryan Hughes
|
eb988b42e6 |
Remove --exec entirely; --exec-arg is the only click-command form
A free-form shell-string --exec sitting next to the safe --exec-arg is a standing invitation for the next caller to interpolate untrusted data and reintroduce the RCE. Remove it: omarchy-notification-send --exec now errors and points at --exec-arg, and the shell drops the omarchy-exec string hint and its bash -lc execution path, leaving only the argv path. Migrate the remaining string callers (the first-run invitation hooks, wifi and welcome prompts) to --exec-arg, and update their notification mocks. Trim the verbose security comments added along the way. |
||
|
Ryan Hughes
|
07443f3970 |
Run notification click actions as argv, not shell strings
The click action of a notification was a free-form shell string run through `bash -lc`, safe only when every sender shell-quoted every interpolated value perfectly. One slip is RCE: a hostile yt-dlp video title forged an output record and injected an mpv option into the click command (mehmetince.net RCE, partially addressed by #7847). Add a parameterized transport: omarchy-notification-send gains --exec-arg (repeatable), encoding a JSON argv into the omarchy-exec-argv hint. The shell runs it with Quickshell.execDetached(argv) and no shell, so data an attacker controls is only ever one argument and can never be reparsed as a command. The shell fails closed on a malformed argv hint. The legacy free-form --exec string is retained but honored only from Omarchy's own omarchy-action toasts, and deprecated. Migrate all in-repo callers (screenshot, screen recording, taildrop receive, migrate-notify, crash-watch, yt-dlp host) to --exec-arg. Update docs and tests. |
||
|
|
ef6d9e6605 |
Stop an installed theme from running code (#7884)
* Stop an installed theme from shipping code `omarchy theme install <url>` clones a stranger's git repository into ~/.config/omarchy/themes, and omarchy-theme-set then copied that whole directory into the staged theme. Most of the files in a staged theme are code rather than colour: Hyprland requires hyprland.lua and gum_env.lua from it at login, Neovim loads neovim.lua at startup, and alacritty.toml, kitty.conf, foot.ini and ghostty.conf each name the program the terminal launches. Installing a theme was the same act as running its author's code, and nothing on disk distinguishes an installed theme from one the user wrote. Stage only what a theme needs in order to be a theme: colors.toml, light.mode, the preview and unlock images, and image files under backgrounds/. Everything else is ignored, named on stderr, and generated from default/themed/*.tpl instead. Symlinks are never followed, because in an untrusted theme they point wherever the author chose. A theme older than colors.toml keeps its palette: its alacritty.toml is read for colours in a scratch directory and only the resulting colors.toml is staged, so the terminal config never lands. The filter belongs in omarchy-theme-set rather than in omarchy-theme-install because staging is the choke point. It also covers themes installed before this change, themes copied in by hand, and files a theme gains later through `omarchy theme update`. First-party themes under $OMARCHY_PATH/themes are unaffected. Per-theme overrides of a generated file are no longer available to user themes; the template at ~/.config/omarchy/themed/<file>.tpl replaces that, and icons.theme is the one setting with no replacement. 🤖 Generated by Opus 5 in Claude Code. * Stop a theme URL or name being read as an option or a path Three paths in the theme commands took an attacker-shaped string straight into git, into basename, or into rm. `git clone "$REPO_URL"` passes the URL as the first positional argument, so a URL beginning with a dash is parsed as an option instead and the destination path becomes what git tries to clone. Pass `--` before the URL so a URL is always a URL. git also treats `<helper>::<address>` as a remote helper to run; git's own protocol.allow default already refuses `ext::`, so rejecting that shape here is a second line rather than the fix, and it keeps holding if that default ever moves. The helper name is a bare word at the very start of the URL, which is what the guard matches: an scp-style IPv6 host such as git@[2001:db8::1]:org/repo.git carries `::` of its own and still clones. `basename "$REPO_PATH" .git` has the same problem one step later, after the scp-style prefix has been stripped: `host:-s/foo.git` leaves basename reading `-s` as an option and returning `.git` as the theme name. Take the name with `--`. That name is then joined into a path that is about to be `rm -rf`'d, so a repo whose basename came out as `..` would take ~/.config/omarchy with it. omarchy-theme-remove had the same shape from its own argument, and omarchy-theme-set's sed/tr normalization does not stop a name containing a slash. Reject empty, anything starting with a dot, and anything containing `/` in all three, before the name reaches a path. 🤖 Generated by Opus 5 in Claude Code. Reviewed by Codex XHigh. Co-Authored-By: Codex XHigh <codex@openai.com> * Re-stage the current theme for installs that already applied one Dropping a theme's code at staging time only takes effect the next time a theme is staged. An install that already applied an extra theme keeps that theme's hyprland.lua, gum_env.lua, neovim.lua and terminal configs in ~/.local/state/omarchy/current/theme, which Hyprland requires at login and the terminals include at launch, and nothing forces a theme change — so for those installs the fix would arrive whenever the user next happened to switch themes, which may be never. Re-stage once through omarchy-theme-refresh. First-party themes stage identically, so the cost for everyone else is a single retint during an update they are already running. 🤖 Generated by Opus 5 in Claude Code. Reviewed by Codex XHigh. Co-Authored-By: Codex XHigh <codex@openai.com> * Stop a theme's unlock image republishing a file it points at omarchy-plymouth-set-by-theme reads unlock.png straight out of ~/.config/omarchy/themes, which is an installed theme's own directory and outside the staging filter, and hands the path to omarchy-plymouth-set. That path was copied twice into world-readable /usr/share — once by the user into the Plymouth theme, and once by `sudo cp` into the SDDM theme. A symlink there was followed both times, so a theme could name a file it cannot read and have root publish it. Refuse a symlinked logo, and copy the staged logo to SDDM instead of rereading the caller's path as root. The staged copy is made by the user, so nothing privileged opens a path the caller chose. 🤖 Generated by Opus 5 in Claude Code. Reviewed by Codex XHigh. Co-Authored-By: Codex XHigh <codex@openai.com> * Limit only what an installed theme could run Two corrections to the rule this branch introduced, both narrowing it to what it was actually for. It applied to every theme under ~/.config/omarchy/themes, which swept up themes the user wrote themselves. Their machine, their file: a theme they wrote is theirs to fill however they like, and Omarchy's own themes were never in scope. Only a theme that came from someone else needs limiting, and the repo already knows which those are — omarchy-theme-extras calls a theme with a `.git` directory an extra and a symlink someone's working copy, because that is what `omarchy theme install` leaves behind when it clones. Use the same test. It was also an allowlist, which dropped files that carry nothing but colour and left theme authors worse off for no gain. Drop only what can run: any `*.lua`, since Hyprland requires a theme's hyprland.lua and gum_env.lua at login and Neovim loads neovim.lua at startup; the four terminal configs, since each names the program the terminal launches; and vscode.json, whose extension field reaches `code --install-extension` and a VS Code extension is arbitrary JavaScript. Everything else an installed theme ships is kept, so btop.theme, chromium.theme, helix.toml, icons.theme, keyboard.rgb and shell.toml go back to being the theme's to set. Symlinks are still dropped, now at any depth rather than only where an allowlist happened to look. A denylist is wrong the moment someone adds a template and does not think about it, so the decision is forced rather than remembered: the test fails on any default/themed/*.tpl whose output is recorded as neither code nor colour, and a new terminal or a new Lua-loading editor cannot be added without classifying it. What this does not cover, and is written down in docs/theming.md rather than implied: a theme shipped as an archive and unpacked by hand looks exactly like one the user wrote. `omarchy theme install` only takes git URLs, so the supported path is always filtered, but this marks where a theme came from and is not a sandbox. 🤖 Generated by Opus 5 in Claude Code. * Fix what the review found Four things, all confirmed against the source before changing anything. The migration failed permanently when the active theme had been removed. `omarchy theme remove` deletes the directory without repointing theme.name, so the name survives, the staged copy survives, and omarchy-theme-refresh exits 1 because neither source directory exists — leaving the migration pending forever and the stale staged Lua exactly where it was, which is the one thing it existed to remove. Seed the default theme in that case: there is nothing to re-stage from, and the removal should have left a working theme behind anyway. The staging test skipped the strict-mode header that docs/testing.md makes the contract for every shell test. Adding it means the patterns that fail on purpose have to stop being bare `cmd && fail` compounds, which errexit reads as the script itself failing; the mutations were re-run afterwards to confirm the assertions still fire rather than the run dying early and looking like something else. The guards in omarchy-theme-install and omarchy-theme-remove had no coverage — they were checked by hand and left that way. theme-install-guards-test.sh stubs git and the themes directory and proves an option-shaped URL, a transport helper, and a name that would climb out all stop before git or rm runs, that a dash inside the path no longer becomes a basename option, and that an ordinary URL still clones and applies. The new docs/theming.md prose was hard-wrapped, which AGENTS.md forbids for docs/. Unwrapped. The rest of that file is wrapped from before and is left alone rather than churned through this change. 🤖 Generated by Opus 5 in Claude Code. Reviewed by Codex XHigh and Copilot. --------- Co-authored-by: Codex XHigh <codex@openai.com> |
||
|
|
b71c60fe30 |
[Security] Stop a video title from becoming the Download Video play command (#7847)
* Stop a video title from becoming the Download Video play command The host parsed yt-dlp's after_move line as title plus path, so a newline in page metadata could forge the path. Clicking the toast then handed that value to mpv as options. Print only the real file, ignore anything that is not inside the download dir, and invoke mpv with --. * Refuse downloads whose video title contains control characters The hoodie page still offered a real hidden clip, so yt-dlp saved it even after the play-action fix. A title with newlines is not a legitimate name; abort before the download and tell the user it was refused. * Test the forged record in the order yt-dlp emits it The records ran forged-first and good-last, so the assertion measured recovery after bad records rather than preservation of an already-captured path when a forged record arrives afterwards. That is the shape a hostile title actually produces, because a title ending in a newline closes its own record and leaves the genuine path on a line the loop ignores. As written the assertion passed with resolve_download_file replaced by a no-op. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Resolve the download path without dropping a trailing newline Command substitution strips trailing newlines, so an in-directory symlink pointing at a regular file whose name ends in one canonicalised to a different path -- which may itself exist -- and that path then passed the containment check and reached ffmpeg and the click command. Reading realpath's NUL-terminated output keeps the name intact, and a resolved path carrying a control character is refused outright. Not reachable through a yt-dlp download, since --restrict-filenames strips control characters from the name it writes; it is the helper's contract that was wrong. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> * Accept a download directory that resolves to / realpath returns "/" for the root directory, which made the containment pattern "//*" and rejected every file saved directly under it, so the host reported a failed download after saving the file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> * Stop refusing a download because its title has control characters The gate cannot tell a hostile title from a legitimate one. --print emits one line per extracted video and --no-playlist does not collapse a multi_video result, so a page holding two clips arrives as two titles separated by a newline and is refused exactly like a forged record would be. It also guaranteed nothing it was read as guaranteeing. The simulate run and the download run are separate fetches, so a site is free to answer them differently, and the check never constrained the metadata the download actually used. What stands between a record and the click command is resolve_download_file, which is untouched here. Leaving a check that refuses valid pages while securing nothing invites the path validation to be relaxed later on the strength of it. A gate that would work is possible -- --print '%(title)j' encodes each title as JSON on its own line, which separates a newline in the metadata from a newline between videos -- but it belongs with a use for the title rather than as a bare refusal. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> * Disarm the legacy exec-before-download hook too --no-exec clears the modern --exec map but leaves --exec-before-download stored separately, and yt-dlp restores it as a before_dl postprocessor, so a hook configured in the user's yt-dlp config still ran during the download this host drives. The accompanying test runs download_url itself against stubbed tools. Everything else in this file exercises the helpers in isolation, which left the invocation uncovered: restoring the title to the record template, or dropping --no-exec or the trailing --, passed every assertion here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> * Toast the page title again instead of the saved filename Deriving the toast text from the sanitised filename cost the title it was meant to show: "My Great Clip" arrived as "My_Great_Clip [My_Great_Clip]". The title is safe as notification text -- it is an argv element, never part of a command -- so the only question was getting it out of yt-dlp without reopening the record forgery. It now comes from the download run, so it describes the file that was actually saved, and it is printed as %(title)j. JSON-encoding is what makes that safe: a newline or tab in page metadata becomes an escape sequence inside one quoted string rather than a record boundary, so a title can no longer split itself across lines. The decoder keeps only what precedes the first control character, refuses anything notify-send would read as an option, and leaves the filename-derived title as the fallback when a page offers nothing usable. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Name the saved file after the page title The download landed as "My_Great_Clip [My_Great_Clip].mp4" when the page called it "My Great Clip". --restrict-filenames was carrying more weight than it earns here: it folds spaces to underscores and strips non-ASCII, which is what mangles the name, and it is not what keeps the record stream safe. yt-dlp removes control characters from a filename either way -- a newline becomes a space, tabs and DEL and NUL are dropped -- so a path printed after the move is still only ever one line, which is the property resolve_download_file depends on. Dropping the [%(id)s] suffix is the other half of matching the title, and it trades away the uniqueness that suffix bought: two videos sharing a title now share a name, and yt-dlp skips a download whose file already exists, so the second one toasts as a failure. Restoring the suffix is a one-line change if that trade is the wrong way round. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Omabot <omabot@omarchy.org> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Codex XHigh <noreply@openai.com> |
||
|
|
1cc5c72e2c |
Add Ori as a lazy-loaded agent and a default-agent choice (#7709)
Ori is OpenRouter's harness: `ori claude`, `ori codex` and `ori opencode` start those agents against OpenRouter's model catalogue, and `ori code` is Ori's own agent. That last one is what the default-agent entry launches, bare — Ori has no approval prompt to skip, so there is no "don't stop to ask" flag to pass it the way the other agents get one. The package is `github:OpenRouterLabs/ori-releases`, because upstream ships prebuilt binaries as release assets and publishes nothing to npm. mise's `github` backend picks the right asset per platform and verifies GitHub's artifact attestations on the way in; `ubi` resolves the same release but is deprecated for removal in mise 2027.1. The menu glyph at U+E909 is OpenRouter's own mark. Ori publishes no logo of its own and its product page renders that one, so there was no Ori-specific mark to prefer over it. Co-authored-by: Codex XHigh <noreply@openai.com> |
||
|
|
2c247e390e |
Stop the About logo moving when the animation starts (#7786)
* Ask the terminal whether the layout scrolled Whether the logo is on the rows the frames address was decided by arithmetic: count the lines of a second fastfetch run, and animate if the window has one more. That holds only while the second run and the real one agree, and they need not — a module that appears between them, a wrap the measurement never sees, anything that makes the painted layout a row taller than the counted one. The screen then scrolls, the logo sits a row above where these frames draw it, and the animation paints a copy of the logo one row below the real one. fastfetch has just painted when the question is asked, so the terminal already knows the answer: an unscrolled layout leaves the cursor one row past its last line. Ask for it, and keep the arithmetic for a terminal that will not say. The reply has to be read without a command substitution around it, or the query goes into the substitution's own pipe instead of to the terminal, and what comes back is the escape rather than a row. 🤖 Generated by Opus 5 in Claude Code. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Find the logo in the render instead of assuming where it is The row and column the frames draw on came from the padding in this repo's fastfetch config. The config that runs is the one in /etc, and `omarchy dev link` says plainly that it does not replace files at fixed system paths — so the two can disagree, and nothing in the code would notice. A logo fastfetch drew on row 1 or row 5, redrawn on row 3, is a logo that jumps the moment the animation starts and stays where the animation put it. fastfetch's own output is already being captured to measure the layout's height, so the logo can be found in it: take the longest line of the file as a landmark, look for it in the render, and turn where it was found back into where the logo starts. Padding of any size lands correctly, and a render that does not contain the file's own text is not this logo at all — a config that restyled it, a placeholder that was substituted — so there is nothing to animate and it is left alone. That last part subsumes what the config-path check was guessing at. It is kept, because it also decides whether the window may be fitted, which happens before there is a terminal to measure anything in. 🤖 Generated by Opus 5 in Claude Code. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Take the cursor query back out Asking the terminal where the cursor came to rest was meant to see a scrolled layout rather than infer one. It cannot: a linefeed at the bottom margin scrolls the screen and leaves the cursor on the bottom row, so a render that fitted exactly and one that scrolled both answer with the same number. Measured on a real terminal — a 29-line layout in windows of 30, 29 and 28 rows answers 30, 29, 28. The guard therefore only ever agreed with the arithmetic it replaced, and only in the case the arithmetic already had right. What it did add was a read on the same stdin the keypress that closes About arrives on. A key pressed while the query is outstanding is swallowed; a reply that arrives after the timeout is read by the next tick as the keypress, and the window closes on its own; typed text of the right shape is accepted as an answer, because nothing checked for the introducer; and the query is written before the read turns echo off, so a fast reply can be echoed onto the screen. None of that buys anything the line count did not already give, so it goes. 🤖 Generated by Opus 5 in Claude Code. Reviewed by Codex XHigh. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> * Fit the About window with a little room to spare The window was sized to exactly what was measured: the columns the widest module line needed, and one row past the layout's last line for the cursor. That measurement is taken once, and then the content goes on living. An uptime turns minutes into hours and hours into days, a version string grows, a module shows up after the next boot — and a window with nothing in hand clips at the right edge or scrolls the top padding away the moment any of it happens. A scrolled layout also moves the logo off the row it was drawn on, which is where a shifting logo comes from. Two columns and a row, which is invisible on screen and enough for anything that ticks over. The remembered size in about.fit is keyed on the logo, so the first launch after this still opens at the old size and the fit corrects it there and then. 🤖 Generated by Opus 5 in Claude Code. 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: Codex XHigh <noreply@openai.com> |
||
|
|
eca89f9518 |
Animate the About logo with a passing glint (#7768)
* Animate the About logo with a passing glint fastfetch has no animation of its own, so the sweep is ours. Every frame is composed once up front and a tick writes one of them, repainting only the cells fastfetch drew the logo on, which holds 40fps for under 1% of a core and never reaches the module column six columns to its right. The logo is handed back exactly as it arrived: frames carry the colour fastfetch drew it in rather than a plain reset, so between glints the window is byte-for-byte the one it was before this change. Where the logo on screen might not be the text in the file, it stays still rather than guess — a fastfetch config in any directory searched ahead of Omarchy's own, a logo built from $1 colour placeholders or from a tab fastfetch expands itself, a window too small for the layout to fit without scrolling, and a shell whose locale is counting bytes instead of characters. A resize moves those cells, so a WINCH trap ends the sweep on the frame it happens rather than up to a poll later, which measured 10ms against 830ms. The polling stays as the backstop for a signal that arrived while it could not be taken. 🤖 Generated by Opus 5 in Claude Code. Reviewed by Codex XHigh. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> * Give the sheen a file of its own The launcher was carrying two things: what a glint looks like, and what it is drawn over. Only the second is about fastfetch. bin/omarchy-logo-sheen now knows how to lean a band of light across an ASCII logo and nothing about About, and it is handed where the logo sits, what colour to give its cells back, and how much room it has. When a frame may be written stays with the launcher, because that is inseparable from how the window closes and resizes. The tests split along the same seam, and the sheen's half no longer strips the launcher's tail to reach the code it tests. 🤖 Generated by Opus 5 in Claude Code. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Leave a logo still when one character is not one cell The frames slice the logo by character and the terminal draws it by column, so the sheen only puts a row back where it found it while those two agree. A double-width glyph, a combining mark and a joined emoji each break that, and a cut through one of them renders as something else — pushing the rest of the row right, into the module column, with nothing on screen to say the logo moved. A user can put any of the three in the logo by editing the text. Comparing the row's character count against its width in columns is the assumption itself, so it is what gets checked, rather than a list of the glyph classes that happen to break it today. 🤖 Generated by Opus 5 in Claude Code. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Size the About window from the layout fastfetch drew The fit predicted the content height from the logo and the module column, taking the taller of the two. Once the logo is the taller one fastfetch writes a row more than that arithmetic expects, so every logo of 27 rows or more got a window one row short and scrolled its top padding away. The shipped logo is 26 rows, which is why it never showed. Ask fastfetch how tall the layout came out instead of predicting it. That measurement was already being taken for the sheen, which refuses to animate a layout that scrolled — so a tall logo used to lose the glint as well as the padding row. 🤖 Generated by Opus 5 in Claude Code. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Leave the logo still when NO_COLOR asks for none fastfetch drops the logo's colour when it writes to a terminal that set NO_COLOR, but not when it writes to the substitution that measures it. The colour to hand those cells back in was therefore measured as green while the logo on screen had none, and the first glint would have left the whole logo green. It stops suppressing autowrap there too, so a narrow window soft-wraps and scrolls where the measurement cannot see it and the frames go on addressing rows that moved. Both follow from animating a screen drawn in a mode the measurement did not reproduce. A glint is colour besides, which is the thing NO_COLOR asks for none of. 🤖 Generated by Opus 5 in Claude Code. Reviewed by Codex XHigh. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> * Read fastfetch's config paths whole, and do not read silence as an answer Splitting each listed path on whitespace dropped everything after the first space, so a config under a home directory containing one was missed and the fit and the sheen went ahead against a layout neither had measured. The marker fastfetch prints beside the config it settled on is not part of the path either. A listing that failed was also indistinguishable from one that found nothing, because the status of a process substitution is discarded, so a fastfetch that could not enumerate read as "no custom config". Fall back to the directory fastfetch has always looked in first rather than take silence for an answer. 🤖 Generated by Opus 5 in Claude Code. Reviewed by Codex XHigh. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> * Notice a resize that lands while the grid is being read The sweep read the WINCH flag before the grid rather than after it. A signal arriving during the two command substitutions that read the grid is delivered only once they finish, so the flag was still false when it was tested, the grid still compared equal, and one more frame went out at coordinates the resize had already moved. Read the flag last, after the check it could have landed during. 🤖 Generated by Opus 5 in Claude Code. Reviewed by Codex XHigh. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> * Check that the render loop is what plays the sheen Every builder the tests drive can be exercised while nothing on screen ever animates. Replacing the render loop's animated branch with the still one it replaced left all of them passing, so nothing was holding the animation onto the screen it belongs on. 🤖 Generated by Opus 5 in Claude Code. Reviewed by Codex XHigh. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> * Name the animation after the branding it animates omarchy-logo-sheen sat in a group of its own, and a group whose only command is hidden still gets a header printed for it with nothing underneath. It belongs beside omarchy-branding-about, whose art it animates: the group already exists, the two halves of About branding are next to each other, and `omarchy branding about` still routes to the command rather than the helper now sharing its prefix. The tests take the names of what they cover, the way the rest of the suite does. 🤖 Generated by Opus 5 in Claude Code. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Fewer moving parts in the sheen Four questions about a logo turned out to be one. Whether the shell is counting characters or bytes, whether a tab or an escape is in the line, whether a glyph is double-width or a combining mark or a joined emoji — each was asking whether one character is one cell, so that is the only thing asked now. It is also less strict in the one case that deserves it: plain ASCII art animates in a C locale, where the locale probe used to refuse everything. One band of light instead of a white core inside a green halo, which is three colour spans a row rather than five and no helper to clamp four cuts with. Only the left cut needs clamping at all: a slice starting past the end of a line is already empty, while a negative offset would count from the end of it. One loop instead of two, because an empty frame list plays nothing. A logo that cannot be animated now waits in the loop the animated one rests in rather than in a second copy of it, and the build that failed leaves no frames behind, since that loop plays whatever it finds. The logo's colour comes out of one match rather than a loop eating one escape at a time. 🤖 Generated by Opus 5 in Claude Code. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Say in the manual which art the glint leaves alone The line promised the glint to any art in the file, and the code does not: art whose characters are not one column wide is left still on purpose, as is the whole screen for anyone keeping a fastfetch config of their own. Somebody reading the old line and seeing a still logo would take deliberate behaviour for a broken feature. Name the condition rather than the list of glyph classes behind it, and say that both modes of Set From Image meet it, because that is the path almost everyone is on. 🤖 Generated by Opus 5 in Claude Code. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Draw the band in a colour bold cannot collapse A terminal can be told to render bold text in a brighter colour — foot's bold-text-in-bright, whose palette-based form brightens a bold regular colour into its bright counterpart. fastfetch draws the logo bold green, so under that setting the logo is already bright green, which is the colour the band was using: the glint came out the same green as the art and nothing appeared to happen at all. None of the four terminal configs set it, so it was waiting on whoever turned it on. Bright white instead, because no regular colour brightens into it, and the band shows whatever the terminal does with bold. Narrower with it, since white against green needs less width to read than a second green did. 🤖 Generated by Opus 5 in Claude Code. 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: Codex XHigh <noreply@openai.com> |
||
|
|
07fccef41c |
Add Super + Q as a second chord for closing a window (#7767)
* Add Super + Q as a second chord for closing a window Super + W stays the documented default. Super + Q is the chord people arrive with from macOS, where Command + Q quits the app, and typing it into Omarchy did nothing at all until now. 🤖 Generated by Opus 5 in Claude Code. Reviewed by Codex XHigh. * Put an action's alternative chord on one keybindings row Super + W and Super + Q both read "Close window" in the menu, two rows apart, with nothing to say they were the same thing -- and the alternative sorted above the default. The scratchpad and the calculator had the same trouble, each bound to a chord and to a second key. Four actions are named as having an alternative, one at a time, and the second chord joins the first one's row. A rule would be wrong here: Alt + Tab and Shift + Alt + Tab both say "Reveal active window on top" while cycling opposite ways, and a media key is nobody's idea of an alternative to a Super chord. Both halves still have to agree on what they dispatch, since a label is only what a chord is called, and an unresolved dispatcher never counts as agreement. Nothing is allowed past the 35-character column: a pair that would overrun it stays as two rows rather than pushing its arrow out of line. The menu elides a row that outgrows its card -- 754px of label, 78 monospace characters at the heading size -- and the longest entry already sits at 74, so widening the column to fit the widest pair would have cost two dozen rows the end of their description. Priority ordering reads the rendered row, so the chord sharing it would otherwise reclassify the entry: XF86Calculator alone belongs in the tail kept for media keys, and it took the calculator down there with it. Ranking now reads the chord that leads the row. The key left of 1 reads as ~ rather than Hyprland's name for it, whether a bind names it or reports the keycode for the keymap to resolve. Cached records predate all of this, so the cache version moves with it. 🤖 Generated by Opus 5 in Claude Code. Reviewed by Codex XHigh. Co-authored-by: Codex XHigh <noreply@openai.com> --------- Co-authored-by: Codex XHigh <noreply@openai.com> |
||
|
|
13a969e1ab |
Only offer Update > Extra Themes when there is one (#7775)
* Only offer Update > Extra Themes when there is one omarchy-theme-update pulls the themes under ~/.config/omarchy/themes that came from a git clone, so on a machine that has never installed one by hand the row opens a terminal that prints nothing and closes. Guard it with the same predicates the command itself applies, since a row that shows over a symlinked theme or a worktree's `.git` file is the same dead end in a narrower shape, and pin the two to each other in the guard test. Co-Authored-By: Codex XHigh <noreply@openai.com> * Extract the Extra Themes guard into omarchy-theme-extras The row's `when:` and omarchy-theme-update each carried their own idea of which themes came from a git clone, and the two only matched because a test held them together. Name it once instead: omarchy-theme-extras lists those directories and exits nonzero when there are none, so the row asks exactly the command its action runs. Living in a script also puts the glob out of reach of whatever shopt a login shell left set for the guard batch. Co-Authored-By: Codex XHigh <noreply@openai.com> --------- Co-authored-by: Codex XHigh <noreply@openai.com> |
||
|
|
b63616422f |
Leave an auto-scaled internal panel alone in clamshell recovery (#7581)
With the default scale = "auto", sync_internal_scale read the config, rejected "auto" as non-numeric, fell back to the hardcoded default 2, and force-applied it whenever the compositor's auto resolution differed. Since the script runs from omarchy-system-wake after every idle cycle, the panel flapped between 2 and auto's own value (1.5666667 on a 198 DPI panel) on every wake/reload pair. A config without a usable number -- "auto", or an expression only Hyprland's Lua can evaluate -- delegates the scale to the compositor: whatever it resolved for the enabled panel is the configured scale, so there is nothing to correct. Recovery of a disabled panel is unchanged and still re-enables it with the remembered scale, falling back to the historical default 2. Fixes #7265. Also the scale-revert half of #7301. Claude-Session: https://claude.ai/code/session_01L4Z6GimYhR1Kpsir24VAPF Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
ed7bae4ac5 |
Replace Gemini coding agent with Antigravity (#6900)
* Replace Gemini coding agent with Antigravity * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * Remove the dead Gemini mise wrapper in the Antigravity migration Remove Preinstalls no longer lists gemini, so the wrapper Omarchy created would have stayed in ~/.local/bin with nothing left to clean it up. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Install Antigravity when it is the default a Gemini user is migrated onto The opt-out check skipped the install but the rewrite ran anyway, so anyone who had removed the preinstalls was left with a default agent naming a command that is not there. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Fix Antigravity skill provisioning and Gemini wrapper migration - Wires Omarchy's default skills into Antigravity by linking them to ~/.gemini/config/skills/ in bin/omarchy-provision-user and migrations/1786719479.sh. - Fixes the Gemini wrapper migration in migrations/1786719479.sh to recognize and remove wrappers containing either `mise use -g "gemini"` or `mise use -g --quiet "gemini"`, while leaving hand-written wrappers intact. - Adds regression tests for both skill provisioning and wrapper removal in test/shell.d/default-agent-test.sh and test/shell.d/provision-user-test.sh. * Stop the provisioning test from retheming the session it runs in The test ran the real omarchy-provision-user, which sources install/user/all.sh and so reached omarchy-theme-set: hyprctl reload against the live compositor, gsettings against the live desktop, and a global Node install, none of which the skill symlinks it asserts need. Its mocks for omarchy-done and omarchy-refresh-applications were shadowed anyway, because provisioning prepends $OMARCHY_PATH/bin ahead of them, so stubbing the install suite at its own path is what a mock cannot do here. The exit status is checked rather than discarded: the assertion held even when provisioning died outright, because the symlinks are made twenty lines before the suite runs. * Match the Gemini default and wrapper the way Omarchy writes them The migration decided both questions differently from the code that owns them. It read the default agent with grep -qxF, while omarchy-default-agent takes the first line through read, so a padded " gemini " that the launcher still resolves was left naming an agent the launcher no longer supports. The wrapper it deletes was matched anywhere in the file, so a hand-written one that only mentions the installer's line in a comment went with Omarchy's own. Reading it the launcher's way and anchoring the match settles both against whoever wrote the file. The skills loop guards its glob the way migrations/1786539345.sh does, so an empty source cannot leave a symlink named "*" behind a migration already marked complete. Co-Authored-By: Codex XHigh <noreply@anthropic.com> * List Antigravity among the skill directories The manual named Claude Code, Codex, Pi and the generic location; provisioning now links ~/.gemini/config/skills too. Co-Authored-By: Codex XHigh <noreply@anthropic.com> --------- Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: David Heinemeier Hansson <david@hey.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Omabot <omabot@omarchy.org> |
||
|
|
d3d9bea1ee |
Add a clock format with live seconds (#7586)
* Add a clock format with live seconds Right-clicking the clock now reaches "Thursday 09:39:23" and its AM/PM twin, and the widget's SystemClock ticks once a second only while a format that prints seconds is showing — every other format keeps the minute precision it had, so nobody pays for a repaint a second to read a label that changes once a minute. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Read an unterminated literal in a clock format as text Qt reads an opening quote with no closing one as a literal running to the end of the format, so "HH:mm 'sec" prints "09:39 sec" and never a second count — but the seconds test stripped only balanced quotes, saw the s, and put the widget on a per-second tick for a label that changes once a minute. The wiring assertions went the other way: each passed while the feature was broken, so hard-coding showsSeconds to false, dropping the label's onDateChanged, or commenting the precision line out and leaving the text behind all shipped green. Comments now come out of the source before it is matched, and both halves of the tick are asserted. Co-Authored-By: Codex XHigh <noreply@openai.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: Codex XHigh <noreply@openai.com> |
||
|
David Heinemeier Hansson
|
3451719ca5 | Reorder remove to match | ||
|
|
023021ad2d |
Add Remove > AI for the apps Install > AI offers (#7504)
* Add Remove > AI for the apps Install > AI offers Install > AI grew five entries and Remove grew one: Dictation, sitting on its own at the top level. Everything else installed from that menu had to come back out through Remove > Package by name. Mirror the install tree instead. Dictation moves under the new AI submenu where its installer already lives, and ChatGPT Desktop, Grok Bot, LM Studio, Ollama and T3 Code get removers beside it. Each entry is conditional on the thing actually being installed, so the submenu only ever lists what is there. What each remover deletes was read off a machine that had all five installed and launched, not guessed. That matters most for T3 Code, which bootstraps the agents it drives: ~/.claude.json, ~/.grok, ~/.npm and ~/.local/share/opencode all appear the first time it runs, and all of them outlive it, so it takes only ~/.config/t3code and ~/.t3. Grok Bot is the same trap in miniature -- ~/.grokbot is its own, ~/.grok belongs to the Grok CLI. Ollama drops every acceleration variant rather than the one the installer happened to pick, and disables the service before the package, since that is what holds the models open. 🤖 Generated by Opus 5 in Claude Code. * Remove only what these apps own, and only where removal works Three defects from an independent review of the previous commit. ChatGPT Desktop was deleting ~/.cache/codex-runtimes, which belongs to the Codex CLI rather than the desktop app: the `codex` binary resolves its runtime and plugins out of that directory, and it ships in a package this remover does not touch. Removing the desktop app took the CLI's prepared runtime with it, leaving a separate, still-installed tool to rebuild it -- and unable to, offline. Ollama's row appeared whenever the `ollama` command existed, but omarchy-pkg-drop removes exact package names. With ollama-bin, ollama-git or a hand-built binary the entry offered a removal it could not perform: the service went down, /var/lib/ollama and ~/.ollama were deleted, and it reported success with the program still installed. Every acceleration variant depends on the base package, so testing for that package covers each one the installer can produce and nothing it cannot remove. LM Studio keeps its models under a relocatable home, and ~/.lmstudio-home-pointer is the only record of where they went. The remover deleted the pointer and the default path, so a user who had moved their models kept every one of them while being told they were gone. Read the pointer before deleting it, and refuse one aimed at / or at the home directory itself, since following it there would take everything. Co-Authored-By: Codex XHigh <noreply@openai.com> --------- Co-authored-by: Codex XHigh <noreply@openai.com> |
||
|
OmarchybotandGitHub
|
260a729104 |
Add T3 Code to the AI install menu (#7496)
t3code-bin is in the Omarchy repo now, so the menu can offer it the way it offers Cursor and Grok Bot: install the package, then launch the desktop entry it ships.
The mark is a trace rather than a download. T3 publishes no monochrome SVG — the app icon is a black rounded tile with the letters knocked out of it, and a tile flattens to a solid square once the menu recolors every path with the theme foreground. Tracing the lettermark out of that icon keeps the silhouette that actually reads.
The font is package-owned, so the glyph reaches a desktop through an omarchy-settings release rather than omarchy update. Until that release lands, a pulled checkout draws the entry with no icon.
🤖 Generated by Opus 5 in Claude Code.
|
||
|
|
1e70cca144 |
Fall back to polkit when the DNS sudoers grant is missing (#7492)
grant_covers re-implemented etc/sudoers.d/omarchy-dns in bash -- one of the three providers, and %wheel -- but never asked whether the rule was installed. It ships in the etc/ tree that omarchy-settings copies, so every machine still on an older settings package answers yes to a grant it does not have. require_root then execs into sudo with no way back, and the panel's one-click toggle dies on a password prompt it has no terminal to show. Ask sudo instead. `sudo -l` alone reports whether a command is permitted, which the blanket %wheel rule answers yes to for everything, but the long listing prints the matched entry's tags -- !authenticate is the grant and nothing else. It runs nothing, and under -n it prompts for nothing, so a machine without the rule falls through to polkit and gets a prompt on screen. The provider list and the wheel check go away with it; sudo owns that policy now, and it stays right if the rule is ever edited or removed. Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
3765e8010b |
Switch DNS providers without a password prompt (#7472)
* Switch DNS providers without a password prompt The network panel and the menu run omarchy-dns from a process with no terminal, so require_root reached for pkexec and put a polkit password prompt in front of what is meant to be a one-click toggle. Grant %wheel passwordless sudo for the three stock providers and take that path whenever the grant covers the invocation. Custom stays out of the grant: it points the machine at servers the caller supplies, and it already runs in a terminal that can ask. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Pick the elevation path without asking sudo The `sudo -n -l` probe answered the wrong question. It reports whether a command is permitted, not whether it is passwordless, and the %wheel rule every Omarchy install ships permits everything -- `sudo -n -l /usr/bin/rm -rf /tmp/x` exits 0. So the probe passed for Custom too, and the exec below it ran `sudo -n`, which fails outright with no terminal and no way back to pkexec. Decide from what the sudoers rule actually says instead: sudo when there is a terminal to type into, or when the resolved path and the provider are both ones the rule names. Everything else keeps going through polkit. Pin a root-owned PATH once elevated, too. `omarchy dev link` puts a user-writable checkout ahead of sudo's secure_path for every command, so a passwordless grant on a script that resolves nmcli, tee, and install through PATH would otherwise hand root to whoever can write there. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Keep users outside %wheel on the polkit path The rule grants %wheel, so path and provider alone do not mean sudo will take it. A user outside the group was sent to sudo anyway, and with no terminal to answer the prompt that is a dead end -- polkit at least offers to authenticate as somebody else. Two holes in the test alongside it: it accepted any file containing the expected rule, so a second, argument-free line would have widened the grant unnoticed, and run as root it would have sailed past the stubs and rewritten the host's own DNS config. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Elevate the system install, whatever copy was invoked The rule names /usr/bin/omarchy-dns, so a dev-linked checkout handed sudo a path nothing could match and fell back to a polkit prompt. Re-exec the packaged path instead: the privileged half is the system install everywhere, the grant matches everywhere, and the path comparison and the PATH pinning that existed to work around the checkout both go away. Dev-linked checkouts run their own unprivileged half and the installed one as root, which is the trade for not carrying a second code path. --------- Co-authored-by: Omabot <david@hey.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
David Heinemeier HanssonandGitHub
|
2684c4b02e |
Print the OEM Windows product key from firmware (#7480)
* Print the OEM Windows product key from firmware Machines that shipped with Windows keep the OEM key in the ACPI MSDM table. `omarchy windows license key` reads it with strings, then cat. * Rename the firmware key command to omarchy-windows-key |
||
|
David Heinemeier HanssonandGitHub
|
238021cd67 |
Decode mixed UTF-16 clipboard text (#7466)
* Decode mixed UTF-16 clipboard text * Harden UTF-16 clipboard detection * Finish UTF-16 decoder hardening |
||
|
|
83987718cf |
Give the Quake console its own file, an agent, and half a screen (#7420)
* Open the scratchpad with the default agent already in it on_created_empty fires when the special workspace is created empty, so the agent starts the first time the console drops down instead of at boot, and comes back on the next open if you close it. The exec rule pins the workspace rather than trusting the spawn to inherit it: Hyprland only tags a process with its origin workspace while misc.initial_workspace_tracking is on, and we turn that off. Nothing to guard for a missing default agent. Omarchy picks none for you, and omarchy-agent exits without opening a window when none is set, so the scratchpad just opens empty until one is chosen. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Move the console into its own file and size it to half the screen The scratchpad's presentation was scattered through looknfeel: a dim in the decoration block, a workspace rule below it, two animation leaves further down again. Gathered into qconsole.lua, where the whole console is one readable thing. Sized to half the screen while it moved. A window rule cannot do that: its size expressions resolve once, when the window maps, so rescaling the monitor afterwards leaves a console that is no longer half of anything. Gaps are re-applied by the layout, so the console is sized by the gap left underneath it, recomputed from the monitor whenever the layout changes. Monitor dimensions come back in physical pixels while gaps are logical, so the scale comes out before the reserved area comes off. That arithmetic is the whole trick, and the test pins it at 1x, 2x and 1.5x. The test runs lua with an explicit "-". Bare `lua <<EOF` reads stdin as a REPL and exits 0 even after an error, which would leave its assertions unable to fail. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Only rewrite the console rule when its size actually changes Refitting replaces the rule in place rather than stacking a new one, so there was no leak, but each write still schedules a monitor and window state refresh and monitor.focused fires on every hop between screens. Remember what was last written and skip the write when the number has not moved. Also say out loud that the scale guard is what keeps the arithmetic below it safe: a monitor handle that has outlived its output answers nil to every field, and a layout change is exactly when that happens. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Drop the active window border inside the console The gradient border marks which window has focus, which the console does not need: it is only ever focused while it is open, and the dimmed workspace behind it already sets it apart. On a single agent terminal the highlight just reads as a frame around the panel. no_border on the workspace rule pins the border to 0 at workspace-rule priority, so it applies to whatever ends up in there without touching the global border. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Omabot <david@hey.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
0b5111702e |
Give scratchpad a Quake-style console presentation (#7409)
* Give scratchpad a Quake-style presentation
* Keep the Quake scratchpad from restyling every window
The presentation was bought with global decoration defaults: rounding went
0 -> 5 and both shadow and blur were switched back on for every window on
the system, undoing
|
||
|
David Heinemeier HanssonandGitHub
|
006460ad57 | Decode UTF-16 clipboard text (#7249) | ||
|
David Heinemeier HanssonandGitHub
|
1c1116b626 | Fix passwordless OWE Wi-Fi handling (#7238) | ||
|
Aditya GarudandGitHub
|
a3de80d647 | Keep shell tests inside their fixtures (#6763) | ||
|
|
dd9dee417f |
Launch claude and codex agents with auto-review instead of full bypass (#7001)
* Launch claude and codex agents with auto-review instead of full bypass Claude's auto permission mode and codex's --approve-for-me both run unattended without prompting, but keep automatic review (and codex's workspace-write sandbox) instead of skipping approval entirely. Grok stays on bypassPermissions. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Match the bash aliases to the agent launcher's auto-review modes Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
ff4e92e63b |
Fix Clone Plugin failing with "unknown clone option" (#6942)
omarchy-plugin-clone only takes the source id as the first argument, but the menu passed --edit ahead of it, so the id fell through to the unknown-option branch and every clone from Setup > Plugins failed. Closes #6913 Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |