fix(session): answer Claude Code 2.1.252's reversed folder-trust dialog

Every claude session in a directory claude had not seen before died about six
seconds after it started (`Pane is dead (status 1)`), before the agent drew a
composer. Reproduced on a fresh case and measured.

Claude Code 2.1.252 rewrote the dialog. It used to be

  ❯ 1. Yes, I trust this folder
    2. No, exit

and is now unnumbered, reversed, and highlights the option that quits:

  ❯ No, exit
    Yes, I trust this folder

Detection still worked (the confirm affordance carries the match once the
numbered option text is gone), so the failure was entirely in the answer: the
auto-accept pressed Enter on the highlighted default, which is now exit.

trustDialogNextKey() reads the ❯ marker off the rendered pane and returns ONE
keystroke at a time: an arrow while the cursor is on the wrong option, Enter
only once the screen shows it on the trust option, and null for a frame that
does not say. Both layouts are handled, and which way the trust option lies is
read from the frame rather than assumed, so a further reordering costs a
repaint instead of a session. The last marked option wins, because the
direct-PTY fallback reads an append-only buffer where an older frame must not
out-vote the freshest one.

Two things only a live pane showed:

- The scan ran solely from the PTY onData handler. The arrow that moves the
  cursor is the last output the pane produces, so the first fix parked every
  session with the cursor sitting on the right option and no Enter ever sent.
  It now schedules its own follow-up read (_trustDialogTimer, cleared in
  _clearAllTimers()), offset past the scan throttle so the chain cannot break
  on a boundary.
- The keystroke cap goes 3 -> 6, since answering is no longer one press.

The bundled codeman skill had the same blind \r as its bounded fallback, so
preamble 1.21.0 replaces it with _trust_key/_accept_trust: read
terminal?full=1, steer onto the trust option, re-read, then confirm. Those
keystrokes go out under their own clientId, because input sequence numbers are
monotonic per client and spending prompt numbers on dialog keys would make the
next send-and-wait look like a stale duplicate and vanish while reporting
success. The readiness recipes in docs/extending-codeman.md,
docs/api-reference.md and the skill's own reference carry the corrected answer,
plus a symptom-table entry for a worker whose pane is dead seconds after spawn.

Verified live on an isolated instance (own data dir and tmux socket): fresh
case -> arrow at 5 s -> Enter at 7 s -> composer, with hasTrustDialogAccepted
recorded. With the server-side auto-accept disabled in a throwaway copy, the
skill's fallback cleared a genuinely parked dialog in 1.1 s and spawn_worker
took a brand-new case to a live composer in 7.2 s; spawn_workers + sendwait +
last_text then ran end to end.

src/session-trust-dialog.ts

@@ -1,16 +1,32 @@
 /**
- * @fileoverview Recognizing Claude Code's workspace-trust dialog on screen.
+ * @fileoverview Recognizing Claude Code's workspace-trust dialog on screen, and
+ * working out which keystroke answers it.
  *
- * Claude asks once per directory before it will read or edit anything:
+ * Claude asks once per directory before it will read or edit anything. The
+ * layout has changed under us at least twice; both of these are live shapes:
  *
- *   Quick safety check: Is this a project you created or one you trust? ...
+ *   Quick safety check: Is this a project you created or one you trust? ...     (<= 2.1.220)
  *   ❯ 1. Yes, I trust this folder
  *     2. No, exit
  *   Enter to confirm · Esc to cancel
  *
+ *   Quick safety check: Is this a project you created or one you trust? ...     (2.1.252)
+ *   Security guide
+ *   ❯ No, exit
+ *     Yes, I trust this folder
+ *   Enter to confirm · Esc to cancel
+ *
  * Codeman sessions run permission-skipping or classifier-guarded modes, so the
  * answer is always yes, and a session parked on this dialog is simply stuck.
  *
+ * ⚠️ **Never press Enter without reading the selection.** The options are now
+ * unnumbered, REVERSED, and the highlighted default is "No, exit" — so the blind
+ * `\r` that answered the old layout picks *exit* on the new one and the pane
+ * dies (`Pane is dead (status 1)`) seconds after the session starts, which is
+ * exactly what a fresh case did on Claude Code 2.1.252. `trustDialogNextKey()`
+ * reads the `❯` marker instead and moves the cursor onto the trust option before
+ * it confirms anything.
+ *
  * **Why the text has to be compacted.** tmux repaints a row by writing each word
  * and then a cursor-forward (`\x1b[C`) instead of a space, and Ink colours each
  * word separately, so the wire carries `I\x1b[Ctrust\x1b[Cthis\x1b[Cfolder`.
@@ -39,6 +55,25 @@ const TRUST_PHRASES = [
 /** The dialog's own affordances. Prose that quotes the question will not have these. */
 const CONFIRM_PHRASES = ['entertoconfirm', 'esctocancel', '2.no,exit'];
 
+/** The option that answers yes, compacted. Identical text in both layouts. */
+const YES_OPTION = 'yes,itrustthisfolder';
+
+/** The option that quits Claude. It is the highlighted DEFAULT since 2.1.252. */
+const NO_OPTION = 'no,exit';
+
+/** Ink's selection marker. The only marked row while the dialog is up. */
+const SELECTION_MARK = '❯';
+
+/** A numbered option's `1.` / `2.` prefix, which the 2.1.220 layout put after the marker. */
+const OPTION_NUMBER_PREFIX = /^\d+\./;
+
+/** Move the selection one row down / up. Literal, so `send-keys -l` carries them. */
+export const TRUST_KEY_DOWN = '\x1b[B';
+export const TRUST_KEY_UP = '\x1b[A';
+
+/** Confirm the highlighted option. */
+export const TRUST_KEY_CONFIRM = '\r';
+
 /**
  * Charset-select sequences (`ESC ( B`), which tmux emits around styled runs and
  * `stripAnsi` does not cover. Left in, they would land inside a phrase as a
@@ -65,6 +100,50 @@ export function isTrustDialogScreen(text: string): boolean {
   return TRUST_PHRASES.some((p) => compact.includes(p)) && CONFIRM_PHRASES.some((p) => compact.includes(p));
 }
 
+/**
+ * Which option the `❯` marker sits on, or null when this text does not say.
+ *
+ * The LAST marked option wins. A pane capture holds exactly one frame and so
+ * exactly one marker, but the direct-PTY fallback reads an append-only buffer
+ * where every repaint since launch is still present — there the freshest frame
+ * is the one at the end, and an older one must not out-vote it.
+ */
+function selectedTrustOption(compact: string): { at: number; option: 'yes' | 'no' } | null {
+  let selected: { at: number; option: 'yes' | 'no' } | null = null;
+  for (let at = compact.indexOf(SELECTION_MARK); at >= 0; at = compact.indexOf(SELECTION_MARK, at + 1)) {
+    const after = compact.slice(at + SELECTION_MARK.length).replace(OPTION_NUMBER_PREFIX, '');
+    if (after.startsWith(YES_OPTION)) selected = { at, option: 'yes' };
+    else if (after.startsWith(NO_OPTION)) selected = { at, option: 'no' };
+  }
+  return selected;
+}
+
+/**
+ * The single keystroke that moves this dialog one step closer to "yes", or null
+ * when the screen does not show clearly enough to touch.
+ *
+ * One step per call on purpose: the caller re-reads the screen between
+ * keystrokes, so a moved cursor is CONFIRMED before Enter is pressed rather than
+ * assumed. Firing arrow+Enter together would re-create the failure this exists
+ * to prevent whenever the arrow is dropped (Ink drops keystrokes while it is
+ * still mounting a widget) — the Enter would then land on "No, exit".
+ *
+ * Returning null is the safe answer, not a failure: an unreadable frame means
+ * wait for the next repaint, and a layout whose options this cannot name means
+ * leave the dialog to the human. The caller's startup window bounds the waiting.
+ */
+export function trustDialogNextKey(text: string): string | null {
+  const compact = compactScreenText(text);
+  if (!compact.includes(YES_OPTION)) return null; // no trust option to steer onto
+  const selected = selectedTrustOption(compact);
+  if (!selected) return null; // marker missing, or not on an option we recognize
+  if (selected.option === 'yes') return TRUST_KEY_CONFIRM;
+  // On "No, exit". Which way the trust option lies is read from THIS frame — it
+  // sits below in 2.1.252 and above in the numbered layout before it — so the
+  // order flipping again costs a repaint, not a killed session.
+  return compact.includes(YES_OPTION, selected.at) ? TRUST_KEY_DOWN : TRUST_KEY_UP;
+}
+
 /**
  * How long after the pane starts the dialog is still plausible. It renders
  * before the main UI, so this only has to cover a slow first launch; leaving it
@@ -72,16 +151,21 @@ export function isTrustDialogScreen(text: string): boolean {
  */
 export const TRUST_DIALOG_WINDOW_MS = 90_000;
 
-/** Minimum gap between two Enter presses, and between two screen reads. */
+/** Minimum gap between two keystrokes, and between two screen reads. */
 export const TRUST_DIALOG_RETRY_MS = 1500;
 
 /**
- * Attempts before giving up and leaving the dialog to the user. A keystroke can
- * land while Ink is still mounting the widget and be dropped, which is the other
- * half of why sessions got stuck here; retrying costs nothing, but retrying
- * forever would hammer Enter into whatever came next.
+ * Keystrokes before giving up and leaving the dialog to the user. A keystroke
+ * can land while Ink is still mounting the widget and be dropped, which is the
+ * other half of why sessions got stuck here; retrying costs nothing, but
+ * retrying forever would hammer Enter into whatever came next.
+ *
+ * Six rather than three because answering is no longer one press: the 2.1.252
+ * layout needs an arrow onto the trust option and then Enter, each confirmed
+ * against a re-read of the screen, so a cap of three left only one dropped
+ * keystroke of slack.
  */
-export const TRUST_DIALOG_MAX_ATTEMPTS = 3;
+export const TRUST_DIALOG_MAX_ATTEMPTS = 6;
 
 /**
  * How much of the append-only terminal buffer to read on a direct-PTY session,

src/session.ts

@@ -66,6 +66,8 @@ import { RalphTracker } from './ralph-tracker.js';
 import { BashToolParser } from './bash-tool-parser.js';
 import {
   isTrustDialogScreen,
+  trustDialogNextKey,
+  TRUST_KEY_CONFIRM,
   TRUST_DIALOG_WINDOW_MS,
   TRUST_DIALOG_RETRY_MS,
   TRUST_DIALOG_MAX_ATTEMPTS,
@@ -455,8 +457,9 @@ export class Session extends EventEmitter {
   private _lastPaneProbeAt = 0; // Throttle for the tmux screen probe
   private _lastPaneProbeWorking: boolean | null = null; // Its last verdict (null = could not read)
   private _trustDialogAccepted: boolean = false; // Stops the trust-dialog scan (answered, or given up)
-  private _trustDialogAttempts = 0; // Enter presses sent at the trust dialog
+  private _trustDialogAttempts = 0; // Keystrokes sent at the trust dialog
   private _lastTrustDialogScanAt = 0; // Throttle for the trust-dialog screen read
+  private _trustDialogTimer: NodeJS.Timeout | null = null; // Re-read after a keystroke (see below)
   private _interactiveStartedAt = 0; // When the interactive pane launched (bounds that scan)
   private _taskTracker: TaskTracker;
 
@@ -1841,6 +1844,10 @@ export class Session extends EventEmitter {
     this._interactiveStartedAt = Date.now();
     this._trustDialogAttempts = 0;
     this._lastTrustDialogScanAt = 0;
+    if (this._trustDialogTimer) {
+      clearTimeout(this._trustDialogTimer);
+      this._trustDialogTimer = null;
+    }
 
     // COD-118: if the PTY exit breaker has tripped (repeated non-zero exits in a
     // short window), refuse to respawn. This is the uniform choke point that stops
@@ -2229,6 +2236,15 @@ export class Session extends EventEmitter {
    * makes a retry safe, since the terminal buffer is append-only and keeps the
    * dialog in its tail long after it has been answered.
    *
+   * ⚠️ **The keystroke is read off the screen, never assumed.** Claude Code
+   * 2.1.252 dropped the option numbers, put "No, exit" first, and highlights IT
+   * by default, so the bare `\r` this used to send now answers *exit*: a fresh
+   * case died (`Pane is dead (status 1)`) about six seconds after spawning.
+   * `trustDialogNextKey()` returns one step at a time — an arrow while the
+   * cursor is on the wrong option, Enter only once the screen shows it on the
+   * trust option — and this method re-reads the pane between the two, so a
+   * dropped arrow costs a repaint instead of the session.
+   *
    * Three guards keep an Enter press off a live session: a startup-only window,
    * a two-marker match (isTrustDialogScreen), and an attempt cap.
    */
@@ -2249,17 +2265,39 @@ export class Session extends EventEmitter {
       this._terminalBuffer.value.slice(-TRUST_DIALOG_SCAN_BYTES);
     if (!isTrustDialogScreen(screen)) return;
 
+    // Null means the frame does not say which option is highlighted. Waiting for
+    // the next repaint is the safe move; pressing Enter blind is the bug.
+    const key = trustDialogNextKey(screen);
+    if (key === null) return;
+
     this._trustDialogAttempts++;
     if (this._trustDialogAttempts > TRUST_DIALOG_MAX_ATTEMPTS) {
       this._trustDialogAccepted = true; // leave it to the user rather than keep typing
       console.warn(`[Session] Workspace trust dialog did not clear after retries: ${this.id}`);
       return;
     }
+    const step = key === TRUST_KEY_CONFIRM ? 'confirming' : 'moving to the trust option';
     console.log(
-      `[Session] Auto-accepting workspace trust dialog for: ${this.id} (attempt ${this._trustDialogAttempts})`
+      `[Session] Auto-accepting workspace trust dialog for: ${this.id} (attempt ${this._trustDialogAttempts}, ${step})`
     );
-    // Enter confirms the highlighted default, "1. Yes, I trust this folder".
-    this.writeViaMux('\r');
+    this.writeViaMux(key);
+
+    // ⚠️ Schedule the next read; do NOT wait for more PTY output. This scan only
+    // ever ran from `onData`, which was enough while one Enter answered the
+    // dialog. It is not enough now: the arrow that moves the cursor is the LAST
+    // output the pane produces, so a dialog left sitting on the trust option
+    // never gets its Enter and the worker stays parked on it forever (measured
+    // on a live 2.1.252 spawn: cursor moved at 6 s, then nothing). The timer is
+    // one-shot and self-rearming through this same path, and every exit route
+    // goes through _clearAllTimers().
+    // The +100ms puts the re-entry OUTSIDE the scan throttle above; firing at
+    // exactly the throttle boundary would let the scan return early and break
+    // the chain with the dialog still on screen.
+    if (this._trustDialogTimer) clearTimeout(this._trustDialogTimer);
+    this._trustDialogTimer = setTimeout(() => {
+      this._trustDialogTimer = null;
+      this._maybeAcceptTrustDialog();
+    }, TRUST_DIALOG_RETRY_MS + 100);
   }
 
   /**
@@ -2784,6 +2822,12 @@ export class Session extends EventEmitter {
   }
 
   private _clearAllTimers(): void {
+    // Clear the workspace-trust follow-up read
+    if (this._trustDialogTimer) {
+      clearTimeout(this._trustDialogTimer);
+      this._trustDialogTimer = null;
+    }
+
     // Clear activity timeout to prevent memory leak
     if (this.activityTimeout) {
       clearTimeout(this.activityTimeout);