## Summary

The panel/component tree re-instantiates and the previous handlers survive, producing the familiar duplicate-`IpcHandler` batch — **with no output loss involved at all**. After that single re-instantiation the menu IPC keeps answering `ok`, but the menu window never maps: `SUPER+SPACE` silently does nothing, and the bar stays visibly normal.

This is the same duplication mechanism described in #13072 and #13956, but neither of those paths is present here — nothing was disconnected, no monitor came or went, and the instance logged **zero** `There are no outputs - creating placeholder screen` / `FALLBACK` lines across its entire 8 h 52 m lifetime. So the recreation-without-destruction does not appear to be gated on the "no outputs" / placeholder-screen path.

Cross-links: #13072 (idle wake, duplicate IpcHandlers + leaked child processes), #13956 (KVM monitor disconnect/reconnect, `rescanPlugins` restores shortcuts), #13995 (overlapping quickshell generations — different mechanism, reported by me).

## Environment

- Framework Desktop, AMD Strix Halo, Omarchy
- `omarchy-dev 4.0.0.r6692.gc05d901-1`
- Quickshell 0.3.1 (Arch package)
- Hyprland 0.56.2 (commit `efb50993…`, aquamarine 0.15.1)
- Two permanent outputs: `DP-4` (LG ULTRAGEAR+) and a headless `Virtual-1` created via `hyprctl output create headless Virtual-1`
- Several third-party plugins installed under `~/.config/omarchy/plugins/`

## Symptom

`omarchy menu ping` → `ok`, exactly one `quickshell` process, bar and background surfaces present as normal — but pressing `SUPER+SPACE` does nothing. The functional tell:

```console
$ omarchy menu summon root
ok                                    # IPC accepted it
$ hyprctl layers | grep omarchy-menu
                                    # nothing: no overlay surface was ever created
```

No crash, no coredump (`coredumpctl list /usr/bin/quickshell` → nothing for this period), no extra engine generation. `omarchy restart shell` restores it immediately.

## Evidence

Instance started 14:08:28, healthy, logging exactly one batch of duplicate-handler warnings at startup (one registration per live screen — 19 lines with `DP-4` + `Virtual-1`, counting built-in and third-party panels together).

8 h 43 m later, with no output change, a second identical batch appeared in ~250 ms — built-in and third-party panels alike, i.e. the whole panel tree was re-instantiated, not one misbehaving plugin:

```
2026-10-04 22:51:10.310  WARN QQuickImage at /usr/share/omarchy/shell/plugins/agents/Panel.qml[1392:5]:
                         Cannot open: .../plugins/agents/assets/grok.svg
2026-10-04 22:51:10.310  WARN ShellIpc at /usr/share/omarchy/shell/plugins/agents/Panel.qml[794:3]:
                         Handler was registered but will not be used … target omarchy.agents
2026-10-04 22:51:10.320  WARN ShellIpc at .../panels/bluetooth/Panel.qml[640:3]: … omarchy.bluetooth
2026-10-04 22:51:10.331  WARN ShellIpc at .../panels/network/Panel.qml[210:3]: … omarchy.network
                         (monitor, power, weather, clock, indicators, elsewhen — same pattern)
2026-10-04 22:51:10.260  WARN IpcHandler at ~/.config/omarchy/plugins/ronald.input-sources/Panel.qml[115:3]
2026-10-04 22:51:10.266  WARN IpcHandler at ~/.config/omarchy/plugins/evo.webtheme/Panel.qml[208:3]
2026-10-04 22:51:10.408  WARN IpcHandler at ~/.config/omarchy/plugins/omaplug/BarWidget.qml[55:5]
2026-10-04 22:51:10.422  DEBUG qml: Panel.qml loaded, filterMode= 2 rows= 0
2026-10-04 22:51:12.622  DEBUG qml: marketplace entries: 4096
2026-10-04 22:51:16.596  DEBUG qml: updateCheckProcess onExited exitCode= 0
```

Warning count went 19 → 38 (2.0×). The menu died somewhere in that window. It happened twice that day, ~13:45 and ~22:51, both times immediately following a `Panel.qml loaded` + `marketplace entries: 4096` pair. The log identifies the re-instantiation but not its caller; `updateCheckProcess` finishing seconds before is correlation, not proof.

## Why a fixed warning threshold is the wrong detection rule

Worth flagging because it defeats log-based watchdogs (including my own, which slept through both events today): the healthy count is proportional to screen count plus installed plugins, so any absolute number calibrated on one monitor layout is wrong on another. Per-instance baseline is stable and self-calibrating — record the count once the instance is past its startup window, then treat *any further* duplicate-handler warning as evidence that a re-instantiation orphaned registrations. On this box that is `19 → anything > 19`, which catches both events; a `>= 40` threshold missed both at 38.

## Questions

1. Is `omarchy-shell shell rescanPlugins` the intended lighter recovery for this state (as reported in #13956)? I have only tested `omarchy restart shell`. If `rescanPlugins` remaps the menu window again, that is a much better thing for a watchdog to try before a full restart.
2. Is there a way to ask the shell directly whether a plugin/panel instance is still alive but unbacked — something cheaper than counting log lines?

## Also observed

`plugins/agents/Panel.qml:185` declares `{ providerId: "grok", providerName: "Grok" }`, but `plugins/agents/assets/` ships only `claude.svg`, `codex.svg`, `codex-light.svg`, `fireworks.svg` — no `grok.svg`. Every panel load logs one `Cannot open: …/assets/grok.svg` from `Panel.qml[1392:5]`. Unrelated to the dead menu, just noise on each reload.

---

*Filed with an AI assistant assembling these logs; the observations and commands above are from my own machine.*