Codex review: needs maintainer review before merge.

Keep this PR open for normal maintainer review. Current main still lacks the TUI reconnect/watchdog resync behavior for #69081, while this PR is a focused implementation candidate with tests and no obvious supply-chain-sensitive changes.

Maintainer follow-up before merge:

Keep this PR open and review it as the focused implementation for #69081. If the approach is sound, land the narrow TUI fix that treats active-run tool and non-terminal lifecycle events as proof-of-life, pauses watchdog timers while disconnected, rearms reconnect recovery without dropping legitimately in-flight runs, and reloads history when reconnect-stale runs time out.

Best possible solution:

Keep this PR open and review it as the focused implementation for #69081. If the approach is sound, land the narrow TUI fix that treats active-run tool and non-terminal lifecycle events as proof-of-life, pauses watchdog timers while disconnected, rearms reconnect recovery without dropping legitimately in-flight runs, and reloads history when reconnect-stale runs time out.

Acceptance criteria:

• pnpm test src/tui/tui-event-handlers.test.ts src/tui/tui-session-actions.test.ts src/tui/tui-command-handlers.test.ts src/tui/embedded-backend.test.ts
• pnpm exec oxfmt --check --threads=1 src/tui/tui-event-handlers.ts src/tui/tui.ts src/tui/tui-event-handlers.test.ts CHANGELOG.md
• git diff --check
• pnpm check:changed via Testbox before maintainer handoff

What I checked:

• current_main_delta_only_watchdog: Current main arms the streaming watchdog from the chat delta branch for the active run; tool and lifecycle proof-of-life are separate paths. (src/tui/tui-event-handlers.ts:338, a1197b907524)
• current_main_quiet_tool_events_do_not_refresh_watchdog: The tool-event branch returns when verbose mode is off before doing any watchdog refresh, matching the long-tool false-idle path in [Bug]: TUI: "streaming" status desyncs from actual run state #69081. (src/tui/tui-event-handlers.ts:439, a1197b907524)
• current_main_lifecycle_events_do_not_rearm_watchdog: Lifecycle events update activity status for active runs but do not arm, pause, or resync the streaming watchdog. (src/tui/tui-event-handlers.ts:474, a1197b907524)
• current_main_reconnect_has_no_watchdog_hooks: runTui currently receives only handleChatEvent, handleAgentEvent, and handleBtwEvent; onConnected reloads history and onDisconnected updates status, but neither calls pause/reconnect watchdog helpers. (src/tui/tui.ts:903, a1197b907524)
• pr_diff_targets_missing_behavior: The latest PR diff adds pauseStreamingWatchdog/reconnectStreamingWatchdog, active-run tool/lifecycle watchdog refreshes, reconnect-stale history recovery, and regression tests for quiet tool events, reconnect pause/rearm, overlapping history reload, stale reconnect runs, and lifecycle-only reconnects. (215f687d69e1)
• security_review_surface: Security pass found the PR touches only CHANGELOG.md and TUI TypeScript/test files. It does not change workflows, dependencies, lockfiles, package scripts, permissions, secret handling, artifact downloads, or publishing metadata. (215f687d69e1)

Likely related people:

• xantorres: Authored the original TUI streaming watchdog reset-after-delta-silence behavior that this PR extends for tool/lifecycle proof-of-life and reconnect recovery. (role: introduced behavior; confidence: high; commits: f44ab20d4db5; files: src/tui/tui-event-handlers.ts, src/tui/tui-event-handlers.test.ts, CHANGELOG.md)
• CCcassiusdjs: Authored the merged delta-path watchdog fix in fix(tui): arm streaming watchdog on every delta, not only visible ones #69338; this PR works in the neighboring agent-event and reconnect paths of the same TUI watchdog state machine. (role: adjacent maintainer; confidence: high; commits: 89b6d0248159; files: src/tui/tui-event-handlers.ts)
• vincentkoc: Recently merged adjacent TUI stale-streaming/orphan-final recovery in fix(tui): clear stale streaming after orphaned finals #72389 and owns an open maintainer-labeled follow-up in the same status/finalization area (fix(tui): recover stale streaming status after unbound final #73749). (role: recent maintainer; confidence: medium; commits: d7e67b455a74; files: src/tui/tui-event-handlers.ts, src/tui/tui-event-handlers.test.ts, CHANGELOG.md)

Remaining risk / open question:

• This PR changes TUI reconnect/watchdog state-machine behavior and should still receive normal maintainer review plus CI/Testbox validation before merge.
• There is nearby open TUI streaming work (fix(tui): raise streaming watchdog threshold to 120s and suppress false-positive warning #69026 threshold/UX and fix(tui): recover stale streaming status after unbound final #73749 stale unbound-final recovery), so maintainers should avoid accidentally bundling unrelated watchdog UX or stale-final scope changes into this PR.

Codex review notes: model gpt-5.5, reasoning high; reviewed against a1197b907524.

Greptile Summary

This PR fixes the streaming watchdog in the TUI to survive reconnects: it pauses the watchdog on disconnect, rearms it (preserving activeChatRunId) on reconnect, counts active-run tool events and non-terminal lifecycle events as proof-of-life, and reloads history when a reconnect-stale run times out rather than showing a noisy warning.

Confidence Score: 4/5

Safe to merge; both findings are narrow edge-case P2s that don't affect the common reconnect path.

No P0/P1 findings. Two P2 issues: a possible double loadHistory call when pendingHistoryRefresh and reconnectPendingRunId are both live simultaneously, and a stale activityStatus when reconnectStreamingWatchdog drops a run that is no longer in sessionRuns. Both are unlikely in normal usage and non-corrupting. P2-only ceiling is 4/5.

src/tui/tui-event-handlers.ts — the two edge-case paths in armStreamingWatchdog's timeout and reconnectStreamingWatchdog's stale-run branch.

This is a comment left during a code review.
Path: src/tui/tui-event-handlers.ts
Line: 123-128

Comment:
**Potential double `loadHistory` call in reconnect watchdog path**

`flushPendingHistoryRefreshIfIdle()` is called unconditionally on line 123 before the `reconnectPendingRunId` guard on line 124. If `pendingHistoryRefresh` happens to be `true` at this point (e.g. a local BTW run finalized while the reconnect-pending run was still active), both `flushPendingHistoryRefreshIfIdle` and the explicit `void loadHistory?.()` on line 126 will fire, issuing two concurrent history fetches. Consider moving the `reconnectPendingRunId` check before `flushPendingHistoryRefreshIfIdle`, or resetting `pendingHistoryRefresh` inside the reconnect branch to prevent the duplicate call.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/tui/tui-event-handlers.ts
Line: 236-240

Comment:
**`activityStatus` not reset when stale `activeChatRunId` is dropped on reconnect**

`state.activeChatRunId` is set to `null` on line 238 before `clearStaleStreamingRunIfNoTrackedRunRemains()` is called. That helper's first check is `!activeRunId`, so it returns early immediately — leaving `state.activityStatus` stuck at `"streaming"` and `flushPendingHistoryRefreshIfIdle()` never called. After reconnect the TUI can keep displaying a streaming indicator for a run that no longer exists. The fix is to call `setActivityStatus("idle")` (and `flushPendingHistoryRefreshIfIdle()`) explicitly in this branch instead of delegating to a helper that will no-op on the already-nulled field.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(tui): keep reconnect history fallbac..." | Re-trigger Greptile}