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.
Ghostty terminal keybind launches single-instance mode that can crash all windows
Reported by nikitalbnv · filed Apr 25, 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
Summary
On my Omarchy install, the terminal keybind launches Ghostty through xdg-terminal-exec. That uses the Ghostty desktop file, which launches Ghostty with --gtk-single-instance=true.
When I run OpenCode inside tmux from a Ghostty window opened this way, Ghostty can crash. Because it is single-instance mode, all Ghostty windows from that shared process can close.
If I launch Ghostty by typing ghostty in another terminal, the same OpenCode plus tmux flow does not crash.
What I expected
The terminal keybind should launch Ghostty the same way as typing ghostty, or at least should not force a mode that can take down every Ghostty window when one surface crashes.
What happened
The keybind path launches:
/usr/bin/ghostty --gtk-single-instance=trueTyping ghostty launches:
/usr/bin/ghosttyThe --gtk-single-instance=true path is the one that crashes all shared Ghostty windows for me.
Reproduction
On Omarchy with Ghostty as the default terminal:
- Press the terminal keybind.
- Run:
tmux
opencode- Interact with OpenCode.
- Ghostty can crash. In single-instance mode, other Ghostty windows from the same process can close too.
Direct launch works:
ghosttyThen:
tmux
opencodeThis does not crash for me.
Evidence
Omarchy keybind uses xdg-terminal-exec:
$terminal = uwsm-app -- xdg-terminal-exec
bindd = SUPER, BACKSPACE, Terminal, exec, $terminal --working-directory="$(omarchy-cmd-terminal-cwd)"xdg-terminal-exec --print-cmd returns:
/usr/bin/ghostty
--gtk-single-instance=trueThe selected desktop file is:
/usr/share/applications/com.mitchellh.ghostty.desktopIt has:
Exec=/usr/bin/ghostty --gtk-single-instance=trueLocal workaround
I added a user desktop file override:
~/.local/share/applications/com.mitchellh.ghostty.desktopWith:
Exec=/usr/bin/ghostty
DBusActivatable=falseAfter that, xdg-terminal-exec --print-cmd returns:
/usr/bin/ghosttyNow the terminal keybind works and the OpenCode plus tmux flow is stable.
Versions
Omarchy on Arch Linux
Hyprland on Wayland
Ghostty 1.3.1-arch2
tmux 3.6a
OpenCode 1.14.25Related
I also opened a Ghostty discussion because Ghostty should not segfault either:
View raw text
## Summary On my Omarchy install, the terminal keybind launches Ghostty through `xdg-terminal-exec`. That uses the Ghostty desktop file, which launches Ghostty with `--gtk-single-instance=true`. When I run OpenCode inside tmux from a Ghostty window opened this way, Ghostty can crash. Because it is single-instance mode, all Ghostty windows from that shared process can close. If I launch Ghostty by typing `ghostty` in another terminal, the same OpenCode plus tmux flow does not crash. ## What I expected The terminal keybind should launch Ghostty the same way as typing `ghostty`, or at least should not force a mode that can take down every Ghostty window when one surface crashes. ## What happened The keybind path launches: ```text /usr/bin/ghostty --gtk-single-instance=true ``` Typing `ghostty` launches: ```text /usr/bin/ghostty ``` The `--gtk-single-instance=true` path is the one that crashes all shared Ghostty windows for me. ## Reproduction On Omarchy with Ghostty as the default terminal: 1. Press the terminal keybind. 2. Run: ```bash tmux opencode ``` 3. Interact with OpenCode. 4. Ghostty can crash. In single-instance mode, other Ghostty windows from the same process can close too. Direct launch works: ```bash ghostty ``` Then: ```bash tmux opencode ``` This does not crash for me. ## Evidence Omarchy keybind uses `xdg-terminal-exec`: ```text $terminal = uwsm-app -- xdg-terminal-exec bindd = SUPER, BACKSPACE, Terminal, exec, $terminal --working-directory="$(omarchy-cmd-terminal-cwd)" ``` `xdg-terminal-exec --print-cmd` returns: ```text /usr/bin/ghostty --gtk-single-instance=true ``` The selected desktop file is: ```text /usr/share/applications/com.mitchellh.ghostty.desktop ``` It has: ```text Exec=/usr/bin/ghostty --gtk-single-instance=true ``` ## Local workaround I added a user desktop file override: ```text ~/.local/share/applications/com.mitchellh.ghostty.desktop ``` With: ```text Exec=/usr/bin/ghostty DBusActivatable=false ``` After that, `xdg-terminal-exec --print-cmd` returns: ```text /usr/bin/ghostty ``` Now the terminal keybind works and the OpenCode plus tmux flow is stable. ## Versions ```text Omarchy on Arch Linux Hyprland on Wayland Ghostty 1.3.1-arch2 tmux 3.6a OpenCode 1.14.25 ``` ## Related I also opened a Ghostty discussion because Ghostty should not segfault either: https://github.com/ghostty-org/ghostty/discussions/12460
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 02:51 UTC