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

Ghostty terminal keybind launches single-instance mode that can crash all windows

Reported by nikitalbnv · filed Apr 25, 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

Ghostty terminal keybind launches single-instance mode that can crash all windowsrevision 1 · captured 2026-09-28 21:29 UTC via poll

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=true

Typing ghostty launches:

/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:
tmux
opencode
  1. Interact with OpenCode.
  2. Ghostty can crash. In single-instance mode, other Ghostty windows from the same process can close too.

Direct launch works:

ghostty

Then:

tmux
opencode

This 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=true

The selected desktop file is:

/usr/share/applications/com.mitchellh.ghostty.desktop

It has:

Exec=/usr/bin/ghostty --gtk-single-instance=true

Local workaround

I added a user desktop file override:

~/.local/share/applications/com.mitchellh.ghostty.desktop

With:

Exec=/usr/bin/ghostty
DBusActivatable=false

After that, xdg-terminal-exec --print-cmd returns:

/usr/bin/ghostty

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

Related

I also opened a Ghostty discussion because Ghostty should not segfault either:

https://github.com/ghostty-org/ghostty/discussions/12460

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