[Bug]: Claude appears to crash on Windows machine

[djfbryant]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. Install or update t3-code-desktop to the same build where the issue started for me: 0.0.13.
2. Launch the desktop app fresh after update.
3. Create a new thread using a Claude model, specifically one of:
4. claude-sonnet-4-6
5. claude-opus-4-6
6. Use a normal coding prompt against a local workspace.
7. Submit the first turn.

Expected behavior

The Claude thread should start processing the turn.

Actual behavior

• The turn remains pending.
• The backend exits and restarts.
• server-child.log records:

Error: All fibers interrupted without error
    at async h4.streamInput (.../@anthropic-ai/claude-agent-sdk/sdk.mjs:22:1905)

• desktop-main.log records:

[desktop] backend exited unexpectedly (code=1 signal=null); restarting in 500ms

Impact

Major degradation or frequent failure

Version or commit

No response

Environment

No response

Logs or stack traces

Screenshots, recordings, or supporting files

t3-claude-crash-sanitized-README.txt
t3-claude-crash-desktop-main-sanitized.log
t3-claude-crash-server-child-sanitized.log

Workaround

Codex still works in the same app/session

• Immediately after the Claude crash loop, a Codex thread starts successfully.
• That makes this look provider-specific rather than a general backend startup failure.

[djfbryant]

The first and most important one is stale Claude resume state being reused across restarts/recovery. T3 persists Claude resume/session identifiers and then automatically feeds them back into later startSession recovery flows. If Anthropic no longer recognizes that session, the first turn fails with errors like No conversation found with session ID ..., which then surfaces in T3 as Query closed before response received or claudeAgent adapter thread is closed. That matches the behavior where old/recovered threads fail but fresh threads work.

The second likely root cause is Windows process-launch assumptions in the Claude integration. The current integration appears to assume the Claude executable can be launched through the SDK the same way it works in an interactive shell. On Windows, npm-installed CLIs often resolve through shim files like claude.cmd, and SDK/spawn behavior does not always match shell behavior. That can make Claude appear installed and functional from a terminal while still failing or behaving inconsistently when launched programmatically by T3.

So for the main branch, the clean issue summary is:

T3 auto-reuses persisted Claude resume/session state too aggressively.
When that persisted Anthropic conversation is no longer valid, recovered threads fail on first turn instead of falling back to a fresh Claude session.
On Windows, Claude executable resolution/launch is also likely brittle because shell-visible claude availability does not necessarily map to a valid SDK launch target.

---

Unsure if this helps, Codex (eventually) fixed the issue in a fork and I asked it to summarise the root cause(s). Hopefully this is helpful