## System details

- Omarchy 4.0.2-1 (`omarchy-settings` 4.0.2-1)
- Hyprland 0.56.2-1, foot 1.27.0-2
- xdg-utils 1.2.1-2, xdg-terminal-exec 0.14.3-1, neovim 0.12.5-1
- AMD EPYC 7551 / Virtio GPU / kernel 7.1.9-arch1-2 (VM guest)

## What's wrong

`omarchy-settings` ships `/usr/share/applications/mimeapps.list`, which maps `text/plain` and 17 other text types to `nvim.desktop`. That entry comes from the `neovim` package and is `Terminal=true`:

```
Exec=nvim %F
Terminal=true
```

Through a **GIO-based launcher** (Nautilus and friends) this is fine — GIO supplies the terminal.

Through **bare `xdg-open`** — what most non-GTK apps call — nothing supplies a terminal. `nvim` starts headless on a stray pts with no window, and `xdg-open` blocks indefinitely waiting for it to exit.

## Steps to reproduce

```bash
printf 'int main(void){return 0;}\n' > /tmp/repro.c
xdg-mime query default text/x-csrc      # -> nvim.desktop

xdg-open /tmp/repro.c &
sleep 6
ps -o pid=,cmd= -C nvim                 # nvim running, no terminal window
jobs                                    # xdg-open still blocked
```

Observed: an `nvim /tmp/repro.c` process with **no** terminal window, and `xdg-open` still running after 6s.

Contrast — the exact same handler through GIO:

```bash
gio launch /usr/share/applications/nvim.desktop /tmp/repro.c
```

Observed: `foot -e nvim /tmp/repro.c` — a real window, as intended.

## Expected behavior

A text file opened through `xdg-open` should get a terminal window, and `xdg-open` should return.

## Impact

Any application that shells out to `xdg-open` to show a config or text file appears to do nothing, then hangs.

I hit this with a locally-run web app (DeepSeek Harness) whose "open configuration file" button calls `xdg-open` on a YAML file and awaits it. The UI showed a generic failure after the request timed out, while an invisible `nvim` silently held the file open. A second click produced a swap-file conflict against the first invisible instance.

## Not a duplicate

- #2087, #2528, #2667 concerned Omarchy's **own** custom `nvim.desktop` (with `$TERMINAL`) breaking Nautilus. Removing that was correct. This report is about the **stock** entry failing on the bare `xdg-open` path only.
- #7810 and #7299 concern switching to a **GUI** editor and MIME defaults not syncing. This occurs with the shipped default (nvim), no editor change involved.

## Suggested fix

Omarchy already ships the right tool — `omarchy-launch-tui`:

```bash
exec setsid uwsm-app -- xdg-terminal-exec --app-id=$APP_ID -e "$1" "${@:2}"
```

Shipping a small `Terminal=false` desktop entry that routes the editor through `omarchy-launch-editor`, and pointing `mimeapps.list` at that entry instead of `nvim.desktop`, would fix the `xdg-open` path **without** touching `nvim.desktop` — so the Nautilus behaviour restored by #1892 stays intact.

Local workaround that fully resolves it here:

```bash
# ~/.local/bin/omarchy-open-editor
#!/bin/bash
export PATH="/usr/share/omarchy/bin:$PATH"
setsid -f omarchy-launch-editor "$@" </dev/null >/dev/null 2>&1
exit 0
```

plus a `Terminal=false` desktop entry with `Exec=/home/<user>/.local/bin/omarchy-open-editor %f`, set as the default for the text MIME types.

The `setsid -f` is the essential part — it is what lets `xdg-open` return instead of blocking.