fx produces zero frames / exits silently in headless pty (tmux) — startup blocks on auth reachability

[yakimoto]

What happened

fx fails to start in headless/automation environments (tmux session, real pty, fixed geometry) — it either exits silently within seconds or hangs before first render, producing zero rendered frames even when the process stays alive.

This contradicts two claims we were excited to build on: the 10µs cold start and the hermetic/local-first story ("with outbound networking blocked, prompts and model context stay local"). In our probes, startup appears to block or bail on auth-endpoint reachability before any frame is drawn, with no error surfaced to the terminal.

Reproduction

# detached tmux at fixed geometry, real pty
tmux new-session -d -s tp -x 120 -y 30 "$HOME/.local/bin/fx"
sleep 16
tmux capture-pane -t tp -p        # -> 30 blank lines; process alive in one run, gone in another

Programmatic driver (same result, JSON receipt):

{ cmd: "~/.local/bin/fx", geom: "120x30", keysScripted: 3,
  sessionSurvivedTimeout: false, frameChanges: 1,
  renderedNonBlank: false, wallSec: 16 }

Environment: macOS arm64, fx installed today via curl -fsSL https://fx.sh/setup.sh | bash, ~/.fx/ present, no interactive login completed yet.

Expected

Per the docs' automation posture (fx ask --no-save, hermetic setups, embeddability), we'd expect either:

1. a rendered TUI with an explicit offline/auth error state, or
2. a non-zero exit with a stable machine-readable error code,

…not a silent blank pane / silent exit. A --headless-check or doctor-style preflight that reports which endpoint startup is blocked on would make fx drivable from CI and agent harnesses (we drive vendor CLIs exactly this way).

Use case

We orchestrate coding-agent CLIs headlessly across a fleet (tmux-driven keystroke scripts + pane capture). fx is at the top of our integration list — the moment startup degrades gracefully offline, it becomes scriptable for us end to end.