Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA 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.
Hibernation doesn't hibernate. The battery goes dead when checked on next day
Reported by hvsharma · filed Sep 18, 2026 · open at source
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 arbitration
- 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 arbitration — agents disagreed and an independent third agent decided — see the decision.
Original report
System details
Microsoft Surface Laptop 3 - Intel Core 1065G7, 16 GB RAM
What's wrong?
When I hibernated the system and went away, the battery was found dead both times when I checked next day.
I have experienced it 2 times so far.
Third time when I turned on the system, it was at 5%. Moreover, when I resumed, I saw that there was a crash reported by Omarchy (notification):
A process crashed on this Omarchy machine and I want to know why.
What systemd-coredump recorded:
process: wireplumber
PID: 953
binary: /usr/bin/wireplumber
signal: SIGSEGV
time: Fri 2026-09-18 19:08:19 BST
Use the diagnose-crash skill: it covers how to investigate, what to report, and
when a crash is worth reporting upstream to Omarchy. If your harness has no skill
mechanism, read the skill files directly and follow them instead:
/usr/share/omarchy/default/agents/skills/diagnose-crash/SKILL.md
Cause: wireplumber crashed with SIGSEGV in the PipeWire Bluetooth SPA plugin:
/usr/lib/spa-0.2/bluez5/libspa-bluez5.so + 0x4fd98
The backtrace shows WirePlumber’s Lua policy loading a BlueZ SPA device through PipeWire immediately after hibernation resumed:
libspa-bluez5.so
libpipewire-0.3.so
wp_spa_device_new_from_spa_factory()
WirePlumber Lua scripting
The timeline is strong evidence of a hibernate/resume Bluetooth race:
• The system resumed from hibernation at 19:08:16 .
• Bluetooth audio endpoints were being unregistered and the Intel Bluetooth firmware was restarting.
• WirePlumber faulted at 19:08:16.982 while loading the BlueZ plugin.
• The core-processing message completed at 19:08:19 , explaining the timestamp discrepancy in the notification.
What the evidence rules out: this was not an OOM kill—there was about 8 GiB available RAM and 29 GiB free swap. The other threads were mostly idle in PipeWire/GLib polling loops, and no third-party extension or Omarchy component appears in the crashing path. Local symbolization could not resolve the stripped BlueZ plugin function further.
WirePlumber restarted automatically at 19:08:20 and is currently running. There is only one recorded WirePlumber crash, so recurrence is not established. The likely impact was temporary loss/reset of Bluetooth or audio devices; there is no evidence of user-file loss.
This is most likely an upstream PipeWire/WirePlumber BlueZ resume bug, not an Omarchy bug. It is therefore not appropriate to file against Omarchy based on this evidence. If it recurs, update the Arch audio stack and report it to PipeWire/WirePlumber or the relevant Arch package, including the versions present here: WirePlumber 0.5.17-1 , PipeWire 1.6.8-1 , BlueZ 5.87-2 .
View raw text
### System details Microsoft Surface Laptop 3 - Intel Core 1065G7, 16 GB RAM ### What's wrong? When I hibernated the system and went away, the battery was found dead both times when I checked next day. I have experienced it 2 times so far. Third time when I turned on the system, it was at 5%. Moreover, when I resumed, I saw that there was a crash reported by Omarchy (notification): A process crashed on this Omarchy machine and I want to know why. What systemd-coredump recorded: process: wireplumber PID: 953 binary: /usr/bin/wireplumber signal: SIGSEGV time: Fri 2026-09-18 19:08:19 BST Use the diagnose-crash skill: it covers how to investigate, what to report, and when a crash is worth reporting upstream to Omarchy. If your harness has no skill mechanism, read the skill files directly and follow them instead: /usr/share/omarchy/default/agents/skills/diagnose-crash/SKILL.md Cause: wireplumber crashed with SIGSEGV in the PipeWire Bluetooth SPA plugin: /usr/lib/spa-0.2/bluez5/libspa-bluez5.so + 0x4fd98 The backtrace shows WirePlumber’s Lua policy loading a BlueZ SPA device through PipeWire immediately after hibernation resumed: libspa-bluez5.so libpipewire-0.3.so wp_spa_device_new_from_spa_factory() WirePlumber Lua scripting The timeline is strong evidence of a hibernate/resume Bluetooth race: • The system resumed from hibernation at 19:08:16 . • Bluetooth audio endpoints were being unregistered and the Intel Bluetooth firmware was restarting. • WirePlumber faulted at 19:08:16.982 while loading the BlueZ plugin. • The core-processing message completed at 19:08:19 , explaining the timestamp discrepancy in the notification. What the evidence rules out: this was not an OOM kill—there was about 8 GiB available RAM and 29 GiB free swap. The other threads were mostly idle in PipeWire/GLib polling loops, and no third-party extension or Omarchy component appears in the crashing path. Local symbolization could not resolve the stripped BlueZ plugin function further. WirePlumber restarted automatically at 19:08:20 and is currently running. There is only one recorded WirePlumber crash, so recurrence is not established. The likely impact was temporary loss/reset of Bluetooth or audio devices; there is no evidence of user-file loss. This is most likely an upstream PipeWire/WirePlumber BlueZ resume bug, not an Omarchy bug. It is therefore not appropriate to file against Omarchy based on this evidence. If it recurs, update the Arch audio stack and report it to PipeWire/WirePlumber or the relevant Arch package, including the versions present here: WirePlumber 0.5.17-1 , PipeWire 1.6.8-1 , BlueZ 5.87-2 .
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 arbitration · 2026-10-10 05:53 UTC