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.
Universal copy/paste (Super+C/V) does nothing in foot: held Super reaches foot with the Ctrl+Shift chord
Reported by SotoAugusto · filed Oct 9, 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
System details
- AMD Ryzen 7 255 w/ Radeon 780M Graphics
- Omarchy
4.0.0.r6815.g50d687a-1 - Hyprland
0.56.2 - foot
1.28.0
What's wrong?
Universal copy/paste (Super+C / Super+V) does nothing in foot. It works in other apps (browser etc.).
This is not the legacy-config case from #13349: ~/.config/foot/foot.ini already has the current template bindings:
[key-bindings]
clipboard-copy=Control+Insert Control+Shift+c XF86Copy
primary-paste=none
clipboard-paste=Shift+Insert Control+Shift+v XF86PasteTerminal detection also works: the foot window carries the terminal* tag (checked via hyprctl repl with hl.get_active_window().tags), so default/hypr/bindings/clipboard.lua sends CTRL SHIFT + C/V as intended.
Cause: the physically held Super is still in the modifier state when the injected chord arrives, so foot sees Super+Ctrl+Shift+V. foot only runs a key binding when the modifiers match exactly, so neither clipboard-copy nor clipboard-paste fires. Apps that ignore the extra Super (browsers) are unaffected. The comment at the top of clipboard.lua says sending explicit mods prevents Super merging into the chord, but foot shows it still does.
Steps to reproduce
- Open foot with the current template
foot.ini. - Select some text and press
Super+C, or pressSuper+Vwith text on the clipboard. - Nothing happens.
Repro without a physical keyboard, into a scratch foot window running read:
printf 'PASTE_MARKER' | wl-copy
# with the scratch foot window focused:
hyprctl repl 'hl.dispatch(hl.dsp.send_key_state({ mods = "SUPER CTRL SHIFT", key = "V", state = "down" })); hl.timer(function() hl.dispatch(hl.dsp.send_key_state({ mods = "SUPER CTRL SHIFT", key = "V", state = "up" })) end, { timeout = 50, type = "oneshot" })'mods = "CTRL SHIFT": the marker gets pasted.mods = "SUPER CTRL SHIFT": nothing gets pasted (simulates the held Super).
Workaround / possible fix
Add the Super-held chords to foot's bindings:
clipboard-copy=Control+Insert Control+Shift+c Mod4+Control+Shift+c XF86Copy
clipboard-paste=Shift+Insert Control+Shift+v Mod4+Control+Shift+v XF86PasteWith this, the simulated case above pastes, and a real Super+C / Super+V works in a newly opened foot window. The fix could go into the shipped config/foot/foot.ini plus a migration (similar to the open PRs for #13349: #13378 / #13446 / #13649).
Related: #13349, #13559.
View raw text
### System details
- AMD Ryzen 7 255 w/ Radeon 780M Graphics
- Omarchy `4.0.0.r6815.g50d687a-1`
- Hyprland `0.56.2`
- foot `1.28.0`
### What's wrong?
Universal copy/paste (`Super+C` / `Super+V`) does nothing in foot. It works in other apps (browser etc.).
This is **not** the legacy-config case from #13349: `~/.config/foot/foot.ini` already has the current template bindings:
```ini
[key-bindings]
clipboard-copy=Control+Insert Control+Shift+c XF86Copy
primary-paste=none
clipboard-paste=Shift+Insert Control+Shift+v XF86Paste
```
Terminal detection also works: the foot window carries the `terminal*` tag (checked via `hyprctl repl` with `hl.get_active_window().tags`), so `default/hypr/bindings/clipboard.lua` sends `CTRL SHIFT` + `C`/`V` as intended.
**Cause:** the physically held Super is still in the modifier state when the injected chord arrives, so foot sees `Super+Ctrl+Shift+V`. foot only runs a key binding when the modifiers match exactly, so neither `clipboard-copy` nor `clipboard-paste` fires. Apps that ignore the extra Super (browsers) are unaffected. The comment at the top of `clipboard.lua` says sending explicit mods prevents Super merging into the chord, but foot shows it still does.
### Steps to reproduce
1. Open foot with the current template `foot.ini`.
2. Select some text and press `Super+C`, or press `Super+V` with text on the clipboard.
3. Nothing happens.
Repro without a physical keyboard, into a scratch foot window running `read`:
```bash
printf 'PASTE_MARKER' | wl-copy
# with the scratch foot window focused:
hyprctl repl 'hl.dispatch(hl.dsp.send_key_state({ mods = "SUPER CTRL SHIFT", key = "V", state = "down" })); hl.timer(function() hl.dispatch(hl.dsp.send_key_state({ mods = "SUPER CTRL SHIFT", key = "V", state = "up" })) end, { timeout = 50, type = "oneshot" })'
```
- `mods = "CTRL SHIFT"`: the marker gets pasted.
- `mods = "SUPER CTRL SHIFT"`: nothing gets pasted (simulates the held Super).
### Workaround / possible fix
Add the Super-held chords to foot's bindings:
```ini
clipboard-copy=Control+Insert Control+Shift+c Mod4+Control+Shift+c XF86Copy
clipboard-paste=Shift+Insert Control+Shift+v Mod4+Control+Shift+v XF86Paste
```
With this, the simulated case above pastes, and a real `Super+C` / `Super+V` works in a newly opened foot window. The fix could go into the shipped `config/foot/foot.ini` plus a migration (similar to the open PRs for #13349: #13378 / #13446 / #13649).
Related: #13349, #13559.
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 23:21 UTC