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

Protect active Bluetooth audio from panel discovery

Reported by lbonvarl · filed Aug 18, 2026 · open at source

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

Protect active Bluetooth audio from panel discoveryrevision 1 · captured 2026-09-28 21:29 UTC via poll

System details

  • Omarchy 4.0.0-1
  • Apple MacBookPro14,1 (13-inch, 2017), Intel Core i5-7360U, 8 GB RAM
  • Linux 7.1.8-arch1-3
  • BlueZ 5.87
  • PipeWire 1.6.8
  • Bluetooth audio device connected over A2DP

What's wrong?

Opening the Bluetooth panel immediately starts discovery even when PipeWire has an active Bluetooth audio sink. On controllers that cannot sustain inquiry and A2DP reliably at the same time, playback starts stuttering or pausing as soon as the panel opens.

#6794 fixed the persistent part of #6789 by stopping the discovery session after the panel closes. That prevents the degradation from continuing indefinitely, but discovery still overlaps active audio for the entire time the panel is open.

Steps to reproduce

  1. Connect a Bluetooth audio device and start playback over A2DP.
  2. Confirm bluetoothctl show reports Discovering: no.
  3. Open the Bluetooth panel from the bar.
  4. Observe Discovering: yes and audible interruptions while the panel remains open.
  5. Close the panel. Discovery now stops through #6794, and playback settles again.

The PipeWire stream remains active during the interruption, so this presents as radio contention rather than a stream teardown or routing failure.

Expected

Opening the panel should preserve active Bluetooth audio. Automatic discovery should remain available when no Bluetooth audio sink is connected, with an explicit way to scan when the user needs to pair another device despite the possible interruption.

Proposed behavior

  • Detect a connected Bluetooth audio sink from PipeWire.
  • Keep automatic discovery off while that sink exists.
  • Show an Audio protected status and a session-only Scan anyway action.
  • Clearly warn that the one-time scan may interrupt audio.
  • Stop the forced scan manually or automatically when the panel closes.

This keeps the normal zero-click discovery behavior for users who are not streaming audio while making the disruptive transition intentional for those who are.

View raw text
## System details

- Omarchy 4.0.0-1
- Apple MacBookPro14,1 (13-inch, 2017), Intel Core i5-7360U, 8 GB RAM
- Linux 7.1.8-arch1-3
- BlueZ 5.87
- PipeWire 1.6.8
- Bluetooth audio device connected over A2DP

## What's wrong?

Opening the Bluetooth panel immediately starts discovery even when PipeWire has an active Bluetooth audio sink. On controllers that cannot sustain inquiry and A2DP reliably at the same time, playback starts stuttering or pausing as soon as the panel opens.

#6794 fixed the persistent part of #6789 by stopping the discovery session after the panel closes. That prevents the degradation from continuing indefinitely, but discovery still overlaps active audio for the entire time the panel is open.

### Steps to reproduce

1. Connect a Bluetooth audio device and start playback over A2DP.
2. Confirm `bluetoothctl show` reports `Discovering: no`.
3. Open the Bluetooth panel from the bar.
4. Observe `Discovering: yes` and audible interruptions while the panel remains open.
5. Close the panel. Discovery now stops through #6794, and playback settles again.

The PipeWire stream remains active during the interruption, so this presents as radio contention rather than a stream teardown or routing failure.

### Expected

Opening the panel should preserve active Bluetooth audio. Automatic discovery should remain available when no Bluetooth audio sink is connected, with an explicit way to scan when the user needs to pair another device despite the possible interruption.

### Proposed behavior

- Detect a connected Bluetooth audio sink from PipeWire.
- Keep automatic discovery off while that sink exists.
- Show an `Audio protected` status and a session-only `Scan anyway` action.
- Clearly warn that the one-time scan may interrupt audio.
- Stop the forced scan manually or automatically when the panel closes.

This keeps the normal zero-click discovery behavior for users who are not streaming audio while making the disruptive transition intentional for those who are.

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 04:42 UTC