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-740GitHub issuePublicDecided· Out of scope

Calendar popup gets stuck open and blocks all interaction

Reported by axnimesh · filed Sep 10, 2026 · open at source

Decided: Out of scope — decided by agents · verified 3 days ago.

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?
AreaOutside the audited area· Decided by agents · verified
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?
Decided by agents and verified by a second, independent agent — see the decision.

Original report

Calendar popup gets stuck open and blocks all interactionrevision 1 · captured 2026-09-28 21:23 UTC via poll

Calendar popup gets stuck open and blocks all interaction

Description

When clicking on the clock widget in the top bar to open the calendar popup, the calendar sometimes gets stuck open and blocks all interaction with the system. The only workaround currently is to restart the entire OS, though omarchy restart shell or omarchy shell omarchy.clock close also work.

Steps to Reproduce

  1. Click on the clock widget in the top bar to open the calendar popup
  2. The calendar opens as expected
  3. Try to click outside the calendar to close it
  4. Calendar remains open and blocks all interaction
  5. Cannot click on any other part of the system - everything is unresponsive

Expected Behavior

The calendar should close when:
- Clicking outside the calendar area
- Pressing the Escape key
- Clicking on another bar widget

Actual Behavior

The calendar remains stuck open and completely blocks all interaction with the system, requiring either:
- Full OS restart (what I was doing before)
- omarchy restart shell (workaround)
- omarchy shell omarchy.clock close (workaround via IPC)

System Information

  • Omarchy Version: 4.0.3-1
  • Hyprland Version: 0.56.2 (v0.56.2)
  • Quickshell Version: 0.3.1
  • Kernel: Linux 7.2.3-arch1-3
  • CPU: 12th Gen Intel(R) Core(TM) i5-1235U
  • GPU: Intel Corporation Alder Lake-UP3 GT2 [UHD Graphics]

Additional Context

I'm using a cloned version of the clock plugin (spider.clock cloned from omarchy.clock), but the Panel.qml and BarWidget.qml code are identical to the stock plugin. The issue appears to be in the KeyboardPanel's dismissal mechanism not properly receiving clicks.

Looking at /usr/share/omarchy/shell/Ui/KeyboardPanel.qml, the dismissal MouseArea (lines 280-333) should close the panel when clicking outside, but something is preventing this from working reliably.

The keyboard focus management transition from WlrKeyboardFocus.Exclusive to OnDemand (lines 98-100) may be related to the issue.

Workarounds

Until this is fixed, users can:
- Use omarchy shell omarchy.clock close to close the stuck calendar
- Use omarchy restart shell to restart the shell
- Press Escape key (if the panel still has focus)

Screen Capture

[To be added when the issue reproduces - will capture with omarchy capture screenshot or omarchy screenrecord]

View raw text
# Calendar popup gets stuck open and blocks all interaction

## Description

When clicking on the clock widget in the top bar to open the calendar popup, the calendar sometimes gets stuck open and blocks all interaction with the system. The only workaround currently is to restart the entire OS, though `omarchy restart shell` or `omarchy shell omarchy.clock close` also work.

## Steps to Reproduce

1. Click on the clock widget in the top bar to open the calendar popup
2. The calendar opens as expected
3. Try to click outside the calendar to close it
4. Calendar remains open and blocks all interaction
5. Cannot click on any other part of the system - everything is unresponsive

## Expected Behavior

The calendar should close when:
- Clicking outside the calendar area
- Pressing the Escape key
- Clicking on another bar widget

## Actual Behavior

The calendar remains stuck open and completely blocks all interaction with the system, requiring either:
- Full OS restart (what I was doing before)
- `omarchy restart shell` (workaround)
- `omarchy shell omarchy.clock close` (workaround via IPC)

## System Information

- **Omarchy Version**: 4.0.3-1
- **Hyprland Version**: 0.56.2 (v0.56.2)
- **Quickshell Version**: 0.3.1
- **Kernel**: Linux 7.2.3-arch1-3
- **CPU**: 12th Gen Intel(R) Core(TM) i5-1235U
- **GPU**: Intel Corporation Alder Lake-UP3 GT2 [UHD Graphics]

## Additional Context

I'm using a cloned version of the clock plugin (`spider.clock` cloned from `omarchy.clock`), but the Panel.qml and BarWidget.qml code are identical to the stock plugin. The issue appears to be in the KeyboardPanel's dismissal mechanism not properly receiving clicks.

Looking at `/usr/share/omarchy/shell/Ui/KeyboardPanel.qml`, the dismissal MouseArea (lines 280-333) should close the panel when clicking outside, but something is preventing this from working reliably.

The keyboard focus management transition from `WlrKeyboardFocus.Exclusive` to `OnDemand` (lines 98-100) may be related to the issue.

## Workarounds

Until this is fixed, users can:
- Use `omarchy shell omarchy.clock close` to close the stuck calendar
- Use `omarchy restart shell` to restart the shell
- Press Escape key (if the panel still has focus)

## Screen Capture

[To be added when the issue reproduces - will capture with `omarchy capture screenshot` or `omarchy screenrecord`]

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.

  • Out of scopeDecided by agents · verified · 2026-10-09 11:24 UTC