Claude thread permanently fails with "No conversation found with session ID" after fresh-session fallback resumes a newly minted id #15103

Activity

1. juliusmarminge commented on Oct 3, 2026

   

   juliusmarminge

   on Oct 3, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Triage

   Thanks for the detailed diagnosis, @areidyOTH! This reproduces on current main (fed41fa88b, which includes 8ed276c2). It's a real bug, and it isn't a duplicate of #2336 (closed). That one was the V1 path, where a Claude session id was resumed before the CLI had written a transcript. This one is the V2 fresh-session fallback opening a newly created id with resume.

   Why the replacement query uses resume

   ClaudeAdapterV2.openQuery treats providerTurnOrdinal > 1 as proof that the native session already exists, so makeClaudeQueryOptions sends resume instead of sessionId. That's correct after an idle release of a session the CLI actually created, because reopening with sessionId fails with "already in use".

   It's wrong after ProviderTurnStartService drops nativeThreadRef and calls ensureThread. For Claude, ensureThread only allocates a new session id and keeps the same provider-thread row, so the next ordinal is still above 1. The replacement query ends up as resume: <new uuid> for a conversation the CLI has never seen.

   Why it stays stuck

   The new ref is written as strength: "strong" before startTurn runs. openedNativeThreads is only updated after a successful open, and the next turn doesn't check it anyway, because the ordinal check forces resume again. Retrying can't recover the thread. As you noted, the original transcript is still under the earlier session id. Continuing that session outside T3, or starting a new thread, is the workaround for now.

   Where uncertain_history_delivery comes from

   That branch only runs when a handoff for this provider thread is still pending on the current native id, and it never calls resumeThread.

   Claude has no history injection, so text handoffs are saved as pending before startTurn and only marked inline once the turn is accepted. ClaudeBackgroundWorkBlocksQueryReplacementError is thrown in openQuery before the prompt goes out, so a refused turn that had something to deliver leaves a pending marker behind. Run 14 fits that. Run 13 failed before a provider turn was recorded, so run 14 treated it as missed history, wrote the marker, and then failed the same way. Run 15 then abandoned the live session. A later delivery rewrite onto the new native id would replace that marker, which explains why you didn't find a pending row for the original session afterward.

   What needs to change

   Two things:

   • A newly created native id needs to be opened with sessionId, whatever the provider-turn ordinal is.
   • A turn start that never reaches the CLI shouldn't leave a pending delivery that later forces this fallback.

   A maintainer will decide on the fix direction.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 3, 2026
3. sandscooling

   added 2 commits that reference this issue on Oct 4, 2026

   fix(server): fresh claude sessions no longer resume a missing id

   ...

   This issue will close once commit 5d73e3a is merged into the 'main' branch.

   5d73e3a

   Merge upstream PR pingdotgg#15318 (fresh claude sessions no longer re…

   ...

   This issue will close once commit aaa260e is merged into the 'main' branch.

   aaa260e
4. CoreInfusion commented on Oct 4, 2026

   

   CoreInfusion

   on Oct 4, 2026

   More actions

   Hit the same on 0.0.46-nightly.20261003.2632 (Linux server, claudeAgent, claude-opus-5-5).

   Sequence:

   1. Messages were refused by the background-work block ([Bug]: Claude refuses every message as a "model or setting change" when a thread moves between mobile and web while background work runs #15471, which this followed directly).
   2. The user stopped the background task.
   3. On the next message, T3 recorded a provider_handoff context transfer and a full_thread_summary context handoff, set the provider thread's nativeThreadRef to a new id, and opened the Claude query with resume: <new id>.
   4. Result: No conversation found with session ID: <new id> (error_during_execution). Every later message resumes the same missing id, so the thread can't be used anymore. The previous native session's transcript was intact on disk.

   In openQuery, shouldResume becomes true through hasPersistedProviderTurn = providerTurnOrdinal > 1. That seems to count turns of the provider thread rather than of the newly created native session, so a brand-new session after a handoff is resumed instead of created.
5. AigarsMurins commented on Oct 5, 2026

   

   AigarsMurins

   on Oct 5, 2026

   More actions

   This still reproduces on 0.0.46-nightly.20261005.2667 (37de6cbde65c), which includes #15770 (efecd3cf8b). It's the "rejected starts" path that #15770 left open, and the newly allocated id is still opened with resume.

   Sequence on macOS, claudeAgent, claude-opus-5-5, on a long thread that had an earlier context handoff:

   1. Run 48 wedged on an AskUserQuestion with a blank option description ([Bug]: Claude AskUserQuestion with a blank option description fails the run and wedges the thread #15316).
   2. Runs 49, 50 and 51 were rejected in ClaudeAdapterV2.startTurn with ProviderAdapterProtocolError: Claude provider turn … is still active.
   3. I restarted the app, which also updated it to 20261005.2667, and sent a message.
   4. At 06:19:34.524Z, a provider-thread.updated event (seq 25332) set a new native id, 5f16b04e-b3bb-4952-b090-05e584cd706b, and context-handoff.updated events followed.
   5. At 06:19:35Z, the provider log shows:

   {"type":"query.close"}
   {"type":"query.open","options":{"model":"claude-opus-5-5[1m]","permissionMode":"bypassPermissions","resume":"5f16b04e-b3bb-4952-b090-05e584cd706b", ...}}
   {"type":"prompt.offer","message":{... "content":"Context handoff (full_thread_summary, delta_since_target_last_seen). 5 handoff records; ..."}}
   {"type":"result","subtype":"error_during_execution","duration_ms":0,"is_error":true,"num_turns":0,"session_id":"5f16b04e-b3bb-4952-b090-05e584cd706b"}

   The UI showed No conversation found with session ID: 5f16b04e-…. The thread's real session (ac7ceaa1-…) is intact on disk and resumes fine with claude --resume.

   So two things are still wrong on a build that includes #15770:

   • The rejected starts forced a fresh session.
   • The fresh id was still opened with resume rather than sessionId.

   The thread can't be used now: every message resumes the same missing id. I can share the provider event log and the orchestration_events rows if that helps.
6. tallboxdesign commented on Oct 5, 2026

   

   tallboxdesign

   on Oct 5, 2026

   More actions

   Additional occurrence on macOS; installed version at investigation: 0.0.46-nightly.20261005.2667.

   A long-running Claude conversation stopped accepting messages after working throughout the day and overnight. Local logs show that T3 replaced a working session reference during recovery, then tried to resume the replacement before it existed. The original transcript remained on disk, but subsequent resume and fork attempts failed. Please investigate session recovery and provide a supported way to reconnect the existing conversation.

   Environment

   • macOS, T3 Code Nightly.
   • Installed version at investigation: 0.0.46-nightly.20261005.2667. The exact build running at every earlier failure is unverified.
   • Claude Agent SDK with Claude Opus 5.5; the successful runtime used the 1M-context variant.
   • Long-running conversation with background commands.

   Observed sequence

   1. Claude worked throughout the day and overnight.

   2. Ordinary follow-up messages began failing with:

      Claude is still running background agents or commands, and this model or setting change would end them. Wait for them to finish, or press Stop, then send the message again.

   3. A history handoff was left marked as pending after a blocked message.

   4. On a later message, T3 logged a fresh-session fallback with the reason uncertain_history_delivery.

   5. T3 replaced the working native session reference with a newly allocated reference.

   6. It closed the previous query and opened another using resume for the new reference, rather than creating the replacement session.

   7. Claude returned “No conversation found with session ID: [redacted]”. The result reported zero turns, zero tokens, and zero API time.

   8. Later retries reused the invalid replacement reference. Fork attempts also failed.

   The original local transcript and T3 conversation history remained available. This is a failure of session continuity, not demonstrated deletion of the conversation. The survival of individual background jobs was not established.

   Separate blocker when switching providers

   Switching to Codex allowed replies. Switching back to Claude then produced:

   Insufficient context allowance for the provider handoff. Compact the target conversation or use a larger-context model; the current request has not been truncated.

   The handoff-budget calculation has not been independently reproduced, so this report does not claim that calculation is incorrect. However, it creates a recovery dead end when the target Claude session is already unavailable.

   Expected behavior

   • A message rejected before delivery should not leave history state that unnecessarily abandons a valid session.
   • A newly allocated session must be created before it can be resumed.
   • An unsuccessful replacement must not permanently displace the last working session reference.
   • Resume and fork failures should offer a supported recovery action, without manual database edits.
   • Context-allowance failures should provide an actionable compaction or concise-handoff recovery path.

   Evidence and limits

   Local provider logs, server traces, and read-only database inspection support the sequence above. The server explicitly recorded an uncertain-history-delivery fallback, followed by a resume request for the replacement session and a missing-session response. The exact internal reason the creation-versus-resume decision selected resume has not been reproduced.

   No app, session, or database files were changed during diagnosis. This report contains no work titles, project names, account identifiers, session/thread IDs, transcript excerpts, local paths, or private-work screenshots.

   Prepared by Codex (GPT-6-Astra), using local read-only investigation; posted with the user’s authorization.
7. juliusmarminge

   closed this as completedon Oct 7, 2026