fix(sessions): stop agent-crash recovery from wiping task history

[richardsolomou]

Problem

When the Claude agent process died at the wrong moment, the local-session recovery path could permanently wipe the task's history and leave the task unrecoverable (reported: "the agent just died and it stopped the task… it actually cleared out the entire history of the task itself"). Three compounding issues:

1. Retry destroyed the run. clearSessionError recreated the session whenever initialPrompt was still set. That flag is only cleared by a live agent event, so it survives a crash (or a dropped event subscription) before the first event reaches the renderer — even when the agent already did real, logged work. The recreate branch tore the session down and called createTaskRun, orphaning the populated run log behind a fresh empty latest_run; the auto-retry loop could repeat this up to three times.
2. Reconnect blanked the transcript. reconnectToLocalSession repaints the session from the run log, and fetchSessionLogs swallows read errors into an empty result — so an unreadable log after a crash replaced a fully populated in-memory transcript with an empty one.
3. API timeouts entered recovery at all. Transient upstream provider failures ("API Error: … the operation timed out / terminated / Connection error / 5xx") arrive wrapped as "Internal error: …", so isFatalSessionError's generic "internal error" pattern classified them as fatal and sent a healthy session through the same teardown/recovery machinery.

Changes

• clearSessionError only recreates the run when the conversation genuinely never started: a new runHasConversationHistory helper checks the in-memory transcript, then the persisted run log, for any event beyond the user's own prompt echo. Otherwise it reconnects in place, preserving the run and its history.
• reconnectToLocalSession keeps the previous in-memory events when the log read produces nothing instead of overwriting them with an empty array.
• New isTransientUpstreamError in @posthog/shared (patterns kept in sync with the agent's classifyAgentError); isFatalSessionError now returns false for these. On a transient failure the prompt handler skips recovery, clears the pending-prompt state, and surfaces "The AI provider timed out or dropped the connection. Your session is unaffected — please send the message again." instead of the raw internal error.

How did you test this?

• New unit tests: recreate-vs-reconnect gating in sessionServiceRetryConfig.test.ts (in-memory history, log-only history, prompt-echo-only), transcript preservation on empty log read and no-recovery-on-API-timeout in sessionServiceHost.test.ts, and 12 classification cases in errors.test.ts.
• Full suites green: shared (48), core sessions (263), UI host (135). typecheck clean on shared/core/ui; Biome clean with zero noRestrictedImports in core.

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

🤖 Generated with Claude Code

[trunk-io]

Merging to main in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[github-actions]

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit 8accc8b.}

[greptile-apps]

_{Reviews (1): Last reviewed commit: "fix(sessions): stop agent-crash recovery..." | Re-trigger Greptile}