Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA 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.
Third-party bar-widgets locked out of bar drag-reorder (PluginBarApi exposes no drag state)
Reported by ujo4eva · filed Sep 15, 2026 · open at source
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
Third-party bar-widgets cannot participate in bar drag-reorder (regression vs pre-sandbox shell)
Setup
- Omarchy 4.0.3-1, quickshell 0.3.1-1
- Intel i5-9300H, Intel UHD 630 + NVIDIA GTX 1050 Max-Q
- Affected plugin: io.github.tyrichards.tray 1.9.3 — its headline feature (drag any bar widget into its drawer) used to work and no longer does, with no plugin-side change.
What happens
Dragging a widget over the third-party tray never registers: no highlight, no insertion marker, release falls through to stock bar reorder. Additionally, a hand-written hosted entry (widgets: [{entry: {id: ...}}] on the tray's shell.json entry) never renders, with no load error in the shell log.
Why (traced to the sandbox)
- Third-party widgets receive PluginBarApi (shell/Ui/PluginBarApi.qml) instead of the Bar object. It exposes no drag state or operations: barDragSource/Window/Screen/SceneX/Y, captureBarDragGhost (plugins/bar/Bar.qml:529), moduleDropAtScene (:913), dropMarkerRect (:445), moduleClickTargetAt/pressModuleClickTarget, moduleSlots/slotWindow are all absent, so a widget cannot observe or join a drag.
- pluginHasBarCapabilities (shell.qml:354) requires kinds: ["bar"], so a kinds: ["bar-widget"] plugin's _mutateBarConfig is gated off (shell.qml:654-656) and cannot persist a drop Shepherd-style layout change.
- Net: any widget needing drop-target behavior is architecturally blocked. Filing here rather than only upstream because the fix (read-only drag-state exposure and/or a scoped widget-capture mutate path for widgets, or an explicit statement that drag-interop is first-party-only) has to come from the shell side.
Repro
1. omarchy plugin add https://github.com/TyRichards/omarchy-tray.git --enable --yes, swap omarchy.tray for io.github.tyrichards.tray in shell.json.
2. Drag any bar widget onto the tray — nothing happens.
3. Optional: hand-add "widgets": [{"entry": {"id": "bt.codecs"}, "listed": true}] to the tray entry — drawer still renders empty on hover.
Happy to capture logs, test a branch, or move this to Discussions if you prefer to track it as a feature request rather than a regression.
View raw text
## Third-party bar-widgets cannot participate in bar drag-reorder (regression vs pre-sandbox shell)
**Setup**
- Omarchy 4.0.3-1, quickshell 0.3.1-1
- Intel i5-9300H, Intel UHD 630 + NVIDIA GTX 1050 Max-Q
- Affected plugin: `io.github.tyrichards.tray` 1.9.3 — its headline feature (drag any bar widget into its drawer) used to work and no longer does, with no plugin-side change.
**What happens**
Dragging a widget over the third-party tray never registers: no highlight, no insertion marker, release falls through to stock bar reorder. Additionally, a hand-written hosted entry (`widgets: [{entry: {id: ...}}]` on the tray's `shell.json` entry) never renders, with no load error in the shell log.
**Why (traced to the sandbox)**
- Third-party widgets receive `PluginBarApi` (`shell/Ui/PluginBarApi.qml`) instead of the `Bar` object. It exposes no drag state or operations: `barDragSource/Window/Screen/SceneX/Y`, `captureBarDragGhost` (`plugins/bar/Bar.qml:529`), `moduleDropAtScene` (`:913`), `dropMarkerRect` (`:445`), `moduleClickTargetAt`/`pressModuleClickTarget`, `moduleSlots`/`slotWindow` are all absent, so a widget cannot observe or join a drag.
- `pluginHasBarCapabilities` (`shell.qml:354`) requires `kinds: ["bar"]`, so a `kinds: ["bar-widget"]` plugin's `_mutateBarConfig` is gated off (`shell.qml:654-656`) and cannot persist a drop Shepherd-style layout change.
- Net: any widget needing drop-target behavior is architecturally blocked. Filing here rather than only upstream because the fix (read-only drag-state exposure and/or a scoped widget-capture mutate path for widgets, or an explicit statement that drag-interop is first-party-only) has to come from the shell side.
**Repro**
1. `omarchy plugin add https://github.com/TyRichards/omarchy-tray.git --enable --yes`, swap `omarchy.tray` for `io.github.tyrichards.tray` in `shell.json`.
2. Drag any bar widget onto the tray — nothing happens.
3. Optional: hand-add `"widgets": [{"entry": {"id": "bt.codecs"}, "listed": true}]` to the tray entry — drawer still renders empty on hover.
Happy to capture logs, test a branch, or move this to Discussions if you prefer to track it as a feature request rather than a regression.
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 13:42 UTC