## What happened

Starting `hyprsunset` for the first time from `omarchy-toggle-nightlight` (i.e. toggling night light before `hyprsunset` is already running) leaves the newly spawned daemon holding open the stdout/stderr file descriptors of whatever invoked the toggle. If the caller pipes or captures that output (as the OmaSettings shell plugin does, to bound output size with `| head -c 4MB`), the reader blocks forever waiting for EOF that never comes, because the long-running `hyprsunset` process never closes the inherited pipe.

In my case this happened through the OmaSettings Quickshell plugin (https://github.com/twiking/omasettings). Its settings window routes every change (theme, font, nightlight, etc.) through a single reused subprocess slot. Once that slot hung on the nightlight toggle, every later change I made in the window — including picking a new theme — was silently swallowed, because the window was still waiting on the stuck process and wouldn't start a new one. From the user's perspective, "changing the theme does nothing."

I confirmed the mechanism directly:

- The `omasettings` helper process (`bin/omasettings set nightlight true`) was still alive 10+ minutes after being invoked, blocked in `do_wait` on a `head -c 4194304` child, which was itself blocked in `anon_pipe_read`.
- `hyprsunset`'s fd 2 (stderr) pointed at the exact same pipe inode as the stuck `head` process's stderr — confirming `hyprsunset` inherited the pipe from `omarchy-toggle-nightlight` and kept it open indefinitely (it was started with `setsid uwsm-app -- hyprsunset &`, with no stdio redirection).
- Killing the stuck process immediately unblocked the settings window; roughly 25 queued clicks (theme picks, resets, state refreshes) that I'd made while it looked "frozen" all fired at once.

## Expected behavior

Toggling night light should not leave a long-running process holding open file descriptors that belong to the invoking shell/script. `omarchy-toggle-nightlight` should redirect `hyprsunset`'s stdio (e.g. `setsid uwsm-app -- hyprsunset >/dev/null 2>&1 &`) so the toggle script's own stdout/stderr close normally regardless of how long `hyprsunset` keeps running.

## Steps to reproduce

1. Reboot (or otherwise ensure `hyprsunset` is not already running: `pgrep -x hyprsunset` returns nothing).
2. Run night light toggle through anything that captures/pipes its output with a byte limit or `wait`s on it, e.g.:
   ```bash
   omarchy-toggle-nightlight | head -c 4194304
   ```
   (This is effectively what `omasettings`'s `bin/omasettings set nightlight true` does internally.)
3. Observe the command never returns, even though night light does get applied.
4. `ps -eo pid,ppid,stat,wchan,cmd` shows the `head` (or equivalent) process parked in `anon_pipe_read` indefinitely, and `hyprsunset`'s open fds include the same pipe inode as that stuck reader's stdout/stderr.

## System details

- Omarchy version: 4.0.3-1
- OS: Arch Linux, kernel 7.2.3-arch1-3
- CPU: Intel Core i7-6700HQ
- GPU: Intel HD Graphics 530 (iGPU) + NVIDIA GeForce GTX 950M (Optimus, dGPU idle/off)

## Additional context

This isn't specific to OmaSettings — any script or plugin that starts `hyprsunset` indirectly via `omarchy-toggle-nightlight` and captures its output the same way will hang the same way. OmaSettings just makes the effect very visible because it serializes all setting changes through one subprocess slot, so one stuck nightlight toggle blocks every other change (themes included) until it's killed manually.

Note: `omarchy debug --no-sudo --print` (the diagnostic command my usual bug-report process asks for) does not exist in this installed version (`omarchy commands --all` has no `debug` entry), so I could not attach that log.