You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Imported Claude Code threads fail on their first follow-up with "Session ID … is already in use" #15243
This report includes the session details and the error text.
Area
apps/server
Steps to reproduce
Run a Claude Code session in a project folder from the terminal (for example claude in ~/work/<project>), so ~/.claude/projects/<encoded-cwd>/<sessionId>.jsonl exists.
Open the imported thread and send any follow-up message.
Expected behavior
The follow-up resumes the existing Claude Code session (resume: <sessionId>) and the turn runs.
Actual behavior
The turn fails immediately. The thread shows "Provider error / Provider turn failed." and its status becomes Failed. The server logs orchestration-v2.claude-query-stream-failed for the thread's provider turn with the cause elided.
Running the same thing the adapter does, directly against the CLI, shows the underlying error:
$ cd ~/work/being-and-becoming
$ claude -p --session-id e7f9c804-28e6-45bb-a19d-de63cd7bc206 "Reply with just the word ok."
Error: Session ID e7f9c804-28e6-45bb-a19d-de63cd7bc206 is already in use.
Cause, from reading the code: AgentSessionImporter writes the imported provider thread with a strong nativeThreadRef but nativeConversationHeadRef: null and no provider turns. In ClaudeAdapterV2openQuery, shouldResume is true only when there is a conversation head, the process already opened the session, or providerTurnOrdinal > 1. An imported thread has none of those on its first follow-up, so makeClaudeQueryOptions passes sessionId: <imported id> instead of resume: <imported id>, and the CLI rejects the id it already owns. The adapter's own comment at that spot describes exactly this failure. The provider_resume_fallback in ProviderTurnStartService does not catch it, because the Claude resumeThread is a no-op that succeeds and the failure happens later at query open.
Codex imports are unaffected: the Codex adapter sends thread/resume { threadId } for the same ref and the turn runs.
Impact
Major degradation or frequent failure. Every imported Claude Code session (wizard import or per-session import) fails on its first follow-up, so Claude sessions cannot be continued in T3 Code.
Version or commit
main at ce90eec (2026-10-03), reproduced on a branch that adds only the per-session picker from #15234 on top of it. Claude Code CLI: 2.1.286 (Claude Code).
Environment
macOS (Darwin 27), web client in the dev server (vp run dev with an isolated --home-dir), Claude Code provider instance with its default home.
Turn item persisted for the run: {"type":"error","title":"Provider error","failure":{"class":"transport_error","message":"Provider turn failed.","code":null,"retryable":null}}.
Workaround
None inside T3 Code. Resuming from the terminal with claude --resume <sessionId> works.
Thanks @alimohammed1624 for turning the prediction from #15234 into a real repro, with the CLI command and the logs.
Confirmed on main at ce90eec. This isn't limited to the unmerged per-session picker. The welcome-wizard import goes through the same AgentSessionImporter path, so every imported Claude Code thread fails the same way on its first follow-up.
Your reading matches the code:
Import writes a strong nativeThreadRef, nativeConversationHeadRef: null, and no provider turns. It also stores a Claude resumeCursor of { threadId, resume }, but ClaudeAdapterV2 never reads that cursor.
The first follow-up's providerTurnOrdinal is 1, since import creates no provider turns.
In openQuery, shouldResume is false for an imported thread, so makeClaudeQueryOptions sends sessionId instead of resume. The comment at that spot describes exactly the "Session ID … is already in use" failure.
ClaudeAdapterV2.resumeThread just stamps the existing row and succeeds, so ProviderTurnStartService never takes the provider_resume_fallback path. The failure comes later, when the query opens.
Codex isn't affected, because its resumeThread sends thread/resume for the same native ref.
Likely fix area
shouldResume in ClaudeAdapterV2.openQuery could also treat an imported thread as resumable, for example by honoring the stored resumeCursor. Alternatively, the importer could record a conversation head. A maintainer will decide on the fix direction.
The per-session picker idea in #15234 remains a separate feature discussion.
Before submitting
Area
apps/server
Steps to reproduce
claudein~/work/<project>), so~/.claude/projects/<encoded-cwd>/<sessionId>.jsonlexists.agentSessions.importvia the welcome wizard at/welcome, or the per-session picker from [Feature]: Continue a Codex or Claude Code session started in the terminal as a T3 Code thread #15234).Expected behavior
The follow-up resumes the existing Claude Code session (
resume: <sessionId>) and the turn runs.Actual behavior
The turn fails immediately. The thread shows "Provider error / Provider turn failed." and its status becomes Failed. The server logs
orchestration-v2.claude-query-stream-failedfor the thread's provider turn with the cause elided.Running the same thing the adapter does, directly against the CLI, shows the underlying error:
Cause, from reading the code:
AgentSessionImporterwrites the imported provider thread with a strongnativeThreadRefbutnativeConversationHeadRef: nulland no provider turns. InClaudeAdapterV2openQuery,shouldResumeis true only when there is a conversation head, the process already opened the session, orproviderTurnOrdinal > 1. An imported thread has none of those on its first follow-up, somakeClaudeQueryOptionspassessessionId: <imported id>instead ofresume: <imported id>, and the CLI rejects the id it already owns. The adapter's own comment at that spot describes exactly this failure. Theprovider_resume_fallbackinProviderTurnStartServicedoes not catch it, because the ClauderesumeThreadis a no-op that succeeds and the failure happens later at query open.Codex imports are unaffected: the Codex adapter sends
thread/resume { threadId }for the same ref and the turn runs.Impact
Major degradation or frequent failure. Every imported Claude Code session (wizard import or per-session import) fails on its first follow-up, so Claude sessions cannot be continued in T3 Code.
Version or commit
mainat ce90eec (2026-10-03), reproduced on a branch that adds only the per-session picker from #15234 on top of it. Claude Code CLI: 2.1.286 (Claude Code).Environment
macOS (Darwin 27), web client in the dev server (
vp run devwith an isolated--home-dir), Claude Code provider instance with its default home.Logs or stack traces
Turn item persisted for the run:
{"type":"error","title":"Provider error","failure":{"class":"transport_error","message":"Provider turn failed.","code":null,"retryable":null}}.Workaround
None inside T3 Code. Resuming from the terminal with
claude --resume <sessionId>works.Related
Filed by alimohammed1624. Drafted with Claude Fable 5.1 in Claude Code.