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-5115GitHub issuePublicReceived

Password preedit text is shown in plaintext on lock screen / polkit prompts when an IME is active

Reported by Rhytam23 · filed Sep 23, 2026Closed upstream on 2026-09-24 by its own reporter Rhytam23. GitHub close reason: completed. Closed by its own reporter — not by itself evidence of a fix.

Open at source
Received and recorded verbatim. Nothing has been checked yet.

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

Password preedit text is shown in plaintext on lock screen / polkit prompts when an IME is activerevision 1 · captured 2026-10-04 12:10 UTC via poll

System details

omarchy (current default branch / 4.0.4-1)

What's wrong?

When an input method (fcitx5, ibus, or any IME with composition/preedit enabled) is active while
typing into a password field — the lock screen unlock field, the Wi-Fi passphrase field, or the
Polkit (sudo) authentication prompt — the character(s) currently being composed are shown in
plaintext by the input method's own preedit/candidate popup, even though the field itself is
masked (dots/bullets).

This looks like the same symptom reported in #12727 ("password becomes visible when unlocking"),
with a likely root cause identified there.

Why this happens

TextInput.Password (and Ui/TextField's password mode) only mask committed text. They do
nothing to an input method's preedit/composition buffer — an active IME draws that separately, in
plaintext, regardless of the field's echo mode. Qt suppresses this only when the field sets
inputMethodHints to include Qt.ImhSensitiveData | Qt.ImhHiddenText | Qt.ImhNoPredictiveText.

None of the shell's password fields set inputMethodHints:
- shell/plugins/lock/LockView.qml (lock screen password)
- shell/Ui/TextField.qml (shared password-mode field, e.g. Wi-Fi passphrase)
- shell/plugins/polkit/PolkitAgent.qml (sudo/polkit prompt)

This is more likely to be hit now that fcitx5 is seeded as the default input method, so more users
have an active IME on the lock screen.

To reproduce

  1. Enable fcitx5 or ibus with composition/preedit enabled.
  2. Lock the screen (or trigger a polkit auth prompt).
  3. Focus the password field and start typing.
  4. Observe the IME's preedit/candidate popup rendering the typed characters in plaintext, even

though the field itself shows masked dots.

Suggested fix

Set inputMethodHints: Qt.ImhSensitiveData | Qt.ImhHiddenText | Qt.ImhNoPredictiveText on each
password field above. See #13001 for a draft fix.

View raw text
### System details

omarchy (current default branch / 4.0.4-1)

### What's wrong?

When an input method (fcitx5, ibus, or any IME with composition/preedit enabled) is active while
typing into a password field — the lock screen unlock field, the Wi-Fi passphrase field, or the
Polkit (sudo) authentication prompt — the character(s) currently being composed are shown in
plaintext by the input method's own preedit/candidate popup, even though the field itself is
masked (dots/bullets).

This looks like the same symptom reported in #12727 ("password becomes visible when unlocking"),
with a likely root cause identified there.

### Why this happens

`TextInput.Password` (and `Ui/TextField`'s `password` mode) only mask **committed** text. They do
nothing to an input method's preedit/composition buffer — an active IME draws that separately, in
plaintext, regardless of the field's echo mode. Qt suppresses this only when the field sets
`inputMethodHints` to include `Qt.ImhSensitiveData | Qt.ImhHiddenText | Qt.ImhNoPredictiveText`.

None of the shell's password fields set `inputMethodHints`:
- `shell/plugins/lock/LockView.qml` (lock screen password)
- `shell/Ui/TextField.qml` (shared password-mode field, e.g. Wi-Fi passphrase)
- `shell/plugins/polkit/PolkitAgent.qml` (sudo/polkit prompt)

This is more likely to be hit now that fcitx5 is seeded as the default input method, so more users
have an active IME on the lock screen.

### To reproduce

1. Enable fcitx5 or ibus with composition/preedit enabled.
2. Lock the screen (or trigger a polkit auth prompt).
3. Focus the password field and start typing.
4. Observe the IME's preedit/candidate popup rendering the typed characters in plaintext, even
   though the field itself shows masked dots.

### Suggested fix

Set `inputMethodHints: Qt.ImhSensitiveData | Qt.ImhHiddenText | Qt.ImhNoPredictiveText` on each
password field above. See #13001 for a draft fix.

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.