Two reasons the local TUI stopped running OpenTUI / showed the wrong directory:
1. Node resolution. OpenTUI needs Node >= 26.3 (node:ffi floor), but
_node26_bin_or_none only checked HERMES_NODE + `which node`. When fnm's
default flips to an older line (e.g. v25.9) the active node fails the gate
and the engine silently falls back to Ink even though a usable v26.3 sits
installed. _fnm_node26_candidates now discovers fnm's installed versions
(FNM_DIR / XDG_DATA_HOME/fnm / ~/.local/share/fnm / macOS Library path),
newest first, version-probed — so the engine launches without the user
re-aliasing their global default.
2. Launch cwd. The launcher runs the engine with cwd=<engine package dir> so
its build/resolution works; the gateway it spawns then auto-detected THAT
dir as the workspace (chrome bar showed 'ui-opentui (feat/opentui-native-
engine)' regardless of where you ran hermes). TERMINAL_CWD — the gateway's
canonical launch-dir channel — was only exported in worktree mode; now it's
set to the real cwd for every launch (worktree mode still overrides to the
worktree path). The TUI's session.create no longer sends process.cwd() (the
engine dir) — a new launchCwd() reads the launcher's HERMES_CWD/TERMINAL_CWD,
falling back to process.cwd() only for standalone smokes.
Together: session cwd, chrome bar, terminal-tool cwd, and /sessions grouping
all anchor to where you actually ran hermes. Verified live — chrome bar shows
'/tmp/cwd-probe (my-feature)' launched from there with fnm default on v25.9.
8 new tests (fnm discovery order/precedence/empty-safety; launchCwd env
precedence).
