[devin-ai-integration]

Summary

Users were running xhost + 127.0.0.1 by hand before xvd, typically after an XQuartz update. The cause: an xhost authorization is state of the X server, but tig only ran xhost when it created a container. The container is deliberately long-lived, so once XQuartz restarted (update, logout, quit) nothing re-authorized it for the container's lifetime.

ensure_x11_ready() is now per command instead of per container, and made cheap by remembering which server was authorized:

identity = x_server_identity()          # darwin: "$DISPLAY xquartz=<pid>"
                                        # linux:  "$DISPLAY socket=<ino>:<mtime>"
if identity is not None and identity == _authorized_server():
    return                              # steady state: one pgrep/stat, no xhost
... xhost ...
_record_authorized_server(identity)     # ~/.cache/tig/x11-authorized

None (no server recognized) always re-authorizes rather than assuming anything. Call sites: ContainerManager.execute_vicar_command(), fast.run() (before the claim, so the dispatcher path is covered too), and container creation as before.

Two macOS specifics:

• authorize +localhost +inet:127.0.0.1, since the connection arrives from the runtime gateway on IPv4 loopback however localhost happens to resolve;
• nolisten_tcp is only read at XQuartz startup, so when it is already running with TCP off — how it comes out of an update that reset the preference — tig writes the preference and tells the user to quit XQuartz, rather than quitting it under their other X clients.

TIG_NO_X11=1 opts out entirely. Docs updated in tig-cli/README.md and docs/install-macos.md.

Link to Devin session: https://nasa-jpl-demo.devinenterprise.com/sessions/50390f321d6648c4b813b55446f1def1
Open in Devin Desktop: https://nasa-jpl-demo.devinenterprise.com/desktop/session/50390f321d6648c4b813b55446f1def1?variant=devin
Requested by: @HuiJun

[devin-ai-integration]

Original prompt from jason.han

@JPL-Devin/tig users are reporting that they often have to do xhost + 127.0.0.1 nearly every time, possibly when XQuartz updates. Is there anything we can do to fix this and not have the user do that command everytime they want to use xvd?

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR that start with 'DevinAI' or '@devin'.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[devin-ai-integration]

Runtime re-test after 832ba82 / 7332773 (Devin session)

Linux end-to-end with the real :opensource VICAR image, tig gen check.vic 128 128 + tig xvd check.vic. Delta run only — baseline and the genuine X-server-restart case were verified in the previous round.

xhost -local: with the same X server running now recovers

Precondition: access control enabled, no LOCAL: entry, socket identity byte-identical to the cached marker. Then tig xvd check.vic with no manual xhost — window renders and LOCAL: is back:

Repeated on a second, cookie-enforced X server (Xtigervnc :2, cookie in /tmp/x2.auth, so a cookie-less client is refused and xhost is the only way in) — tig re-authorized it by itself and xvd rendered in the captured :2 framebuffer:

Steady state: 1 xhost per command, overhead invisible

With a logging shim ahead of the real xhost, five consecutive commands logged exactly five xhost +local: calls (the intended new behavior), the marker stayed byte-identical, and non-GUI commands still ran 0.112–0.116 s real.

TIG_NO_X11=1 still does not touch the display

On a revoked, cookie-enforced :2: Error: Can't open display: :2, zero xhost calls from tig, no LOCAL: added, marker md5 unchanged.

Note on how much xhost matters on Linux

The container mounts $HOME rw with HOME=/home/ubuntu, so xvd uses the same ~/.Xauthority MIT cookie as the host: with TIG_NO_X11=1 and access control revoked, the window still opened on the desktop display. So on a typical Linux desktop the xhost +local: call is mostly belt-and-braces; the load-bearing case is a display whose cookie is not in $HOME (verified separately on :2) and the macOS/TCP path. Not a defect in this PR, just scope.

Not tested: the macOS/XQuartz half (no macOS host); the "marker only written when xhost succeeded" and "network DISPLAY never cached" changes were not exercised at runtime.