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.
omarchy plugin clone leaves bar.centerAnchor pointing at the old widget id, silently disabling the center anchor
Reported by emindashdamirov11-lang · filed Sep 27, 2026Closed upstream on 2026-09-27 by its own reporter emindashdamirov11-lang, as a duplicate of #7868 (R-1557). GitHub close reason: not_planned.
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
Summary
omarchy plugin clone renames the cloned widget's id in the bar layout but does not migrate bar.centerAnchor. After cloning the clock, centerAnchor keeps pointing at the original omarchy.clock id, which no longer exists in the layout.
The bar then silently falls back to a different layout algorithm: the clock is no longer pinned as the center anchor, so revealing the indicators slides the whole center row sideways instead of expanding away from a fixed clock.
Steps to reproduce
omarchy plugin clone omarchy.clock— this creates~/.config/omarchy/plugins/$USER.clock/and switches the bar to the clone.- Inspect
~/.config/omarchy/shell.json. The center layout entry is now"id": "$USER.clock", butbar.centerAnchoris still"omarchy.clock". - Hover the clock.
Nothing is logged. The bar renders, but the clock now moves with the row.
What happened vs. what was expected
The anchor lookup is an exact string match:
plugins/bar/BarModel.js:50—entryIndex()comparesentryId(entries[i]) === nameplugins/bar/Bar.qml:1538—hasAnchor: root.entryIndex(entries, root.centerAnchor) !== -1
With the stale id, hasAnchor is false, so Bar.qml:1558-1563 renders all center entries as one ModuleList with anchors.centerIn: parent. Revealing the indicators widens that centered block, so the clock shifts with it.
When the anchor does resolve, Bar.qml:1576-1579 pins the anchor module with anchors.centerIn: parent and the entries before it grow leftward via anchors.right: centerAnchorModule.left — the clock holds its position.
The reveal itself is stock behavior, not part of this bug: hovering the center section sets centerSectionRevealHeld (Bar.qml:813-821), which Indicators.qml:18 reads to expand the inactive indicators. The bug is only that the hover now moves the clock because the anchor is gone.
Two contributing defects
1. Clone does not migrate `centerAnchor`.
omarchy-plugin-clone computes the new id (new_id="${USER}.${source_id#omarchy.}"), updates the manifest, then calls omarchy-plugin-enable → omarchy-shell shell enablePlugin, which is what rewrites the layout entry. Nothing rewrites bar.centerAnchor. Since omarchy.clock is the stock default (Bar.qml:48), this is reachable with a single stock command and hits anyone who clones the clock.
2. The bar fails silently.
applyBarConfig (Bar.qml:586) assigns centerAnchor with no validation, and there is no console.warn anywhere in Bar.qml. An unresolvable anchor degrades layout behavior with no diagnostic, so the config looks valid and the regression has no visible cause.
Suggested fix
- Have
omarchy plugin cloneupdatebar.centerAnchorto the new id when the cloned widget is the current anchor. - Log a warning in
applyBarConfigwhencenterAnchoris set but matches no entry in the center layout.
Fixing (2) alone would have made this immediately self-diagnosing.
System
- Omarchy 4.0.4-1
- Hyprland 0.56.2
- Kernel 7.2.3-arch1-3
- CPU: AMD Ryzen 7 4800H with Radeon Graphics
- GPU: NVIDIA TU117M [GeForce GTX 1650 Ti Mobile], driver 610.57.04
- Machine: LENOVO 82B5 (Lenovo Legion 5 15ARH05)
View raw text
## Summary
`omarchy plugin clone` renames the cloned widget's id in the bar layout but does not migrate `bar.centerAnchor`. After cloning the clock, `centerAnchor` keeps pointing at the original `omarchy.clock` id, which no longer exists in the layout.
The bar then silently falls back to a different layout algorithm: the clock is no longer pinned as the center anchor, so revealing the indicators slides the whole center row sideways instead of expanding away from a fixed clock.
## Steps to reproduce
1. `omarchy plugin clone omarchy.clock` — this creates `~/.config/omarchy/plugins/$USER.clock/` and switches the bar to the clone.
2. Inspect `~/.config/omarchy/shell.json`. The center layout entry is now `"id": "$USER.clock"`, but `bar.centerAnchor` is still `"omarchy.clock"`.
3. Hover the clock.
Nothing is logged. The bar renders, but the clock now moves with the row.
## What happened vs. what was expected
The anchor lookup is an exact string match:
- `plugins/bar/BarModel.js:50` — `entryIndex()` compares `entryId(entries[i]) === name`
- `plugins/bar/Bar.qml:1538` — `hasAnchor: root.entryIndex(entries, root.centerAnchor) !== -1`
With the stale id, `hasAnchor` is `false`, so `Bar.qml:1558-1563` renders **all** center entries as one `ModuleList` with `anchors.centerIn: parent`. Revealing the indicators widens that centered block, so the clock shifts with it.
When the anchor does resolve, `Bar.qml:1576-1579` pins the anchor module with `anchors.centerIn: parent` and the entries before it grow leftward via `anchors.right: centerAnchorModule.left` — the clock holds its position.
The reveal itself is stock behavior, not part of this bug: hovering the center section sets `centerSectionRevealHeld` (`Bar.qml:813-821`), which `Indicators.qml:18` reads to expand the inactive indicators. The bug is only that the hover now *moves the clock* because the anchor is gone.
## Two contributing defects
**1. Clone does not migrate `centerAnchor`.**
`omarchy-plugin-clone` computes the new id (`new_id="${USER}.${source_id#omarchy.}"`), updates the manifest, then calls `omarchy-plugin-enable` → `omarchy-shell shell enablePlugin`, which is what rewrites the layout entry. Nothing rewrites `bar.centerAnchor`. Since `omarchy.clock` is the stock default (`Bar.qml:48`), this is reachable with a single stock command and hits anyone who clones the clock.
**2. The bar fails silently.**
`applyBarConfig` (`Bar.qml:586`) assigns `centerAnchor` with no validation, and there is no `console.warn` anywhere in `Bar.qml`. An unresolvable anchor degrades layout behavior with no diagnostic, so the config looks valid and the regression has no visible cause.
## Suggested fix
- Have `omarchy plugin clone` update `bar.centerAnchor` to the new id when the cloned widget is the current anchor.
- Log a warning in `applyBarConfig` when `centerAnchor` is set but matches no entry in the center layout.
Fixing (2) alone would have made this immediately self-diagnosing.
## System
- Omarchy 4.0.4-1
- Hyprland 0.56.2
- Kernel 7.2.3-arch1-3
- CPU: AMD Ryzen 7 4800H with Radeon Graphics
- GPU: NVIDIA TU117M [GeForce GTX 1650 Ti Mobile], driver 610.57.04
- Machine: LENOVO 82B5 (Lenovo Legion 5 15ARH05)
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.