Omahub
← All plugins
L

Relaunch

by Layton F

Save your current app-to-workspace layout, then relaunch those apps into the right workspaces after a reboot or crash.

Security review

Review recommended · 10 findings

Deterministic scan — not a security guarantee

Low
Risk level
Low
Analyzed commit
457f976
Scanned
3 weeks ago
  • Augments a command with octal/hex escape sequences.

    \0herdr\0' >"$RELAUNCH_CMDLINE_DIR/91"
  • Augments a command with octal/hex escape sequences.

    \0herdr\0' >"$RELAUNCH_CMDLINE_DIR/4242"
  • Augments a command with octal/hex escape sequences.

    \0btop\0' >"$RELAUNCH_CMDLINE_DIR/4244"
  • Augments a command with octal/hex escape sequences.

    \0value\0' >"$RELAUNCH_CMDLINE_DIR/4300"
  • Augments a command with octal/hex escape sequences.

    \0dua i /\0' >"$RELAUNCH_CMDLINE_DIR/4400"
  • Augments a command with octal/hex escape sequences.

    \0dua i /\0' >"$RELAUNCH_CMDLINE_DIR/700"
  • Augments a command with octal/hex escape sequences.

    \0herdr\0' >"$RELAUNCH_CMDLINE_DIR/701"
  • Augments a command with octal/hex escape sequences.

    \0htop\0' >"$RELAUNCH_CMDLINE_DIR/1200"
  • Docs external_hosts README.md:45

    Downloads or connects to an external HTTP(S) host.

    git clone https://github.com/farmall856/omarchy-relaunch.git
  • Command runs with sudo, elevating the process beyond the plugin environment.

    sudo amd-s2idle test` as a Relaunch test.

Automated analysis only — not a security guarantee.

AI advisory review

No obvious issues detected

Language-model assessment · ~deepseek/deepseek-v4-flash-latest — advisory only

Low
AI risk level
Low
Recommendation
install
Model
~deepseek/deepseek-v4-flash-latest
Analyzed commit
457f976
Reviewed
3 weeks ago

The plugin is a legitimate workspace-restoration tool with no malicious behavior. The deterministic scan's findings are either documentation-only (README clone command, sudo in a test plan) or test fixtures using octal escapes to simulate command-line arguments, not obfuscation. The engine runs as the user, writes only to its own config directory, and provides a clean uninstall path.

  • The `install.sh` script copies the engine to `~/.local/bin` and modifies `hyprland.lua` to add a dofile line, which is a system-level change but clearly documented and user-initiated.
  • The engine executes launch commands via `bash -c` from user-editable config, which is a potential injection vector if the user's config is compromised, but this is inherent to the plugin's purpose and not hidden.
  • The `relaunch` script reads `/proc` and runs `hyprctl` commands, but all operations are user-level and non-destructive.
How this check works

This review combines the deterministic scan (the rule-based results above) with an independent look at the plugin's code by a language model. The model reads a trimmed sample of the repository's files, the manifest, and the README, then gives a plain-language risk level and a recommendation: install (no notable danger), review (look closer first), or avoid (clearly dangerous).

It runs on the same analyzed commit as the deterministic scan and is strictly advisory — it is not a security guarantee and never blocks a plugin by itself. A human moderator still reviews plugins before they are listed.

AI advisory only — automated analysis, not a security guarantee.

Install
$ omarchy plugin add https://github.com/farmall856/omarchy-relaunch --enable
Widgets #Hyprland #bar #workspaces

Relaunch

An Omarchy Quattro bar widget that saves your current app-to-workspace layout, then relaunches those apps into the same workspaces after a reboot or crash. Each app restores its own context; this makes sure it comes back up in the right place.

Click the bar icon → Save Current Workspaces. That's it. On the next boot, herdr is back on workspace 1, Brave on 2, your terminal on 6 — wherever you had them.

How it works

No daemon. Nothing runs in the background unless you opt in to the session snapshot below. When you save, the widget inventories running windows (hyprctl clients -j) and records one class → workspace mapping per app. The boot hook and the workspace pins live in two files Relaunch owns: ~/.config/omarchy-relaunch/relaunch.lua registers the hook, and rules.lua holds the generated o.window pins. Both are reached through one guarded line in hyprland.lua. Relaunch never writes your autostart.lua — it reads it, to show you what already starts at login, and that is all. Because the pins are declarative config rather than live state, they survive a crash for free.

  • Bar widget (BarWidget.qml / Panel.qml): Save, list edits, and boot policy, grouped into bordered sections. The last-boot log is a second plugin kind — a fullscreen overlay (Overlay.qml), not the cramped bar popover.
  • Engine (relaunch, a bash + jq script): inventories windows and existing Hyprland startup apps, writes the Lua pins, and runs relaunch boot. The widget invokes the copy in the plugin folder.

Install

Via Omarchy (recommended):

omarchy plugin add https://github.com/farmall856/omarchy-relaunch.git --enable

That clone is enough. Opening the widget (or just loading the bar) runs the engine from the plugin folder and installs the owned loader plus the one relaunch.lua source line in hyprland.lua. Optionally also:

git clone https://github.com/farmall856/omarchy-relaunch.git
cd omarchy-relaunch
./install.sh

install.sh copies relaunch into ~/.local/bin, installs the plugin folder, and wires the same hooks.

Dependencies

  • bash and jq — both ship with Omarchy Quattro. No compiler.
  • Hyprland / Omarchy Quattro — the runtime.
  • A Nerd Font in the bar (Omarchy default) for the widget glyph.

The engine runs hyprctl. No elevated privileges; everything runs as your user, like any Hyprland command.

Usage

  1. Arrange your apps across workspaces the way you want them on boot.
  2. Click the Relaunch icon in the bar.
  3. Save Current Workspaces — captures the layout and writes the pins. The status line reports how many entries were added and updated.

The panel is titled relaunch, with a ? icon opposite it on the same line that opens this README on GitHub. Below the save button the panel is bordered boxes, each with its title sitting on the top border rather than inside it. Every icon names itself on hover.

Workspace boxes

Under a Relaunch list (N) heading — or No apps on the relaunch list yet — comes one box per workspace, titled Workspace 1, Workspace 2, and so on, holding the apps pinned to that workspace. Each app is a single line: its name, then two icons.

  • Rocket — show the launch command. It opens an editable field with a Save button, so the same icon both views and edits it. Esc closes the field.
  • Trash can — remove that app from the relaunch list.

An app whose launch command cannot be found is drawn in the urgent colour and opens its editor by itself, since there is nothing else on a one-line row to fix it with. Type the command that starts it and press Save.

WINDOWS NOT IN RELAUNCH

Windows open right now that the relaunch list does not cover, one line each, each with the workspace it is on. Nothing in this box starts at login: close the window and its line goes with it.

  • + — add that window to the relaunch list, on the workspace it is already on.

The box is hidden when every open window is already on the list.

STARTUP APPS

Hyprland startup apps — the entries in your autostart.lua. These do start when you log in, which is why they are kept apart from the windows above.

The list is read-only, and the rows have no buttons. Relaunch makes your app windows reappear in their workspaces after a reboot or a crash; it is not an autostart manager, and it never writes autostart.lua. The box is here so that when something you did not expect turns up at login, you can see where it came from — then edit autostart.lua yourself, or use whatever put it there.

An app that is on both lists appears on both. The box is hidden when your autostart.lua has no entries.

RELAUNCH ON BOOT

Boot policy and the last-boot report, in one box.

  • Skip next boot — one-shot; the next relaunch boot does nothing, then clears itself. The chip becomes Enable on boot until then.
  • Disable until re-enabled — stays off across reboots until you enable it.
  • View last boot log — opens a fullscreen overlay with the last relaunch boot diagnostic: what launched, and where it landed. The line above it summarises the last boot at a glance.

Remove Relaunch permanently

Centred on its own at the very bottom of the panel, in no section. Two-click confirm; removes the hooks, the config, and the plugin folder.

Session snapshot (manual, diagnostic)

Answers "what did I have before, and what actually came back?" Nothing else reads it, and no part of save, restore or boot depends on it.

relaunch snapshot              # capture the layout right now
relaunch last-session --diff   # compare that snapshot with the last boot

Capture is always something you ask for. Relaunch does not sample your windows on a timer or at shutdown, and there is no background service — an earlier pre-shutdown hook was removed because it recorded window titles on a schedule you could not see or control. Everything Relaunch keeps on disk is visible and editable in the panel.

Configure

Fine-tune by editing ~/.config/omarchy-relaunch/config.json:

{
  "staggerSeconds": 0,
  "skipOnce": false,
  "entries": [
    { "class": "herdr",         "workspace": 1, "exec": "xdg-terminal-exec --app-id=herdr -e herdr", "enabled": true },
    { "class": "brave-browser", "workspace": 2, "exec": "brave",                                 "enabled": true },
    { "class": "foot",          "workspace": 6, "exec": "foot",                                  "enabled": true }
  ]
}
  • class matches a window's initialClass (stable across an app's post-launch class changes — Brave/Electron do this).
  • exec overrides the guessed launch command; leave blank to use the guess.
  • enabled keeps an entry on file but out of the generated pins and boot list.
  • float is captured from the live window and refreshed on every save: true pins the app floating, false pins it tiled. Omitting it entirely leaves float alone, which lets Omarchy's own rules decide.
  • skipOnce is set by Skip next boot. Save keeps it; relaunch boot consumes it.
  • staggerSeconds waits N seconds between launches if apps race the pins.

After a manual edit, run relaunch generate (or Save again from the panel).

Runtime files (not in git):

  • ~/.config/omarchy-relaunch/config.json — entries and boot-skip state
  • ~/.config/omarchy-relaunch/overrides.json — class → exec exceptions you set
  • ~/.config/omarchy-relaunch/relaunch.lua — owned loader; registers the boot hook
  • ~/.config/omarchy-relaunch/rules.lua — generated o.window pins
  • ~/.config/omarchy-relaunch/disabled / skip-once — boot flags
  • ~/.config/omarchy-relaunch/last-boot.log / last-boot.json — last relaunch boot diagnostic
  • ~/.config/omarchy-relaunch/last-session.json — window snapshot, written only when you run relaunch snapshot

Remove

From the panel: Remove Relaunch permanently (click twice). That removes the hyprland.lua source line, ~/.config/omarchy-relaunch/ (loader, rules and all state), and the plugin folder. Your autostart.lua is not touched, because Relaunch never wrote to it.

Complete removal is the one thing Relaunch promises unconditionally: every file it writes is removable, and after an uninstall Hyprland is left as it was found.

Or from a terminal:

relaunch uninstall --yes
# or, if you only want the plugin checkout gone:
omarchy plugin remove io.github.laytonf.relaunch --yes

omarchy plugin remove does not unwind the Hyprland hooks or config dir; use the panel action or relaunch uninstall --yes for a full teardown.

Limits

One workspace per app

Relaunch keeps one entry per window class, and the rule it generates is a standing Hyprland rule, not a one-shot placement at boot:

o.window({ class = "^(brave-browser)$" }, { workspace = "2 silent" })

That rule has no expiry. It applies to every window of that class, for the whole session — not just the ones relaunch boot starts. Verified on the development machine: with Brave pinned to workspace 2, launching Brave from workspace 7 opened it on workspace 2. The same happens with foot.

So two windows of one app on two different workspaces can be neither restored nor kept:

  • Save records only the first one seen (the lowest workspace).
  • Even if both were recorded, the standing rule would pull both to the same workspace as soon as they opened.

This is the ceiling of the approach, not a bug to be filed. Hyprland window rules match on class, not on a particular window instance, so there is nothing to attach a second, different placement to. Terminals are the usual way to hit this: every plain foot window shares the class foot. A terminal hosting a command is a way out, because it gets its own class — foot -e herdr is captured as class herdr, separate from plain foot, and can hold its own workspace.

Apps that restore themselves

Some applications reopen their own windows at startup, independently of Relaunch. Browsers are the common case: after an unclean shutdown — which a reboot usually is — Brave restores its previous session, and that includes any web app or PWA window it had open. Relaunch launches the same web app from its saved entry, and you end up with two.

Relaunch cannot see this coming. At the moment relaunch boot runs, the browser has not restored anything yet, so there is no window to detect and no way to tell "this app will bring itself back" from "this app needs launching". Waiting and then closing the extra window is not an option either: Relaunch must never close a window it did not open.

The fix is to stop launching that app through Relaunch — remove the entry and let the application restore itself, which it was going to do anyway. Everything else on the list is unaffected.

Web apps are the sharpest version of this, because the browser remembers them individually. A PWA that a browser restores on its own is better left off the list entirely.

Multiple monitors

Relaunch restores apps to workspace numbers, not to screens. Which monitor a given workspace lives on is Hyprland's business, and Relaunch does not express an opinion about it.

Omarchy ships no workspace→monitor binding at all — only keybindings to move a workspace to another monitor by hand (SUPER + SHIFT + ALT + arrow, see default/hypr/bindings/tiling.lua). So:

  • With your own workspace→monitor rules, restore follows them: your apps land on the workspaces they were saved on, and those workspaces land on the screens you assigned.
  • Without them, workspace placement across screens is whatever Hyprland decides at the time. Your apps still come back on the right workspace numbers, but which physical screen shows them is not guaranteed to match what you had.

Only single-monitor use has actually been verified. Multi-monitor should follow from the above, but it is untested — treat it as such.

Notes

  • Launch commands: terminal wrap, then overrides.json (your exceptions; starts empty), then gio launch of the matching .desktop (your ~/.local/share/applications first, then the system dirs), then the process command line, then a lowercased class. The panel flags unverified guesses and lets you type a command when the binary is missing.
  • A terminal hosting another command (foot -e cmd, omarchy-launch-terminal cmd) is identified by that command and relaunched with xdg-terminal-exec --app-id=<cmd> -e <cmd...> so Hyprland gets a distinct class. Argument boundaries are preserved, so bash -c 'dua i /' survives the round trip.
  • Terminals relaunch empty; lean on the app's own restore (tmux, herdr, etc.) for in-terminal context.

License

MIT. See LICENSE.