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

Bluetooth panel pairing silently fails for devices requiring passkey confirmation

Reported by mhbnielsen · filed Sep 11, 2026Closed upstream on 2026-09-21 by bjarneo via an automated message, as a duplicate of #8485 (R-1398). GitHub close reason: completed.

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

Bluetooth panel pairing silently fails for devices requiring passkey confirmationrevision 1 · captured 2026-10-04 12:10 UTC via poll

What happened

Pairing a Logitech MX Keys S keyboard (fresh Bluetooth pairing, not a reconnect) through the Bluetooth panel/omarchy bluetooth device pair <mac> showed the device as Paired/Connected, but it was completely non-functional — no keystrokes registered. Manually pairing the same device address directly through bluetoothctl pair <mac> worked fine once I typed the passkey it displayed.

Root cause

omarchy-bluetooth-device's pair action runs:

timeout 20s bluetoothctl pair "$address" >/dev/null 2>&1 || true
trust_device
timeout 20s bluetoothctl connect "$address" >/dev/null 2>&1 || true

All of bluetoothctl's output is redirected to /dev/null. Devices that use "Just Works" pairing are unaffected, but devices whose IO capability requires passkey-entry confirmation (many keyboards, including this one) need bluetoothctl's agent to display a 6-digit passkey ([agent] Passkey: NNNNNN) for the user to type on the device within a few seconds. Because that prompt is discarded, the user never sees it, the passkey is never entered, and the 20s timeout expires with the pairing left in a broken/partial state — no working link keys, but trust+connect still get attempted regardless (|| true), so the panel can end up showing "Connected" for a device that never actually completed authentication.

Expected

Fresh pairing of a passkey-requiring device through the Bluetooth panel should either surface the passkey somewhere the user can see it (OSD/notification), or the panel should otherwise handle passkey-confirmation pairing instead of running fully silent with output suppressed.

Repro

  1. Have a Bluetooth device that requires passkey-entry pairing (not Just Works) — e.g. a Logitech MX Keys S doing a from-scratch pair (hold its Easy-Switch button on a channel until it fast-blinks).
  2. Pair it via the Omarchy Bluetooth panel, or omarchy bluetooth device pair <address>.
  3. Panel shows Paired/Connected.
  4. Device does not actually function (no HID input registers).
  5. Compare: bluetoothctl pair <address> run directly shows [agent] Passkey: NNNNNN; typing it on the device completes pairing correctly and the device works.

System details

  • Omarchy version: 4.0.2-1 (stable channel)
  • Kernel: 7.1.9-arch1-2
  • CPU: Intel Core Ultra 7 155H (Meteor Lake)
  • GPU: Intel Meteor Lake-P [Intel Arc Graphics]
  • Device: Logitech MX Keys S (Bluetooth LE HID keyboard)

(Note: omarchy debug --no-sudo --print returned "Unknown Omarchy command" on this install, so I couldn't attach that log — may be worth checking if that command still exists.)

View raw text
## What happened

Pairing a Logitech MX Keys S keyboard (fresh Bluetooth pairing, not a reconnect) through the Bluetooth panel/`omarchy bluetooth device pair <mac>` showed the device as Paired/Connected, but it was completely non-functional — no keystrokes registered. Manually pairing the same device address directly through `bluetoothctl pair <mac>` worked fine once I typed the passkey it displayed.

## Root cause

`omarchy-bluetooth-device`'s `pair` action runs:

```bash
timeout 20s bluetoothctl pair "$address" >/dev/null 2>&1 || true
trust_device
timeout 20s bluetoothctl connect "$address" >/dev/null 2>&1 || true
```

All of `bluetoothctl`'s output is redirected to `/dev/null`. Devices that use "Just Works" pairing are unaffected, but devices whose IO capability requires **passkey-entry confirmation** (many keyboards, including this one) need `bluetoothctl`'s agent to display a 6-digit passkey (`[agent] Passkey: NNNNNN`) for the user to type on the device within a few seconds. Because that prompt is discarded, the user never sees it, the passkey is never entered, and the 20s timeout expires with the pairing left in a broken/partial state — no working link keys, but `trust`+`connect` still get attempted regardless (`|| true`), so the panel can end up showing "Connected" for a device that never actually completed authentication.

## Expected

Fresh pairing of a passkey-requiring device through the Bluetooth panel should either surface the passkey somewhere the user can see it (OSD/notification), or the panel should otherwise handle passkey-confirmation pairing instead of running fully silent with output suppressed.

## Repro

1. Have a Bluetooth device that requires passkey-entry pairing (not Just Works) — e.g. a Logitech MX Keys S doing a from-scratch pair (hold its Easy-Switch button on a channel until it fast-blinks).
2. Pair it via the Omarchy Bluetooth panel, or `omarchy bluetooth device pair <address>`.
3. Panel shows Paired/Connected.
4. Device does not actually function (no HID input registers).
5. Compare: `bluetoothctl pair <address>` run directly shows `[agent] Passkey: NNNNNN`; typing it on the device completes pairing correctly and the device works.

## System details

- Omarchy version: 4.0.2-1 (stable channel)
- Kernel: 7.1.9-arch1-2
- CPU: Intel Core Ultra 7 155H (Meteor Lake)
- GPU: Intel Meteor Lake-P [Intel Arc Graphics]
- Device: Logitech MX Keys S (Bluetooth LE HID keyboard)

(Note: `omarchy debug --no-sudo --print` returned "Unknown Omarchy command" on this install, so I couldn't attach that log — may be worth checking if that command still exists.)

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.