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

USB device authorization needs hotkeys to approve or reject pending devices

Reported by ekollof · filed Oct 10, 2026 · open at source

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

USB device authorization needs hotkeys to approve or reject pending devicesrevision 1 · captured 2026-10-10 10:28 UTC via poll

The new USB device authorization flow has no dedicated hotkeys to acknowledge/approve or reject a newly connected USB device.

With USB authorization enabled, connecting an untrusted device produces a critical “USB accessory blocked” notification that says “Click to review it.” Opening it launches a terminal chooser with “Allow once”, “Always allow this device”, and “Keep blocked”. There is no USB-specific keyboard action to reach the pending request or approve/reject it.

There is an existing generic workaround: Super + Alt + , invokes the last notification. That can open the USB review when it is the last actionable notification, but it targets notifications generally rather than the pending USB request. The chooser itself is keyboard-operable once opened; the missing part is a dedicated, discoverable shortcut to the USB authorization decision.

Steps

  1. Enable USB Device Authorization through Setup → Security.
  2. Connect an untrusted USB device.
  3. Try to approve or keep it blocked using a USB authorization hotkey, without clicking the notification or relying on it being the last notification.

Requested behavior

  • Provide documented, bindable keyboard actions for reviewing and approving/rejecting pending USB requests.
  • Identify the device being acted on; when multiple requests are pending, let the user select the intended device.
  • Preserve the distinction between “Allow once”, persistent trust, and “Keep blocked”. A normal approval shortcut should not silently grant permanent trust.
  • Keep existing device-identity validation and authorization checks in the keyboard path.

The exact default key combinations can follow the project's existing conventions. A dedicated shortcut opening a pending-device chooser with keyboard approve/reject actions would also address this.

Code references

  • bin/omarchy-usb-authorization-event: sends the notification and associates it with a token-specific review command.
  • bin/omarchy-usb-authorization-review: requires a request token and implements the three review choices.
  • default/hypr/bindings/utilities.lua: provides generic notification shortcuts, including invoking the last notification, but no USB-specific action.

This report describes the keyboard workflow gap and source inspection; no new USB hotplug reproduction or authorization-policy change was performed while filing it.

View raw text
The new USB device authorization flow has no dedicated hotkeys to acknowledge/approve or reject a newly connected USB device.

With USB authorization enabled, connecting an untrusted device produces a critical “USB accessory blocked” notification that says “Click to review it.” Opening it launches a terminal chooser with “Allow once”, “Always allow this device”, and “Keep blocked”. There is no USB-specific keyboard action to reach the pending request or approve/reject it.

There is an existing generic workaround: `Super + Alt + ,` invokes the last notification. That can open the USB review when it is the last actionable notification, but it targets notifications generally rather than the pending USB request. The chooser itself is keyboard-operable once opened; the missing part is a dedicated, discoverable shortcut to the USB authorization decision.

### Steps

1. Enable USB Device Authorization through Setup → Security.
2. Connect an untrusted USB device.
3. Try to approve or keep it blocked using a USB authorization hotkey, without clicking the notification or relying on it being the last notification.

### Requested behavior

- Provide documented, bindable keyboard actions for reviewing and approving/rejecting pending USB requests.
- Identify the device being acted on; when multiple requests are pending, let the user select the intended device.
- Preserve the distinction between “Allow once”, persistent trust, and “Keep blocked”. A normal approval shortcut should not silently grant permanent trust.
- Keep existing device-identity validation and authorization checks in the keyboard path.

The exact default key combinations can follow the project's existing conventions. A dedicated shortcut opening a pending-device chooser with keyboard approve/reject actions would also address this.

### Code references

- `bin/omarchy-usb-authorization-event`: sends the notification and associates it with a token-specific review command.
- `bin/omarchy-usb-authorization-review`: requires a request token and implements the three review choices.
- `default/hypr/bindings/utilities.lua`: provides generic notification shortcuts, including invoking the last notification, but no USB-specific action.

This report describes the keyboard workflow gap and source inspection; no new USB hotplug reproduction or authorization-policy change was performed while filing it.

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

  • Related PRpr/14936· confirmed
  • Related PRpr/14937· confirmed
  • Related PRpr/14938· confirmed
  • Related PRpr/15091· confirmed

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-10 13:04 UTC