Proof Portal

Sign in
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-122GitHub issuePublicDecided· Out of scope

Held Ctrl is lost during keyboard repeat in native Wayland apps when Omarchy's fcitx5 service is running

Reported by MPavleski · filed Sep 24, 2026 · open at source

Open at source
Decided: Out of scope — decided by agents · verified 3 days 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

Held Ctrl is lost during keyboard repeat in native Wayland apps when Omarchy's fcitx5 service is runningrevision 1 · captured 2026-09-28 21:23 UTC via poll

System details

Omarchy 4.0.0.r2186.gee8ebf6-1

What's wrong?

Description

While holding Ctrl and a repeatable key, the first few key-down events reach the application with Ctrl held, but subsequent repeated key-down events arrive without Ctrl. For example, holding Ctrl+W changes from Ctrl+W events to plain W events even though Ctrl remains physically pressed. This affects native Wayland applications, including Firefox and Visual Studio Code. The same keyboard behavior worked as expected under KWin Wayland.

Steps to reproduce

  1. Start an Omarchy session with omarchy-fcitx5.service running.
  2. In a native Wayland application, hold Ctrl and a repeatable key long enough for keyboard repeat to begin. Observe the modifier state on the repeated key events.
  3. Temporarily stop fcitx5 with systemctl --user stop omarchy-fcitx5.service and repeat the test.
  4. Restore the service with systemctl --user start omarchy-fcitx5.service.

Expected behavior

Ctrl remains active on every repeated key event until the physical Ctrl key is released.

Actual behavior

After a few repeated key-down events, the application sees the key without Ctrl. I manually confirmed that the problem disappears when omarchy-fcitx5.service is stopped.

System details

  • Omarchy 4.0.0.r2186.gee8ebf6-1
  • Hyprland 0.56.2 (hyprland 0.56.2-3)
  • fcitx5 5.1.22 (fcitx5 5.1.22-1)
  • omarchy-fcitx5.service enabled and running during reproduction
  • Firefox and Visual Studio Code verified as native Wayland windows (xwayland: false in hyprctl clients -j)
  • Keyboard layouts: us,si,mk; XKB options: grp:alts_toggle,grp:alt_space_toggle

Related reports

  • Omarchy #5598: fcitx5 prevents modifiers held on one keyboard from applying to keys on another in native Wayland apps; stopping fcitx5 resolves it. This is a related modifier-state failure, though the reproduction differs.
  • Hyprland discussion #9954: tracks multi-keyboard modifier handling and the fcitx5 input-method path.

The precise point where the Ctrl state is lost still needs a Wayland keyboard event trace. The stop/start comparison isolates fcitx5 as a necessary part of this reproduction.

View raw text
### System details

Omarchy `4.0.0.r2186.gee8ebf6-1`

### What's wrong?

## Description

While holding Ctrl and a repeatable key, the first few key-down events reach the application with Ctrl held, but subsequent repeated key-down events arrive without Ctrl. For example, holding Ctrl+W changes from Ctrl+W events to plain W events even though Ctrl remains physically pressed. This affects native Wayland applications, including Firefox and Visual Studio Code. The same keyboard behavior worked as expected under KWin Wayland.

## Steps to reproduce

1. Start an Omarchy session with `omarchy-fcitx5.service` running.
2. In a native Wayland application, hold Ctrl and a repeatable key long enough for keyboard repeat to begin. Observe the modifier state on the repeated key events.
3. Temporarily stop fcitx5 with `systemctl --user stop omarchy-fcitx5.service` and repeat the test.
4. Restore the service with `systemctl --user start omarchy-fcitx5.service`.

## Expected behavior

Ctrl remains active on every repeated key event until the physical Ctrl key is released.

## Actual behavior

After a few repeated key-down events, the application sees the key without Ctrl. I manually confirmed that the problem disappears when `omarchy-fcitx5.service` is stopped.

## System details

- Omarchy `4.0.0.r2186.gee8ebf6-1`
- Hyprland 0.56.2 (`hyprland 0.56.2-3`)
- fcitx5 5.1.22 (`fcitx5 5.1.22-1`)
- `omarchy-fcitx5.service` enabled and running during reproduction
- Firefox and Visual Studio Code verified as native Wayland windows (`xwayland: false` in `hyprctl clients -j`)
- Keyboard layouts: `us,si,mk`; XKB options: `grp:alts_toggle,grp:alt_space_toggle`

## Related reports

- [Omarchy #5598](https://github.com/omacom/omarchy/issues/5598): fcitx5 prevents modifiers held on one keyboard from applying to keys on another in native Wayland apps; stopping fcitx5 resolves it. This is a related modifier-state failure, though the reproduction differs.
- [Hyprland discussion #9954](https://github.com/hyprwm/Hyprland/discussions/9954): tracks multi-keyboard modifier handling and the fcitx5 input-method path.

The precise point where the Ctrl state is lost still needs a Wayland keyboard event trace. The stop/start comparison isolates fcitx5 as a necessary part of this reproduction.

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 19:40 UTC