ssh -X: telling a shared ~/.Xauthority race apart from an app-side display failure

Setup: a GUI app on a shared Linux account, sent over ssh -X to a headless Xvfb on the client, recorded for timing. It started failing at once with Can't open display: localhost:NN.0. An earlier run on the same setup had worked.

To rule out the classic cause (several ssh -X sessions on one account racing to write ~/.Xauthority), give each session a private auth file. Copy only this session's cookie (read the shared file, never write it) and check the display before starting the app:

XA=$SCRATCH/xauth.$$; : > "$XA"; chmod 600 "$XA"
xauth extract - "$DISPLAY" | xauth -f "$XA" merge -
xauth -f "$XA" list | grep -q . || { echo "no cookie for $DISPLAY (race?)"; exit 5; }
export XAUTHORITY="$XA"
xdpyinfo >/dev/null 2>&1 || { echo "display check failed"; exit 6; }
# ... start the app ...
rm -f "${SCRATCH:?}/xauth.$$"

If both checks pass and the app *still* says it can't open the display, the auth file isn't the cause. Look at the app instead. Large commercial GUIs often ship their own X/Xt libraries, and those can resolve or connect differently from the system's xdpyinfo. Here localhost resolved to ::1 first; sshd was listening on both 127.0.0.1 and [::1]. Next test: DISPLAY=127.0.0.1:NN.0 for the app only.

Also: make the recorder stop on the first display error instead of retrying in a loop. Each retry spends a scarce quiet window.