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.
OpenClaw won't open on slower machines: launcher's 10 s dashboard probe times out while the gateway is healthy
Reported by filip982 · filed Oct 3, 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 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
System details
Mac mini 2012 (Macmini6,2), Intel Core i7-3720QM (Ivy Bridge, 4c/8t), 16 GB RAM, Intel HD 4000. Omarchy 4.0.4-1, openclaw 2026.9.6-2 (omarchy repo), OpenClaw 2026.9.6 (eb377ac) in ~/.openclaw.
What's wrong?
On slower hardware OpenClaw never opens from the app grid, even though its gateway is running and healthy. omarchy-launch-openclaw decides whether the gateway is up with timeout 10 openclaw dashboard --json, and on this machine that CLI call alone takes ~10.3–11.2 s with the gateway already up and the system otherwise idle (it succeeds with rc=0 when given longer). The timeout kills it every time, so dashboard_url always comes back empty.
The launcher then retries for up to 30 iterations, each one hitting the same 10 s limit, before printing "OpenClaw's gateway did not come up". Clicking the app again while that is happening starts another launcher; six were running at once here, and the extra load made each check slower still.
The same timeout 10 openclaw dashboard --json is used by omarchy-openclaw-onboard (gateway_answers and gateway_ready, lines 34 and 88 on master), so on such a machine onboarding cannot see its own gateway come up either, and falls through to its 180 s "did not come up" exit.
Measured with the gateway active (openclaw gateway status: running, connectivity probe ok):
$ time timeout 60 openclaw dashboard --json # x2, launchers stopped, load ~2.9
rc=0 took 10264ms
rc=0 took 10471msSteps to reproduce
- On a machine where
openclaw dashboard --jsontakes over 10 s (an older CPU such as Ivy Bridge), install OpenClaw from Install > AI and finish onboarding. - Launch OpenClaw from the app grid.
- No window opens;
pgrep -af omarchy-launch-openclawshows the launcher looping, whilesystemctl --user status openclaw-gatewayis active andopenclaw dashboard --json(run without a timeout) returnsok: truewith a URL.
Expected
The launcher opens the Control UI once the gateway answers, however slow the CLI is to start.
Workaround / possible fix
A local copy of omarchy-launch-openclaw with timeout 30 in dashboard_url, used as the .desktop Exec, opens the window in ~12 s. Raising the probe timeouts (launcher and onboarding) to around 30 s, or making them configurable, would fix it. It may also be worth guarding against a second launcher starting while one is already waiting.
Related, already fixed on master
While reproducing this I also hit two issues that #13296 resolves (it merged after 4.0.4): the 2026.9.6-2 package arrived before the scripts that seed ~/.openclaw from it, so on 4.0.4 there is no openclaw command at all after install; and onboarding got stuck at the Telegram channel step, which matches the channel-search terminal bug #13296 describes. Noting them only so they aren't re-reported.
Filed by Claude Opus 5.5 via Claude Code.
View raw text
### System details Mac mini 2012 (Macmini6,2), Intel Core i7-3720QM (Ivy Bridge, 4c/8t), 16 GB RAM, Intel HD 4000. Omarchy 4.0.4-1, `openclaw` 2026.9.6-2 (omarchy repo), OpenClaw 2026.9.6 (eb377ac) in `~/.openclaw`. ### What's wrong? On slower hardware OpenClaw never opens from the app grid, even though its gateway is running and healthy. `omarchy-launch-openclaw` decides whether the gateway is up with `timeout 10 openclaw dashboard --json`, and on this machine that CLI call alone takes ~10.3–11.2 s with the gateway already up and the system otherwise idle (it succeeds with rc=0 when given longer). The timeout kills it every time, so `dashboard_url` always comes back empty. The launcher then retries for up to 30 iterations, each one hitting the same 10 s limit, before printing "OpenClaw's gateway did not come up". Clicking the app again while that is happening starts another launcher; six were running at once here, and the extra load made each check slower still. The same `timeout 10 openclaw dashboard --json` is used by `omarchy-openclaw-onboard` (`gateway_answers` and `gateway_ready`, lines 34 and 88 on master), so on such a machine onboarding cannot see its own gateway come up either, and falls through to its 180 s "did not come up" exit. Measured with the gateway active (`openclaw gateway status`: running, connectivity probe ok): ``` $ time timeout 60 openclaw dashboard --json # x2, launchers stopped, load ~2.9 rc=0 took 10264ms rc=0 took 10471ms ``` ### Steps to reproduce 1. On a machine where `openclaw dashboard --json` takes over 10 s (an older CPU such as Ivy Bridge), install OpenClaw from Install > AI and finish onboarding. 2. Launch OpenClaw from the app grid. 3. No window opens; `pgrep -af omarchy-launch-openclaw` shows the launcher looping, while `systemctl --user status openclaw-gateway` is active and `openclaw dashboard --json` (run without a timeout) returns `ok: true` with a URL. ### Expected The launcher opens the Control UI once the gateway answers, however slow the CLI is to start. ### Workaround / possible fix A local copy of `omarchy-launch-openclaw` with `timeout 30` in `dashboard_url`, used as the `.desktop` Exec, opens the window in ~12 s. Raising the probe timeouts (launcher and onboarding) to around 30 s, or making them configurable, would fix it. It may also be worth guarding against a second launcher starting while one is already waiting. ### Related, already fixed on master While reproducing this I also hit two issues that #13296 resolves (it merged after 4.0.4): the 2026.9.6-2 package arrived before the scripts that seed `~/.openclaw` from it, so on 4.0.4 there is no `openclaw` command at all after install; and onboarding got stuck at the Telegram channel step, which matches the channel-search terminal bug #13296 describes. Noting them only so they aren't re-reported. --- Filed by Claude Opus 5.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 21:04 UTC