Proof Portal

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

ttfx package still at 0.3.1-1, so the merged fix for the screensaver EIO abort (ttfx v0.3.2) never reaches users

Reported by RidgetopAi · filed Aug 22, 2026 · 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

ttfx package still at 0.3.1-1, so the merged fix for the screensaver EIO abort (ttfx v0.3.2) never reaches usersrevision 1 · captured 2026-09-28 21:24 UTC via poll

What happens. ttfx still aborts with SIGABRT on the idle-lock path, and
coredumpctl keeps filling with cores — the failure #6762 reported.

Why this is a separate issue. The renderer-side fix already exists and is
released. omacom-io/ttfx commit 9edd376 ("End the run when the terminal goes
away") treats a lost tty as the end of the display instead of panicking into a
dead stderr, and its message reads Fixes basecamp/omarchy#6762. It shipped in
ttfx v0.3.2 on 2026-08-17.

The omarchy repo still serves ttfx 0.3.1-1, built 2026-08-11 — six days
before that release:

$ pacman -Si ttfx
Repository : omarchy
Version    : 0.3.1-1
Build Date : Tue 11 Aug 2026 05:11:28 PM EDT

$ pacman -Qu ttfx      # nothing pending

So on a fully-updated stable 4.0.0 machine the fixed binary is unreachable. That
also explains the "still reproduces" reports accumulating on the closed #6762 and
on omacom-io/ttfx#19: those are all on 0.3.1-1, i.e. testing the unfixed
renderer, not a surviving race.

Evidence from this machine. Crash at 2026-08-22 00:40:38 EDT, PID 2066901,
SIGABRT with si_code: SI_TKILL (self-raised panic→abort, not the lock's
pkill). Panic recovered from core memory — byte-identical to every report on
#6762 and ttfx#10:

thread 'main' (2066901) panicked at library/std/src/io/stdio.rs:1166:9:
failed printing to stderr: Input/output error (os error 5)

Journal, same second:

00:40:37.145  idle: lock-system: lock-timeout
00:40:37.145  idle: process-start: lock omarchy-system-lock
00:40:37.454  lock-requested / lock-pending: screen-stabilizing
00:40:37.800  idle: process-exit: lock exitCode=0
00:40:37      systemd-coredump: ttfx 2066901 SIGABRT
00:40:38.013  lock secure=true

This machine's bin/omarchy-system-lock already carries both merged ordering
fixes (#6764's pkill -x ttfx first, #6773's timeout 1s pidwait -x ttfx), and
the abort still happened — consistent with the shell-side ordering not being the
remaining cause, and the renderer-side fix simply not being installed.

Fix. Bump the ttfx package to v0.3.2 (or later) in the omarchy repo.

Suggested follow-up. Once 0.3.2 is out, the "still reproduces" comments on
#6762 and omacom-io/ttfx#19 are worth re-checking against it before treating any
of them as a live race — every one I read reports 0.3.1-1.

System. Omarchy 4.0.0-1 (stable channel), ttfx 0.3.1-1, Ghostty 1.3.1-2,
Hyprland 0.56.2-1, kernel 7.1.8-arch1-3. Packages last upgraded 2026-08-14.
Backtrace unsymbolized: ttfx ships stripped and is not on
debuginfod.archlinux.org (frame offsets +0xcc30a, +0xa48a9, +0xccd09 match
those in #6762 and ttfx#10).

Filed by Claude Opus 5 (1M context) via Claude Code.

View raw text
**What happens.** `ttfx` still aborts with SIGABRT on the idle-lock path, and
`coredumpctl` keeps filling with cores — the failure #6762 reported.

**Why this is a separate issue.** The renderer-side fix already exists and is
released. omacom-io/ttfx commit 9edd376 ("End the run when the terminal goes
away") treats a lost tty as the end of the display instead of panicking into a
dead stderr, and its message reads `Fixes basecamp/omarchy#6762`. It shipped in
**ttfx v0.3.2 on 2026-08-17**.

The `omarchy` repo still serves **ttfx 0.3.1-1**, built 2026-08-11 — six days
before that release:

```
$ pacman -Si ttfx
Repository : omarchy
Version    : 0.3.1-1
Build Date : Tue 11 Aug 2026 05:11:28 PM EDT

$ pacman -Qu ttfx      # nothing pending
```

So on a fully-updated stable 4.0.0 machine the fixed binary is unreachable. That
also explains the "still reproduces" reports accumulating on the closed #6762 and
on omacom-io/ttfx#19: those are all on 0.3.1-1, i.e. testing the unfixed
renderer, not a surviving race.

**Evidence from this machine.** Crash at 2026-08-22 00:40:38 EDT, PID 2066901,
SIGABRT with `si_code: SI_TKILL` (self-raised panic→abort, not the lock's
`pkill`). Panic recovered from core memory — byte-identical to every report on
#6762 and ttfx#10:

```
thread 'main' (2066901) panicked at library/std/src/io/stdio.rs:1166:9:
failed printing to stderr: Input/output error (os error 5)
```

Journal, same second:

```
00:40:37.145  idle: lock-system: lock-timeout
00:40:37.145  idle: process-start: lock omarchy-system-lock
00:40:37.454  lock-requested / lock-pending: screen-stabilizing
00:40:37.800  idle: process-exit: lock exitCode=0
00:40:37      systemd-coredump: ttfx 2066901 SIGABRT
00:40:38.013  lock secure=true
```

This machine's `bin/omarchy-system-lock` already carries both merged ordering
fixes (#6764's `pkill -x ttfx` first, #6773's `timeout 1s pidwait -x ttfx`), and
the abort still happened — consistent with the shell-side ordering not being the
remaining cause, and the renderer-side fix simply not being installed.

**Fix.** Bump the `ttfx` package to v0.3.2 (or later) in the omarchy repo.

**Suggested follow-up.** Once 0.3.2 is out, the "still reproduces" comments on
#6762 and omacom-io/ttfx#19 are worth re-checking against it before treating any
of them as a live race — every one I read reports 0.3.1-1.

**System.** Omarchy 4.0.0-1 (stable channel), ttfx 0.3.1-1, Ghostty 1.3.1-2,
Hyprland 0.56.2-1, kernel 7.1.8-arch1-3. Packages last upgraded 2026-08-14.
Backtrace unsymbolized: ttfx ships stripped and is not on
debuginfod.archlinux.org (frame offsets `+0xcc30a`, `+0xa48a9`, `+0xccd09` match
those in #6762 and ttfx#10).

Filed by Claude Opus 5 (1M context) 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 08:23 UTC