fix: auto-accept Bypass Permissions dialog so readiness isn't stuck

[kaibyao]

Problem

Every clarp -p --dangerously-skip-permissions invocation dies after exactly 120s with a readiness timeout, even in a fresh empty dir. duration_ms≈120000, num_turns:0, empty session_id — Claude never takes a turn. Native claude -p runs fine in the same environment.

clarp error: Readiness timeout: Timed out after 120s waiting for Claude to become ready...

Root cause

--dangerously-skip-permissions shows two sequential first-run TUI dialogs, not one:

1. Workspace trust — clarp already auto-confirms (\r, default option = "Yes, I trust this folder"). ✅
2. Bypass Permissions mode warning — clarp had no handler. Its default-highlighted option is 1. No, exit:

   WARNING: Claude Code running in Bypass Permissions mode
   ❯ 1. No, exit
     2. Yes, I accept
   

Claude sat at dialog #2 forever, never started a session, never wrote its ~/.claude/sessions/<pid>.json status file. clarp's PTY supervisor polls that file for a status transition to observe readiness — the transition never came, so it timed out after STARTUP_READY_TIMEOUT_MS (120s). Native claude -p skips the interactive dialog entirely, which is why it worked.

Fix

Generalize the single-shot workspace-trust detector into createStartupPromptDetector, which reports both dialogs (each at most once). On the bypass dialog, select 2. Yes, I accept by writing 2\r.

Writing the digit avoids the leading ESC byte of an arrow-key sequence (\x1b[B) — the dialog shows "Esc to cancel", and a lone/slow ESC registers as cancel and quits (observed: exit code 1).

Verification

• Fresh mktemp -d + --dangerously-skip-permissions: Claude now becomes ready and completes the turn (produces output, SSE streams). No more 120s hang.
• Added tests: bypass-prompt detection + trust→bypass two-dialog sequencing.
• Full suite green (439 tests).

https://claude.ai/code/session_01TAxUbT4zmnXv8LiipMk7ii