Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.

Inbox
ReportR-3640GitHub issuePublicReceived

Walker clipboard preview persists when switching to system menu (UI overlap bug)

Reported by russell-davis · filed Nov 4, 2025Closed upstream on 2025-11-05 by dhh. GitHub close reason: completed. No closing PR or commit is recorded — "completed" alone is not evidence of a fix.

Received and recorded verbatim. Nothing has been checked yet.

At a glance

1 · What is claimed?
Only the report text below — no validator has restated it as checkable claims yet.
2 · What does it affect?
Not yet mapped to any requirement or component.
3 · Is it reproducible?
No validation has been run yet.
4 · What remains unclear?
  • Not validated yet: no claims, no reproducer.
5 · What happens next?
Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.

Original report

Walker clipboard preview persists when switching to system menu (UI overlap bug)revision 1 · captured 2026-10-04 11:42 UTC via poll

System details

Omarchy 3.1.5 (master), Kernel 6.17.6-arch1-1, Hyprland 0.51.1, alacritty 0.16.1, 1060 packages, Dell XPS 15 7590, i9-9980HK @ 5GHz, GTX 1650 Mobile + Intel UHD 630

What's wrong?

When opening the Walker clipboard manager (Super+Ctrl+V) and then subsequently opening the system menu (Super+Esc), the clipboard item preview panel remains visible on the right side while the system menu items replace the clipboard list on the left. This creates a confusing UI state where two different menus are partially displayed simultaneously.

Steps to Reproduce

  1. Press Super + Ctrl + V to open the clipboard manager in Walker
  • The clipboard manager displays: list of clipboard items on the left, preview of selected item on the right

<img width="3840" height="2160" alt="Image" src="https://github.com/user-attachments/assets/8f3a8b3c-19fa-4358-abef-18dec3a122ee" />

  1. Without closing the clipboard manager, press Super + Esc to open the system menu

<img width="3840" height="2160" alt="Image" src="https://github.com/user-attachments/assets/2637b5e7-40a0-4b2e-a011-e7e6fe455a91" />

  1. Bug occurs: - The system menu list (Lock, Screensaver, Suspend, Restart, Shutdown) replaces the clipboard list on the left
  • The clipboard preview from the previous menu remains visible on the right
  • This creates a mixed UI state with elements from two different menus displayed simultaneously

Expected Behavior

When switching from the clipboard manager to the system menu (or any other Walker menu), the entire previous menu (including both the list and the preview panel) should be dismissed before showing the new menu.

Actual Behavior

The system menu items appear on the left side, but the clipboard item preview from the previous menu persists on the right side, creating a visually confusing hybrid state.

Environment

  • Omarchy Version: v3.1.5 (commit 7f9ee95)
  • Hardware: Dell XPS 15 7590
  • CPU: Intel i9-9980HK (8-core/16-thread @ 2.40GHz base, 5.00GHz turbo)
  • RAM: 31GB
  • Display: 4K (3840x2160)
  • Desktop: Hyprland 0.51.0 (Wayland compositor)

Workaround

The fix that has worked for me is a single line, walker --close addition to the menu() function in ~/.local/share/omarchy/bin/omarchy-menu that closes any existing Walker instance before launching a new dmenu.

menu() {
  local prompt="$1"
  local options="$2"
  local extra="$3"
  local preselect="$4"

  read -r -a args <<<"$extra"

  if [[ -n "$preselect" ]]; then
    local index
    index=$(echo -e "$options" | grep -nxF "$preselect" | cut -d: -f1)
    if [[ -n "$index" ]]; then
      args+=("-c" "$index")
    fi
  fi

  ############## WALKER WORKAROUND ##############
  # Close any existing walker instance to prevent UI overlap
  walker --close 2>/dev/null
  ##################################################

  echo -e "$options" | omarchy-launch-walker --dmenu --width 295 --minheight 1 --maxheight 600 -p "$prompt…" "${args[@]}" 2>/dev/null
}

After making this change, the menu switching works correctly - the clipboard preview no longer persists when opening other menus.

View raw text
### System details

Omarchy 3.1.5 (master), Kernel 6.17.6-arch1-1, Hyprland 0.51.1, alacritty 0.16.1, 1060 packages, Dell XPS 15 7590, i9-9980HK @ 5GHz, GTX 1650 Mobile + Intel UHD 630

### What's wrong?

When opening the Walker clipboard manager (`Super+Ctrl+V`) and then subsequently opening the system menu (`Super+Esc`), the clipboard item preview panel remains visible on the right side while the system menu items replace the clipboard list on the left. This creates a confusing UI state where two different menus are partially displayed simultaneously.

## Steps to Reproduce

1. Press `Super + Ctrl + V` to open the clipboard manager in Walker
   - The clipboard manager displays: **list of clipboard items on the left**, **preview of selected item on the right**

<img width="3840" height="2160" alt="Image" src="https://github.com/user-attachments/assets/8f3a8b3c-19fa-4358-abef-18dec3a122ee" />

2. Without closing the clipboard manager, press `Super + Esc` to open the system menu

<img width="3840" height="2160" alt="Image" src="https://github.com/user-attachments/assets/2637b5e7-40a0-4b2e-a011-e7e6fe455a91" />

3. **Bug occurs**:   - The system menu list (Lock, Screensaver, Suspend, Restart, Shutdown) replaces the clipboard list on the left
   - The clipboard preview from the previous menu **remains visible on the right**
   - This creates a mixed UI state with elements from two different menus displayed simultaneously

## Expected Behavior

When switching from the clipboard manager to the system menu (or any other Walker menu), the **entire previous menu** (including both the list and the preview panel) should be dismissed before showing the new menu.

## Actual Behavior

The system menu items appear on the left side, but the clipboard item preview from the previous menu persists on the right side, creating a visually confusing hybrid state.

## Environment

- **Omarchy Version**: v3.1.5 (commit `7f9ee95`)
- **Hardware**: Dell XPS 15 7590
- **CPU**: Intel i9-9980HK (8-core/16-thread @ 2.40GHz base, 5.00GHz turbo)
- **RAM**: 31GB
- **Display**: 4K (3840x2160)
- **Desktop**: Hyprland 0.51.0 (Wayland compositor)

## Workaround

The fix that has worked for me is a single line, `walker --close` addition to the `menu()` function in `~/.local/share/omarchy/bin/omarchy-menu` that closes any existing Walker instance before launching a new dmenu.

```bash
menu() {
  local prompt="$1"
  local options="$2"
  local extra="$3"
  local preselect="$4"

  read -r -a args <<<"$extra"

  if [[ -n "$preselect" ]]; then
    local index
    index=$(echo -e "$options" | grep -nxF "$preselect" | cut -d: -f1)
    if [[ -n "$index" ]]; then
      args+=("-c" "$index")
    fi
  fi

  ############## WALKER WORKAROUND ##############
  # Close any existing walker instance to prevent UI overlap
  walker --close 2>/dev/null
  ##################################################

  echo -e "$options" | omarchy-launch-walker --dmenu --width 295 --minheight 1 --maxheight 600 -p "$prompt…" "${args[@]}" 2>/dev/null
}
```

After making this change, the menu switching works correctly - the clipboard preview no longer persists when opening other menus.
  • 8f3a8b3c-19fa-4358-abef-18dec3a122ee
  • 2637b5e7-40a0-4b2e-a011-e7e6fe455a91

Validation

Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.

Linked

Not linked to any known issue, other report or change yet.

Decision

Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.

No decision has been recorded yet.