### System details

- **Omarchy:** 3.8.4
- **Kernel:** 7.1.4-arch1-1
- **Hyprland:** 0.56.0
- **supergfxctl:** 5.2.7-2 (freshly installed by the toggle itself)
- **NVIDIA:** nvidia-open-dkms 610.43.03
- **Laptop:** ASUS TUF Gaming FX505GT
- **iGPU:** Intel UHD Graphics 630 `[8086:3e9b]` · **dGPU:** GTX 1650 Mobile `[10de:1f91]`

### What's wrong?

Running **Hardware → Hybrid GPU** on a machine that doesn't yet have `supergfxctl` installed hangs forever. The setup portion completes fine, then the script blocks at the mode query and never returns — no prompt, no timeout, no error. The Omarchy terminal just sits there indefinitely until you kill the process from another shell.

In `bin/omarchy-toggle-hybrid-gpu` (3.8.4, line 25):

```bash
if omarchy-cmd-missing supergfxctl; then
  omarchy-pkg-add supergfxctl
  sudo tee /etc/supergfxd.conf >/dev/null <<'CONF'
  ...
CONF
  sudo systemctl enable --now supergfxd     # completes
fi

gpu_mode=$(supergfxctl -g)                  # ← blocks here, forever
```

### Reproduction

1. Hybrid-GPU laptop **without** `supergfxctl` installed.
2. Hardware → Hybrid GPU.
3. Enter sudo password, accept the `supergfxctl` install.
4. Package installs, `/etc/supergfxd.conf` is written, `supergfxd` is enabled and started — then the terminal hangs with no further output. The expected `gum confirm` prompt never appears.

### Evidence

The client sat wedged for 3m36s until I killed it:

```
$ ps -o pid,etime,stat,wchan:25,cmd -p 15586,16399
    PID     ELAPSED STAT WCHAN                     CMD
  15586       03:47 S+   anon_pipe_read            /bin/bash .../omarchy-toggle-hybrid-gpu
  16399       03:36 S+   do_epoll_wait             supergfxctl -g
```

Meanwhile the daemon was perfectly healthy and answered a **new** client instantly:

```
$ systemctl is-active supergfxd
active
$ timeout 8 supergfxctl -g
Hybrid          # returns immediately, exit 0
$ timeout 8 supergfxctl -s
[Integrated, Hybrid, Vfio]
```

The daemon's log hints that the wedged request was never processed, though this is circumstantial. In my session each served query appeared to coincide with a `nvidia-drm.modeset not set, ignoring` line, and there is nothing at all between the end of the startup sequence and my first successful query 2m9s later — despite the wedged client having connected during that window:

```
21:59:58 supergfxd: [INFO supergfxctl::controller] reload: Reloaded gfx mode: Hybrid   ← startup done
                                                                                        ← wedged `supergfxctl -g` here, never logged
22:02:07 supergfxd: [INFO supergfxctl] nvidia-drm.modeset not set, ignoring             ← my first successful query
22:03:20 supergfxd: [INFO supergfxctl] nvidia-drm.modeset not set, ignoring             ← subsequent queries
```

Nothing is left half-applied — the hang is *after* all the setup, and both `case` branches (which are the only things that change mode) never run. State afterwards was correct: `mode: Hybrid` in `/etc/supergfxd.conf`, `supergfxd` enabled+active, `supergfxctl -g` → `Hybrid`. So the impact is purely a stuck terminal on first run, not a broken configuration.

### Notes on cause

I could **not** confirm a root cause, and I can't reproduce it anymore now that `supergfxctl` is installed — so treat this as an observation report.

One thing I can rule out: the obvious "service isn't on the bus yet" race. `supergfxd.service` is `Type=dbus` with `BusName=org.supergfxctl.Daemon`, so `systemctl enable --now` shouldn't return until the name is acquired.

This code path has already been patched twice for adjacent first-run problems, which is why I think it's worth reporting even without a root cause:

```
7015601d  No need to start on the first install
ae8b9b74  Have to start it right away
ccc88a01  Ensure config is available so starting the service immediately will work
```

The in-script comment from `ccc88a01` — *"Create config before starting service to prevent hang on first boot"* — describes this same class of hang, so the existing mitigation appears incomplete.

### Suggested fix

Regardless of the underlying cause, the query shouldn't be able to block forever. Bounding it turns an indefinite hang into a clear error, and a short retry loop would likely paper over the race entirely:

```bash
gpu_mode=""
for _ in {1..10}; do
  gpu_mode=$(timeout 3 supergfxctl -g) && [[ -n $gpu_mode ]] && break
  sleep 1
done

if [[ -z $gpu_mode ]]; then
  echo "supergfxd is not responding. Try again, or check: systemctl status supergfxd"
  exit 1
fi
```

A cheaper variant: since the script has just written `mode: Hybrid` into `/etc/supergfxd.conf` in the first-install branch, it could skip the query entirely on that path and go straight to the known mode.