---
name: xdg-open-tab-proof-niri
description: "Prove an xdg-open URL actually landed a tab in Frank's Firefox on niri, instead of reporting the law-compliant \"opened in your browser\" blind."
---

AGENTS.md (`dank/command-center`) requires opening every PR in Frank's browser with `xdg-open <PR-URL>`. `xdg-open` exits 0 whether or not a tab appeared, and its stderr is easy to swallow (`>/dev/null 2>&1 &`), so "opened in your browser" is normally an unverified claim. Prove it before saying it.

## The proof that works

```bash
export XDG_RUNTIME_DIR=/run/user/$(id -u)
export WAYLAND_DISPLAY=${WAYLAND_DISPLAY:-wayland-1}
niri msg windows | grep -iA2 'firefox\|gitea\|pull'
```

Expected — the tab title is the page title, so it doubles as confirmation you opened the right object:

```
Title: "#61 - fix(#60): checks that lied… - command-center - Frank's Dank Gitea… — Mozilla Firefox"
  App ID: "firefox"
  PID: 1150647
```

## Why the obvious checks fail here

- **The computer/AX window list does not list Firefox.** `computer.windows()` on this Wayland backend returned only ghostty windows — Firefox exposes no ATSPI top-level unless accessibility is already active inside it — so an empty list is **not** evidence the tab is missing.
- `capture: false`, `displayCount: 0` in `computer.capabilities()` mean screenshots are unavailable (display asleep); a blank screenshot proves nothing either way.
- `wmctrl -l` / `hyprctl` do not exist on niri. `niri msg windows` is the window census, and `niri msg outputs` is the output census.
- `pgrep -af firefox` only shows the process tree (one parent + `-contentproc` children); a tab never appears there.
- The web page itself is not proof: Gitea's `/dank/<repo>/pulls/N` HTML answers **404** without a session cookie even though the API and the browser both work.

## Dispatch recipe (when nothing is running, or nothing landed)

```bash
XDG_RUNTIME_DIR=/run/user/$(id -u) WAYLAND_DISPLAY="${WAYLAND_DISPLAY:-wayland-1}" \
  xdg-open https://gitea.franksdank.cloud/dank/<repo>/pulls/N
```

Give it the **`https://gitea.franksdank.cloud/…`** form, not the LAN `192.168.0.143:3000` form the API returns — that is the host Frank's bookmarks and cert expectations use. A running Firefox receives the URL as a new tab in the existing instance; re-dispatching opens a second tab, which is a cheap, idempotent way to recover from a swallowed failure.

Related: `gitea-pr-api-cycle` (the API cycle whose final step this verifies), `omp-tui-live-visual-verify` (same rule for terminal UIs: observe the real surface).