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

Universal copy (Super+C) sends Ctrl+X (cut) on non-QWERTY layouts (Colemak-DH)

Reported by figgeous · filed Oct 11, 2026 · open at source

Decided: Out of scope — decided by agents · verified 24 h 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

Universal copy (Super+C) sends Ctrl+X (cut) on non-QWERTY layouts (Colemak-DH)revision 1 · captured 2026-10-11 08:27 UTC via poll

System: Omarchy 4.0.4-1, Hyprland 0.56.2, Arch Linux. Layouts in ~/.config/hypr/input.lua:

hl.config({
  input = {
    kb_layout = "gb,gb",
    kb_variant = ",colemak_dh",
    kb_options = "compose:caps,shift:both_capslock_cancel,grp:alts_toggle",
  },
})

What happens

With Colemak-DH active, Super + C ("Universal copy") cuts the selected text instead of copying it. The text disappears from the field.

Cause

default/hypr/bindings/clipboard.lua sends the key by name:

hl.dsp.send_key_state({ mods = "CTRL", key = "C", state = "down" })

Hyprland resolves C against the active layout, which on UK Colemak-DH is keycode 53. The receiving app then decodes that keycode with the QWERTY keymap, where 53 is x.

Running wev -f wl_keyboard:key and pressing Super + C shows the app receiving:

key: 53; state: 1 (pressed)
  sym: x (120)
key: 53; state: 0 (released)
  sym: x (120)

So the app gets Ctrl+X (cut). Super + V still works only because V is keycode 55 in both layouts.

Workaround (confirmed working)

Overriding the binding to send the QWERTY keycode, key = "code:54", makes wev show:

key: 54; state: 1 (pressed)
  sym: c (99)

and Super + C copies correctly.

Expected

Super + C and Super + X send Ctrl+C and Ctrl+X on any layout.

View raw text
**System:** Omarchy 4.0.4-1, Hyprland 0.56.2, Arch Linux. Layouts in `~/.config/hypr/input.lua`:

```lua
hl.config({
  input = {
    kb_layout = "gb,gb",
    kb_variant = ",colemak_dh",
    kb_options = "compose:caps,shift:both_capslock_cancel,grp:alts_toggle",
  },
})
```

## What happens

With Colemak-DH active, `Super + C` ("Universal copy") cuts the selected text instead of copying it. The text disappears from the field.

## Cause

`default/hypr/bindings/clipboard.lua` sends the key by name:

```lua
hl.dsp.send_key_state({ mods = "CTRL", key = "C", state = "down" })
```

Hyprland resolves `C` against the active layout, which on UK Colemak-DH is keycode 53. The receiving app then decodes that keycode with the QWERTY keymap, where 53 is `x`.

Running `wev -f wl_keyboard:key` and pressing `Super + C` shows the app receiving:

```
key: 53; state: 1 (pressed)
  sym: x (120)
key: 53; state: 0 (released)
  sym: x (120)
```

So the app gets Ctrl+X (cut). `Super + V` still works only because `V` is keycode 55 in both layouts.

## Workaround (confirmed working)

Overriding the binding to send the QWERTY keycode, `key = "code:54"`, makes `wev` show:

```
key: 54; state: 1 (pressed)
  sym: c (99)
```

and `Super + C` copies correctly.

## Expected

`Super + C` and `Super + X` send Ctrl+C and Ctrl+X on any layout.

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-11 08:38 UTC