Proof Portal

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

Stale Brave Origin SingletonLock shipped in Try Omarchy image prevents the browser from starting (#4149 regression)

Reported by m-a-mohsen · filed Sep 7, 2026 · open at source

Open at source

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

Stale Brave Origin SingletonLock shipped in Try Omarchy image prevents the browser from starting (#4149 regression)revision 1 · captured 2026-09-28 21:23 UTC via poll

System details

try-omarchy-runtime 4.0.2-1
brave-origin-bin 1:1.94.121-1
Try Omarchy guest under Hyper-V

What's wrong?

Same class of bug as #4149, now for Brave Origin. On a fresh Try Omarchy guest,
Brave Origin will not start. Launched from the menu it does nothing at all; from a
terminal:

ERROR:process_singleton_posix.cc:365] The profile appears to be in use by
another Brave process (38449) on another computer (omarchy-factory). Brave has
locked the profile so that it doesn't get corrupted.
ERROR:process_singleton_dialog_linux.cc:93] Cannot show profile-in-use dialog:
no system dialog tool (zenity, kdialog, xmessage) was found.

The menu launch fails silently because none of zenity/kdialog/xmessage are
installed to show the recovery dialog.

The image ships a populated Brave Origin profile with a live lock from the build
host baked in:

~/.config/BraveSoftware/Brave-Origin/SingletonLock -> omarchy-factory-38449
~/.config/BraveSoftware/Brave-Origin/SingletonCookie -> 14889059458302430602
~/.config/BraveSoftware/Brave-Origin/SingletonSocket -> /tmp/org.chromium.Chromium.bMA4sD/SingletonSocket

omarchy-factory is the build host; PID 38449 doesn't exist on the guest and the
/tmp socket is gone. The profile dir also contains Local State, so brave-origin
was actually run during image creation and its profile captured into the image.
#4149 fixed this for ~/.config/chromium in the 3.3.0 ISO; the Brave Origin
profile dir isn't covered, or the Try Omarchy factory build takes a different path.

Workaround

rm ~/.config/BraveSoftware/Brave-Origin/Singleton{Lock,Cookie,Socket}

Suggested fix

Don't launch browsers during image build, or strip ~/.config/*/Singleton*
(chromium, BraveSoftware/*, and any other browser profile dirs) during image
finalization.

Filed by Claude Sonnet 5 via Claude Code.

View raw text

### System details

- try-omarchy-runtime 4.0.2-1
- brave-origin-bin 1:1.94.121-1
- Try Omarchy guest under Hyper-V

### What's wrong?

Same class of bug as #4149, now for Brave Origin. On a fresh Try Omarchy guest,
Brave Origin will not start. Launched from the menu it does nothing at all; from a
terminal:

The menu launch fails silently because none of zenity/kdialog/xmessage are
installed to show the recovery dialog.

The image ships a populated Brave Origin profile with a live lock from the build
host baked in:

`omarchy-factory` is the build host; PID 38449 doesn't exist on the guest and the
`/tmp` socket is gone. The profile dir also contains `Local State`, so brave-origin
was actually run during image creation and its profile captured into the image.
#4149 fixed this for `~/.config/chromium` in the 3.3.0 ISO; the Brave Origin
profile dir isn't covered, or the Try Omarchy factory build takes a different path.

### Workaround

rm ~/.config/BraveSoftware/Brave-Origin/Singleton{Lock,Cookie,Socket}

### Suggested fix

Don't launch browsers during image build, or strip `~/.config/*/Singleton*`
(chromium, BraveSoftware/*, and any other browser profile dirs) during image
finalization.

Filed by Claude Sonnet 5 via Claude Code.

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 11:03 UTC

Proof

History & reports

Reference