### System details

Ryzen 5600x with nvidia 3060 12gb with 32gb or ram 

### What's wrong?

I am still experiencing the intermittent top-bar mouse-input issue described in #10030.

The bar and widgets remain visually normal, but when the issue occurs, the effective mouse click area appears to be displaced from the visible widget position. In practice, I sometimes have to move the pointer all the way toward the top edge / a specific shifted position for the widget click to register.

Affected widgets include:

- Dropbox
- Tailscale
- Agents
- Audio

The rest of the desktop continues to receive mouse input normally.

Restarting the Omarchy shell restores normal behaviour. Changing the bar position also restores normal behaviour.

I captured a screen recording while the issue was occurring and attached it to this report.

---

## System

- Omarchy: 4.0.2-1
- Hyprland: 0.56.2
- NVIDIA RTX 3060
- Display: HDMI-A-2, 1920x1080 @ 144 Hz
- Single monitor/output
- Wayland

---

## Diagnostics performed while the issue was occurring

I followed the diagnostics requested during the investigation.

### 1. Bar geometry

I ran:

```bash
omarchy-shell shell debugBarGeometry | jq 'sort_by(.section, .x)'

The affected widgets reported normal geometry:

omarchy.dropbox   x=1750  y=0  width=27 height=26
omarchy.tailscale x=1777  y=0  width=27 height=26
omarchy.agents    x=1804  y=0  width=27 height=26
omarchy.audio     x=1831  y=0  width=27 height=26
omarchy.monitor   x=1858  y=0  width=27 height=26
omarchy.network   x=1885  y=0  width=27 height=26

All affected widgets had:

visible: true
itemVisible: true
width: 27
height: 26
itemWidth: 27
itemHeight: 26
y: 0

No duplicate widget entries were reported.

So the running shell's internal geometry appears correct even while the click problem is happening.

2. Hyprland layer inspection

While the problem was occurring I ran:

hyprctl layers

The relevant output was:

Layer level 2 (top):
    Layer ... xywh: 0 0 1920 26
    namespace: omarchy-bar

There was no omarchy-notifications layer present.

There was also no fullscreen overlay/input surface visible in the layer listing.

3. Notification overlay test

Following the investigation, I tested the notification-overlay hypothesis while the bar was still broken:

notify-send test

The notification appeared normally.

However, the top-bar click problem remained unchanged.

Therefore the stale omarchy-notifications input-region hypothesis does not appear to explain this occurrence.

4. Bar layout / duplicate widget check

I ran:

omarchy-shell shell listShellConfig | jq .bar.layout

The configured widgets are listed only once.

The right section is:

omarchy.tray
omarchy.dropbox
omarchy.tailscale
omarchy.agents
omarchy.audio
omarchy.power
omarchy.monitor
omarchy.network

There are no duplicate widget IDs.

Current conclusion from these tests

The following possibilities have now been ruled out or are not supported by the current evidence:

Incorrect live bar geometry
Duplicate widget IDs in shell.json
Fullscreen overlay blocking the desktop
omarchy-notifications being the cause of this occurrence
An obvious collapsed/hidden affected widget
Duplicate configured bar entries

The widgets remain visually correct and report correct 27x26 geometry, but their effective mouse interaction area can become displaced.

This makes a lower-level input/hit-testing issue around the Quickshell / LayerShell / Hyprland boundary seem more likely than a simple QML geometry problem.

I understand that this cannot be established from the QML source alone, so I am providing the runtime evidence and screen recording.

Relation to previous investigation

I also reviewed the previous investigation and understand that several earlier theories have already been reconsidered:

stale ModuleList / ModuleSlot
duplicated IpcHandler
duplicated bar widget construction
fullscreen WlrLayer.Overlay
cross-PanelWindow coordinate mapping

On this single-output system, the current evidence does not support those as the cause of this particular click issue.

I also understand that the duplicate IpcHandler warnings are a separate issue and do not explain the bar click path.

Custom Agent integration

For completeness, this machine has user-level OpenCode/Pi integrations with the Omarchy Agent widget.

These integrations are additive/user-level only and do not modify the Omarchy bar QML.

The previous investigation also found no evidence that the Agent/OpenCode/Pi integration is causing this mouse-input problem.

The current evidence points more toward the bar/input layer itself rather than the Agent integration.

Reproduction / recovery

The issue is intermittent.

When it happens:

The bar remains visually normal.
Affected widgets remain visible.
debugBarGeometry reports correct widget rectangles.
hyprctl layers shows the normal omarchy-bar layer.
No omarchy-notifications layer is present.
shell.json contains no duplicate widget IDs.
notify-send test does not restore the click behaviour.
Restarting the Omarchy shell restores normal clicking.
Changing the bar position also restores normal clicking.
The effective click location appears to be displaced relative to the visible widget.
Related issues

This appears related to previous Omarchy bar/input problems, although I understand they may not be exactly the same bug:

#10030 — Top-bar widgets intermittently stop responding to mouse clicks
#10122 — current investigation
#10221 — related investigation
#10310 — related pointer/hit-testing investigation
#8834 — bar centre section becomes unclickable with an absolute pointing device
#9048 — pointing-hand cursor / stale mouse coordinates in bar pointer handling
#9538 — pointer-input / hit-area issue involving Omarchy audio controls

I am continuing to follow #10030 as the main issue.

Request

Could you please advise what additional runtime-level diagnostics would be useful to capture while the issue is actively occurring?

At this point the most interesting observation seems to be:

The shell reports correct widget geometry and the bar is rendered correctly, but the actual mouse hit area can become displaced.

I have attached a screen recording showing the behaviour so the pointer position and visible widget position can be compared directly.

No restart or bar-position change was performed before taking the diagnostics above.