## What happened

`omarchy restart shell` reported failure ("Omarchy shell did not become ready after restart.", exit 1) twice in a row, even though the shell actually did come back up successfully shortly after each attempt.

## Steps to reproduce

1. Have a bar with a non-trivial number of plugins configured (I have ~15 first- and third-party plugins in `~/.config/omarchy/plugins/` + `shell.json`).
2. Trigger `omarchy restart shell` (in my case it was triggered indirectly: a third-party plugin's QML froze the running `quickshell` process on hot-reload after `omarchy plugin add ... --enable`, so I ran `omarchy restart shell` to recover — but the readiness-check issue reproduces independently of that freeze).
3. Observe the command exit with:
   ```
   Omarchy shell did not become ready after restart.
   ```

## What's actually happening (from the journal, `journalctl --user -t omarchy-shell`)

The kill + relaunch itself works fine. The new `quickshell` process launches, loads its configuration, and becomes IPC-responsive — it just takes longer than the script's readiness-poll budget allows:

```
12:51:15 ... INFO: Exiting due to IPC request.                     # old instance killed
12:51:20 ... An instance of this configuration is already running. # relaunch raced the dying instance's lock cleanup
...
12:52:22 ... INFO: Launching config: "/usr/share/omarchy/shell/shell.qml"
12:52:23 ... INFO: Configuration Loaded
12:52:26 ... DEBUG qml: omarchy idle ... service-ready
```

Looking at `omarchy-restart-shell`'s source, the readiness poll is:

```bash
for (( attempt = 0; attempt < 20; attempt++ )); do
  if OMARCHY_PATH="$session_omarchy_path" OMARCHY_SHELL_IPC_TIMEOUT=0.5s omarchy-shell shell ping >/dev/null 2>&1; then
    ...
    exit 0
  fi
  sleep 0.1
done
echo "Omarchy shell did not become ready after restart." >&2
exit 1
```

That's a 2-second budget (20 attempts × 0.1s sleep, ignoring the ping's own timeout), plus each failed ping can itself burn up to `OMARCHY_SHELL_IPC_TIMEOUT` (0.5s) before the next attempt — so the effective window can be smaller than 2s of actual polling-free time. On this machine, with this plugin set, the shell reliably took several seconds (and once, due to the "already running" race above, closer to 15s across two attempts) to become ready — comfortably past that budget, causing a false failure report even though the restart succeeded moments later.

I also hit the "An instance of this configuration is already running" race once: the kill loop (`while timeout 5 quickshell kill -p "$CONFIG_DIR" --any-display; do :; done`) returned, but the just-killed instance apparently hadn't fully released its instance lock in `$XDG_RUNTIME_DIR/quickshell/` yet when the relaunch attempted to start, so the relaunch itself failed outright and had to be retried.

## Expected

`omarchy restart shell` should not report failure when the shell actually recovers successfully a few seconds later — either by widening the readiness-poll budget (especially for setups with many plugins, where first-load QML compilation legitimately takes longer), or by retrying the relaunch step itself when it fails with "instance already running" instead of just polling for readiness on a relaunch that never happened.

## System

- `omarchy version`: 4.0.1-1
- `uname -a`: Linux omarchy 7.1.9-arch1-2 #1 SMP PREEMPT_DYNAMIC Fri, 21 Aug 2026 22:18:59 +0000 x86_64 GNU/Linux
- CPU: Intel(R) Core(TM) i5-4258U CPU @ 2.40GHz
- GPU: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09)
- ~15 shell plugins configured (mix of first-party and third-party, several loaded from `~/.config/omarchy/plugins/`)

Note: `omarchy debug --no-sudo --print` (referenced in the docs I had on hand) doesn't exist as a command on this Omarchy version — `omarchy commands --all` has no `debug` group — so I've included the equivalent info gathered manually above instead.