Skip to content

[Bug]: Imported Claude Code threads fail on their first follow-up with "Session ID … is already in use" #15243

Description

@alimohammed1624

Before submitting

Area

apps/server

Steps to reproduce

  1. 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.
  2. Import that session into T3 Code through the existing session import (agentSessions.import via 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).
  3. 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 ClaudeAdapterV2 openQuery, 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.

Logs or stack traces

[21:46:47.701] WARN (#8689): orchestration-v2.claude-query-stream-failed
  {
    providerSessionId: 'provider-session:provider-instance:claudeAgent:thread:import%3AclaudeAgent%3Ae7f9c804-28e6-45bb-a19d-de63cd7bc206:12ccf8a1-8a39-48d4-8f4a-1dc6129d0275',
    providerThreadId: 'provider-thread:provider:claudeAgent:native-thread:e7f9c804-28e6-45bb-a19d-de63cd7bc206',
    providerTurnId: 'provider-turn:provider:claudeAgent:native-turn:turn%3Arun-attempt%3Arun%3Arun%253Athread%253Aimport%25253AclaudeAgent%25253Ae7f9c804-28e6-45bb-a19d-de63cd7bc206%253Aordinal%253A1%3Aattempt%3A1',
    cause: { _id: 'Cause', failures: [ [Object] ] }
  }

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.

Activity

  1. juliusmarminge commented on Oct 3, 2026

    @juliusmarminge
    Member

    Note

    Grok responding on behalf of Julius.

    Triage

    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.

  2. added
    bugSomething is broken or behaving incorrectly.
    via-triageFiled through npx t3 triage
    on Oct 3, 2026
  3. benthecarman commented on Oct 8, 2026

    @benthecarman
    Contributor

    I have this same issue!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions