## What happened

`omarchy-channel-set edge` from the Omarchy menu finished without ever offering to reboot, even though the switch replaced both the running kernel and Hyprland. The last two lines of the run were:

```
Linux kernel has been updated. Reboot? Run omarchy-system-reboot when ready.
Hyprland has been updated. Reboot? Run omarchy-system-reboot when ready.
```

That is the fallback text, not the prompt. There was no `Reboot now? / Later` choice, so the only way to reboot was to know the command name and type it.

## Cause

`bin/omarchy-channel-set` ends by handing off to an unattended update:

```bash
OMARCHY_UPDATE_USER_PATH="$user_path" "$OMARCHY_PATH/bin/omarchy-update" -y
```

`-y` sets `OMARCHY_UPDATE_UNATTENDED=1` (`omarchy-update:103`). `confirm_reboot` in `bin/omarchy-update-restart` keys off exactly that variable and skips the prompt:

```bash
confirm_reboot() {
  if [[ ${OMARCHY_UPDATE_UNATTENDED:-0} == "1" ]]; then
    echo "$1 Run omarchy-system-reboot when ready."
  elif gum confirm "$1"; then
    omarchy-system-reboot
    exit 0
  fi
}
```

So `OMARCHY_UPDATE_UNATTENDED` silences the reboot offer, and the channel switch sets it unconditionally on its last line.

## This is not an unattended environment

The channel switch is launched into a real terminal:

```
"update.channel.edge": {..., "action":"omarchy-launch-floating-terminal-with-presentation 'omarchy-channel-set edge'"}
```

A human is watching and can answer `gum`. The same run proves it — `omarchy-update-orphan-pkgs:21` asked `gum confirm "Remove 1 orphaned package(s)?"` a few lines earlier, and it was answered normally:

```
Orphan system packages
  hyprwayland-scanner

Removing orphan system packages
[sudo] password for mihai:
...
:: Do you want to remove these packages? [Y/n]
```

So a `gum` prompt rendered and was answered in that exact session. The reboot offer was the only prompt that did not appear, and `-y` is the only reason.

Worth noting the inconsistency this creates: `-y` is not honoured by `omarchy-update-orphan-pkgs` (that's #13356), so the run asked one question it was supposed to skip and skipped the one it should have asked.

## Expected

A channel switch is interactive and often needs a reboot — it swaps the kernel, and for `dev` it also relinks the checkout. It should offer the reboot choice.

`omarchy-channel-set` also already has a working precedent for this. For the two cases where it cannot rely on the kernel/Hyprland detection, it sets a marker instead:

```bash
omarchy-state set reboot-required
```

at `:130` (switching to `dev`) and `:145` (leaving `dev`). Those set the same `$HOME/.local/state/omarchy/reboot-required` file `omarchy-update-restart:39` checks. That path is also gated behind `confirm_reboot`, so it is silenced by `-y` too — but the mechanism exists and is already trusted by this script.

## Suggested fix

Separate "skip the update confirmation" from "unattended". They are not the same thing, and `-y` currently means both:

- **The confirmation at `omarchy-update:63`** ("Ready to update? You cannot stop the update once you start!"). Skipping this during a channel switch is reasonable — the user already chose the channel deliberately in the menu, and re-asking what they just asked for is noise.
- **The reboot offer.** Not reasonable to skip, for the reasons above.

A flag that skips only the first, leaving `OMARCHY_UPDATE_UNATTENDED` unset, would restore the offer without changing `omarchy update -y` semantics for the automation and agent callers that rely on it. It also would not regress #8986 or #13356, which are about `-y` blocking on prompts that should be suppressed.

An alternative is for `omarchy-channel-set` to present the reboot choice itself after the hand-off returns, using the same `omarchy-state set reboot-required` + `gum confirm` pattern it already uses for the `dev` cases. That keeps `-y` as it is and confines the change to one file, but duplicates the reboot logic and loses the kernel/Hyprland detection that `omarchy-update-restart` already has.

## System details

```
Omarchy        4.0.0.r2304.g7b336b1-1 (omarchy-dev, edge)
OMARCHY_PATH   /usr/share/omarchy
channel        stable -> edge, launched from the Omarchy menu
kernel         7.2.5-3-omarchy running, 7.2.5-4 installed by this switch
Hyprland       0.56.2-2 running, 0.56.2-3 installed by this switch
CPU            Intel Core i7-10750H (CometLake-H)
GPU            Intel UHD (GT2) + NVIDIA GTX 1650 Ti (hybrid)
date           2026-09-27
```

I checked `bin/omarchy-channel-set` and `bin/omarchy-update-restart` on master; both still behave this way.