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

Migration 1786643346 loops after reboot on stale Chromium SingletonLock

Reported by rfmyrick · filed Aug 14, 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

Migration 1786643346 loops after reboot on stale Chromium SingletonLockrevision 1 · captured 2026-09-28 21:29 UTC via poll

System details

  • Omarchy: 4.0.0rc5-1
  • Channel: rc
  • Kernel: 7.1.8-arch1-3
  • CPU: AMD Ryzen AI MAX+ PRO 395
  • GPU: AMD Strix Halo / Radeon 8060S

What's wrong?

Migration 1786643346 repeatedly asks me to close the browser windows and continue even after Chromium is completely stopped. Pressing Continue just returns to the same prompt.

This happened after a reboot. The affected Chromium profile still contained singleton symlinks from the previous session:

SingletonLock -> <hostname>-112033
SingletonSocket -> /tmp/org.chromium.Chromium.<token>/SingletonSocket

There was no Chromium-family process running, PID 112033 no longer existed, and the socket target under /tmp no longer existed.

The migration nevertheless considers the profile open because profile_open() tests -L "$profile/SingletonLock". That remains true for a stale symlink, so the while affected_profile_open loop cannot make progress regardless of how many times Continue is selected.

After moving the three stale Singleton* symlinks out of ~/.config/chromium, omarchy-migrate immediately completed successfully. I verified that no migrations remained pending and that Alt+Shift+L was rebound to the pinned Copy URL extension id bgpiichlckmfanooecilcjemknkcpngb.

Steps to reproduce

  1. Have a Chromium profile affected by migration 1786643346.
  2. Leave a stale SingletonLock symlink in the profile whose encoded PID is no longer alive, plus a SingletonSocket symlink whose /tmp target no longer exists. A reboot left this state on my machine.
  3. Ensure Chromium is not running.
  4. Run omarchy-migrate.
  5. Select Continue at the close-browser prompt.

Expected behavior

The migration should distinguish a stale singleton lock from a live browser and proceed when the encoded local PID is dead and the socket target is absent. Alternatively, it could safely remove confirmed-stale singleton links before testing the profile.

Actual behavior

The prompt repeats indefinitely because the existence of the SingletonLock symlink alone is treated as an open profile.

Related work

  • #6841 / #6842 fixed the hidden-prompt failure for this migration, but this report concerns a visible prompt that repeats because of stale lock state.
  • #6837 introduced profile-specific lock detection and explicitly treats dangling SingletonLock symlinks as open.
  • #4149 is prior evidence that stale Chromium SingletonLock files can occur on Omarchy.
View raw text
### System details

- Omarchy: `4.0.0rc5-1`
- Channel: `rc`
- Kernel: `7.1.8-arch1-3`
- CPU: AMD Ryzen AI MAX+ PRO 395
- GPU: AMD Strix Halo / Radeon 8060S

### What's wrong?

Migration `1786643346` repeatedly asks me to close the browser windows and continue even after Chromium is completely stopped. Pressing Continue just returns to the same prompt.

This happened after a reboot. The affected Chromium profile still contained singleton symlinks from the previous session:

```text
SingletonLock -> <hostname>-112033
SingletonSocket -> /tmp/org.chromium.Chromium.<token>/SingletonSocket
```

There was no Chromium-family process running, PID `112033` no longer existed, and the socket target under `/tmp` no longer existed.

The migration nevertheless considers the profile open because `profile_open()` tests `-L "$profile/SingletonLock"`. That remains true for a stale symlink, so the `while affected_profile_open` loop cannot make progress regardless of how many times Continue is selected.

After moving the three stale `Singleton*` symlinks out of `~/.config/chromium`, `omarchy-migrate` immediately completed successfully. I verified that no migrations remained pending and that `Alt+Shift+L` was rebound to the pinned Copy URL extension id `bgpiichlckmfanooecilcjemknkcpngb`.

### Steps to reproduce

1. Have a Chromium profile affected by migration `1786643346`.
2. Leave a stale `SingletonLock` symlink in the profile whose encoded PID is no longer alive, plus a `SingletonSocket` symlink whose `/tmp` target no longer exists. A reboot left this state on my machine.
3. Ensure Chromium is not running.
4. Run `omarchy-migrate`.
5. Select Continue at the close-browser prompt.

### Expected behavior

The migration should distinguish a stale singleton lock from a live browser and proceed when the encoded local PID is dead and the socket target is absent. Alternatively, it could safely remove confirmed-stale singleton links before testing the profile.

### Actual behavior

The prompt repeats indefinitely because the existence of the `SingletonLock` symlink alone is treated as an open profile.

### Related work

- #6841 / #6842 fixed the hidden-prompt failure for this migration, but this report concerns a visible prompt that repeats because of stale lock state.
- #6837 introduced profile-specific lock detection and explicitly treats dangling `SingletonLock` symlinks as open.
- #4149 is prior evidence that stale Chromium `SingletonLock` files can occur on Omarchy.

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:05 UTC