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-5001GitHub issuePublicReceived

~/.config/chromium-flags.conf is force-injected into every chromium launch, crashing headless/automation invocations (Playwright etc.) with SIGTRAP

Reported by dutchbase · filed Sep 10, 2026Closed upstream on 2026-09-21 by bjarneo via an automated message, as a duplicate of #8394 (R-1420). GitHub close reason: completed.

Open at source
Received and recorded verbatim. Nothing has been checked yet.

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?
Not yet mapped to any requirement or component.
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?
Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.

Original report

~/.config/chromium-flags.conf is force-injected into every chromium launch, crashing headless/automation invocations (Playwright etc.) with SIGTRAPrevision 1 · captured 2026-10-04 12:10 UTC via poll

System details

  • Omarchy: 4.0.2-1
  • Kernel: Linux 7.1.9-arch1-2
  • Hyprland: 0.56.2
  • chromium: 151.0.7922.173-1

What's wrong?

Omarchy's default ~/.config/chromium-flags.conf is read by Arch's /usr/bin/chromium
wrapper and unconditionally prepended to every invocation of chromium, including
ones launched programmatically for browser automation (e.g. Playwright), not just the
desktop app. The shipped defaults are:

--ozone-platform=wayland
--ozone-platform-hint=wayland
--password-store=gnome-libsecret
--enable-features=TouchpadOverscrollHistoryNavigation
--load-extension=/usr/share/omarchy/default/chromium/extensions/copy-url,.../yt-dlp,.../whatsapp-slim

When a tool launches chromium headlessly (`--headless --ozone-platform=headless
--no-startup-window --user-data-dir=/tmp/...`), these flags get merged in ahead of
it, producing a conflicting, duplicated --ozone-platform (wayland then
headless) and forcing three desktop extensions to load into a windowless
automation profile. Chromium hits an internal startup assertion and crashes with
SIGTRAP (signal 5, SI_KERNEL) before creating any window.

Confirmed via coredumpctl: 7 crashes reproduced across two separate days, all with
byte-identical relative stack offsets (same code path every time), all headless
processes with the same conflicting flag set, e.g.:

Stack trace of thread 3072:
#0 chromium + 0x10c634f1
#1 chromium + 0x10c5a234
#2 chromium + 0x1d148ee
#3 chromium + 0x83e0557
#4 chromium + 0x83de156
#5 ChromeMain (chromium + 0x1d11859)

No OOM, no GPU-driver involvement, no user data lost (the profile is an ephemeral
/tmp/playwright_chromiumdev_profile-* dir).

Steps to reproduce

  1. On a stock Omarchy install with the default ~/.config/chromium-flags.conf.
  2. Launch chromium headlessly, e.g. via Playwright:

`chromium --headless --ozone-platform=headless --no-startup-window --no-sandbox
--user-data-dir=/tmp/testprofile --remote-debugging-pipe`
3. Observe the process crash immediately with SIGTRAP instead of starting headless.

Expected behavior

The wrapper's user-flags injection should not fight with flags the caller
explicitly passed (at minimum, not duplicate --ozone-platform), and/or Omarchy's
default chromium-flags.conf shouldn't force desktop-only behavior (Wayland ozone
backend, extension loading) onto headless/automation invocations.

Actual behavior

Chromium crashes on startup with SIGTRAP any time it's launched headlessly on this
machine, because Omarchy's default flags conflict with the caller's headless flags.

Related

#7642 is a similar env-var-forcing issue (OZONE_PLATFORM=wayland breaking some
Electron apps) but is a different mechanism (global env var vs. wrapper-injected
CLI flags) and a different symptom (missing window vs. SIGTRAP crash) — filing
separately.

Filed by Claude Sonnet 5 via Claude Code.

View raw text
## System details

- Omarchy: 4.0.2-1
- Kernel: Linux 7.1.9-arch1-2
- Hyprland: 0.56.2
- chromium: 151.0.7922.173-1

## What's wrong?

Omarchy's default `~/.config/chromium-flags.conf` is read by Arch's `/usr/bin/chromium`
wrapper and unconditionally prepended to *every* invocation of `chromium`, including
ones launched programmatically for browser automation (e.g. Playwright), not just the
desktop app. The shipped defaults are:

    --ozone-platform=wayland
    --ozone-platform-hint=wayland
    --password-store=gnome-libsecret
    --enable-features=TouchpadOverscrollHistoryNavigation
    --load-extension=/usr/share/omarchy/default/chromium/extensions/copy-url,.../yt-dlp,.../whatsapp-slim

When a tool launches chromium headlessly (`--headless --ozone-platform=headless
--no-startup-window --user-data-dir=/tmp/...`), these flags get merged in ahead of
it, producing a conflicting, duplicated `--ozone-platform` (`wayland` then
`headless`) and forcing three desktop extensions to load into a windowless
automation profile. Chromium hits an internal startup assertion and crashes with
SIGTRAP (signal 5, SI_KERNEL) before creating any window.

Confirmed via `coredumpctl`: 7 crashes reproduced across two separate days, all with
byte-identical relative stack offsets (same code path every time), all headless
processes with the same conflicting flag set, e.g.:

    Stack trace of thread 3072:
    #0  chromium + 0x10c634f1
    #1  chromium + 0x10c5a234
    #2  chromium + 0x1d148ee
    #3  chromium + 0x83e0557
    #4  chromium + 0x83de156
    #5  ChromeMain (chromium + 0x1d11859)

No OOM, no GPU-driver involvement, no user data lost (the profile is an ephemeral
`/tmp/playwright_chromiumdev_profile-*` dir).

## Steps to reproduce

1. On a stock Omarchy install with the default `~/.config/chromium-flags.conf`.
2. Launch chromium headlessly, e.g. via Playwright:
   `chromium --headless --ozone-platform=headless --no-startup-window --no-sandbox
   --user-data-dir=/tmp/testprofile --remote-debugging-pipe`
3. Observe the process crash immediately with SIGTRAP instead of starting headless.

## Expected behavior

The wrapper's user-flags injection should not fight with flags the caller
explicitly passed (at minimum, not duplicate `--ozone-platform`), and/or Omarchy's
default `chromium-flags.conf` shouldn't force desktop-only behavior (Wayland ozone
backend, extension loading) onto headless/automation invocations.

## Actual behavior

Chromium crashes on startup with SIGTRAP any time it's launched headlessly on this
machine, because Omarchy's default flags conflict with the caller's headless flags.

## Related

#7642 is a similar env-var-forcing issue (`OZONE_PLATFORM=wayland` breaking some
Electron apps) but is a different mechanism (global env var vs. wrapper-injected
CLI flags) and a different symptom (missing window vs. SIGTRAP crash) — filing
separately.

---
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.

No decision has been recorded yet.