Sign up
View stargazersSign up

[Bug]: [Nightly] Thread stuck on "No conversation found with session ID" — resume cursor never cleared (related #2336)#31689

opened7d agobySserkanbektas

Before submitting

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

Area

apps/server

Steps to reproduce

Description

A Claude thread became unusable. Every message I send fails immediately with:

Provider error No conversation found with session ID: UUID

Right before it, T3 shows the warning:

T3 could not confirm Claude bypass permissions here, so Full access is running with approval checks.

The T3-side message history is still visible, but the thread can't continue. It looks like T3 keeps calling claude --resume with a session ID that no longer exists on disk, and the stored resume cursor is never cleared, so the same failure repeats on every send/reopen.

Steps to reproduce

  1. Open an existing Claude thread in T3 Code Nightly (runtime mode: Full access).
  2. Send a message.
  3. Observe the bypass-permissions warning, then the "No conversation found" provider error.
  4. Retry / restart the app — same error every time.

Diagnostics

  • find ~/.claude/projects -name "UUID.jsonl" → [no result / found at: ...]

Expected behavior

If the provider session can't be resumed, T3 should clear the stale resume cursor and start a fresh provider session for the thread (ideally with a notice), instead of leaving the thread permanently broken.

Actual behavior

The thread is permanently stuck; the only workaround is to start a new thread and lose the model-side context.

Impact

Blocks work completely

Version or commit

Version 0.1.8-nightly.20261105.4234 (8b570d282b5f)

Environment

MacOS 26.6.2 (25G83), Node: v26.10.0, Claude Code CLI: 2.1.311 (Claude Code)

Logs or stack traces

shell
1T3 could not confirm Claude bypass permissions here, so Full access is running with approval checks.

Screenshots, recordings, or supporting files

No response

Workaround

No response

DDamienStevens3d ago
Synced from GitHub

Root cause and a deterministic repro, in case it helps triage.

Repro (main @ eb6e7fa2f6): run a turn on a Claude thread, stop the server, delete that session's ~/.claude/projects/*/<nativeId>.jsonl, start the server, send a message → No conversation found with session ID: <nativeId> on every send. Same thing happens when the transcript is lost in a backup restore that captured the T3 database but not ~/.claude/projects.

Cause: ClaudeAdapterV2.resumeThread checks the transcript on disk, but when no copy exists it returns success and leaves the resume to the CLI. Because the thread already ran, startTurn launches the CLI with --resume, which fails. ProviderTurnStartService already has the right recovery (fresh native session + context handoff, native ref replaced), but it only runs when resumeThread fails, so it never kicks in. #19637 fixed the neighboring case (a transcript that contains only metadata) by failing resumeThread; the case where no transcript exists at all wasn't covered.

Fix: have resumeThread also fail when no transcript copy exists and the provider thread has already run (lastRunOrdinal !== null). Unreadable transcripts and never-used session ids keep the current behavior. The diff is about 10 lines in the adapter, plus an added case in the existing ClaudeAdapterV2 resumeThread test. Two test harnesses also need CLAUDE_CONFIG_DIR pointed at a temp dir, because they currently read the real ~/.claude/projects on whatever machine runs them.

Codex isn't affected: its resumeThread calls thread/resume directly, so a missing rollout already fails and falls back.

Happy to open a PR if this direction looks right.

(The bypass-permissions warning in the original report looks unrelated.)