[Bug]: Stopping a new Claude thread before the CLI's system/init bricks it: every later turn resumes a session that was never created (V2 regression of #2336)

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 (orchestration-v2 / ClaudeAdapterV2)

Steps to reproduce

Create a new Claude (claudeAgent) thread and send the first message. In my case it had text plus one image attachment, but I don't think the attachment matters.
Press Stop within the first ~2–3 seconds, while the CLI is still starting up (before anything streams back — in my log the SDK had only emitted command_lifecycle: queued, no system/init, no assistant message).
Send any follow-up message (I sent "continue").

Expected behavior

The follow-up starts a turn. The first attempt never reached Claude, so the thread should either open a fresh native session (sessionId) and send the message, or at least offer a way to reset the native session without losing the visible history.

Actual behavior

Every subsequent turn fails instantly with:

Provider error
No conversation found with session ID: 63f9ae9f-a3bf-4601-a74c-2f92cb30d95f

The same error is shown as a toast at the top. The thread is permanently stuck: sending again, restarting the app, or changing the model doesn't help. There is no transcript for that id under ~/.claude/projects/ — Claude Code never got to create the session.

Diagnosis

This is the same outcome as #2336 (closed), but on the V2 code path. #2336 was closed by #13999, which patched apps/server/src/provider/Layers/ClaudeAdapter.ts (V1). That file was deleted on 2026-10-02 by #2829 (new orchestrator), so the fix is gone and ClaudeAdapterV2 doesn't have an equivalent. It is not #15103 (open) — that one is the fresh-session fallback minting a new id and then resuming it; here no fallback runs, the very first id is already dangling.

Timeline from logs/provider/events.<thread>.log, statev2.sqlite (read only) and server.trace.ndjson, times UTC:

time	what
02:38:05.324	`provider-thread.updated` — `status: not_loaded`, `nativeThreadRef: null`
02:38:05.383	`provider-thread.updated` — `nativeThreadRef: { nativeId: "63f9ae9f-…", strength: "strong" }`, `nativeConversationHeadRef: null`. `run-attempt.updated` also records `nativeThreadId: 63f9ae9f-…`. This is ~1 s before the SDK query is even opened.
02:38:06.327	outgoing `query.open` with `sessionId: "63f9ae9f-…"` (fresh session, correct)
02:38:06.341	`provider-turn.updated` ordinal 1 `status: running`
02:38:06.786	incoming `command_lifecycle { state: "queued" }` — the only thing the CLI ever sent
02:38:08.756	outgoing `query.interrupt` (user pressed Stop)
02:38:08.757	outgoing `query.close` — 1 ms later, no grace for the CLI to persist anything
02:38:10.765	`provider-turn.updated` ordinal 1 `status: interrupted`
02:38:12.356	outgoing `query.open` with `resume: "63f9ae9f-…"` for the follow-up
02:38:12.803	incoming `result { subtype: "error_during_execution", num_turns: 0, errors: ["No conversation found with session ID: 63f9ae9f-…"] }`
02:39:41	same again for the next message

No system/init was ever received for that id (grep -c '"type":"system"' on the provider log is 0), and ~/.claude/projects/<cwd>/63f9ae9f-….jsonl does not exist.

Why the follow-up resumes instead of creating, ClaudeAdapterV2.ts openQuery (current main 1e2ecbd):

const hasPersistedProviderTurn =
  turnInput.nativeThreadHasTurns ?? turnInput.providerTurnOrdinal > 1;
const shouldResume =
  resumeSessionAt !== undefined || openedWithResume || hasPersistedProviderTurn;

and ProviderTurnStartService.ts computes nativeThreadHasTurns from attempts that have a provider turn and carry the current native id:

const deliveredAttemptIds = new Set(projection.providerTurns.map((turn) => turn.runAttemptId));
const acceptedAttempts = projection.attempts.filter(
  (source) => source.providerThreadId === providerThread.id && deliveredAttemptIds.has(source.id),
);
const nativeInputRunIds = new Set(
  acceptedAttempts
    .filter((source) => source.nativeThreadId !== undefined &&
                        source.nativeThreadId === runningProviderThread.nativeThreadRef?.nativeId)
    .map((source) => source.runId),
);
// …
nativeThreadHasTurns: nativeInputRunIds.size > 0 || …

Run 1 has a provider turn (interrupted) and its attempt carries nativeThreadId: 63f9ae9f-…, so nativeThreadHasTurns is true and the adapter passes resume for a session the CLI never created. The interrupted turn counts as proof that the native conversation exists, but "we sent query.open" and "the CLI wrote a transcript" are different things, and the gap between them is exactly where Stop landed.

Two things seem to combine here:

The native id is recorded as a strong ref (and the attempt is marked as having that native id) before the SDK acknowledges the session. Claude thread permanently fails with "No conversation found with session ID" after fresh-session fallback resumes a newly minted id #15103 raises the same point for the fallback path.
The V2 interrupt path does existing.query.interrupt → existing.query.close back to back, so a Stop during CLI startup never lets the first prompt get persisted. V1 had a 3 s grace for this since fix(server): let Claude abort turns before closing sessions #13999.

Possible directions (not tested):

Don't count a provider turn toward nativeThreadHasTurns unless the CLI confirmed the session (a system/init or a result with session_id was received for that native id), or keep nativeThreadRef.strength as something weaker until then and let openQuery use sessionId for a never-confirmed id.
Port the abort grace from fix(server): let Claude abort turns before closing sessions #13999 to ClaudeAdapterV2's interrupt handler.
As a safety net: when a resume open returns error_during_execution with num_turns: 0 and "No conversation found", retry once with sessionId for the same id (or a new one) instead of failing the turn — this would also unbrick the threads that already exist. The thread's history is all in T3, so nothing visible would be lost.

Impact

Blocks work completely — the thread is unusable from the UI.

Version or commit

Desktop AppImage 0.0.46-nightly.20261004.2657. The relevant code is unchanged on main as of 1e2ecbd (2026-10-05).

Environment

Linux x64 (kernel 7.0.0), desktop app (server mode: desktop, loopback), Claude Code CLI 2.1.287, provider claudeAgent, model claude-fable-5-1[1m], runtime mode full-access.

Logs or stack traces

# logs/provider/events.<thread>.log (trimmed; ids other than the session id shortened)
02:38:06.327Z outgoing query.open   { sessionId: "63f9ae9f-a3bf-4601-a74c-2f92cb30d95f", model: "claude-fable-5-1[1m]", effort: "medium", permissionMode: "bypassPermissions", cwd: "<project>" }
02:38:06.786Z incoming command_lifecycle { state: "queued", session_id: "63f9ae9f-…" }
02:38:08.756Z outgoing query.interrupt
02:38:08.757Z outgoing query.close
02:38:12.356Z outgoing query.open   { resume: "63f9ae9f-a3bf-4601-a74c-2f92cb30d95f", effort: "high", … }
02:38:12.803Z incoming result       { subtype: "error_during_execution", is_error: true, num_turns: 0, duration_ms: 0,
                                      errors: ["No conversation found with session ID: 63f9ae9f-a3bf-4601-a74c-2f92cb30d95f"] }
02:39:41.523Z outgoing query.open   { resume: "63f9ae9f-…", … }
02:39:41.929Z incoming result       { subtype: "error_during_execution", …, errors: ["No conversation found with session ID: 63f9ae9f-…"] }

# statev2.sqlite — orchestration_v2_projection_provider_threads.payload_json (read only)
"nativeThreadRef": {"driver":"claudeAgent","nativeId":"63f9ae9f-a3bf-4601-a74c-2f92cb30d95f","strength":"strong"},
"nativeConversationHeadRef": null, "status": "idle", "firstRunOrdinal": 1, "lastRunOrdinal": 3

# orchestration_events — provider-turn.updated, ordinal 1
02:38:06.341Z status: running
02:38:10.765Z status: interrupted   (completedAt 02:38:10.757Z)

# ~/.claude/projects/<cwd>/   → no 63f9ae9f-* transcript exists anywhere under ~/.claude

Screenshots, recordings, or supporting files

Not attaching the screenshot since it shows the prompt content. What it shows: the first user message, then a "Run interrupted · Run interrupted by user" divider, then for each follow-up a "Provider error — No conversation found with session ID: 63f9ae9f-…" row, plus the same text in a red toast at the top of the window.

Workaround

None from inside the app. Starting a new thread works. The stuck one can only be repaired by editing statev2.sqlite (I haven't).

Filed by

Debugged with Claude Code (claude-fable-5-1) running inside T3 Code.

@ThallesP

Note

Grok responding on behalf of Julius.

Triage

Thanks @ThallesP for the thorough report, including the timing and the trace back to #2336. It made the race easy to follow. This reproduces on current main (1e2ecbd), and it's separate from #15103 and not covered by #15770.

What I found

#15103 was the fresh-session fallback, where a newly minted id was opened with resume; #15770 addressed that by passing nativeThreadHasTurns, which is false for a new id. This thread never takes that path. Claude's resumeThread succeeds, so the fallback doesn't run, and the id that fails is the original one.

The sequence on main:

ensureThread allocates a session id and makeProviderThread stores it as strength: "strong" before the CLI is contacted. ProviderTurnStartService writes that id onto the run attempt, then startTurn opens the query.
openQuery emits provider_turn.updated (running) as soon as the SDK query object exists, before system/init or any transcript, so Stop during CLI startup still leaves an interrupted provider turn for that attempt.
interruptTurn calls query.interrupt and then query.close immediately. The 3-second abort grace from fix(server): let Claude abort turns before closing sessions #13999 lived only in the V1 ClaudeAdapter (settleInterruptedTurn / CLAUDE_INTERRUPT_GRACE) and went away with that file in feat(orchestrator): introduce new orchestrator #2829. Without it, a Stop that lands while the command is still queued closes the CLI before ~/.claude/projects/ has a transcript, which matches the 1 ms gap you saw.
The next turn resumes that id. nativeThreadHasTurns is true because the interrupted attempt has a provider turn with the same native id, and openedNativeThreads is set after a successful SDK open, which only means the query object was created. shouldResume then sends resume instead of sessionId. The CLI returns error_during_execution with num_turns: 0 and No conversation found with session ID: …, providerFailureFromResult fails the turn, and the strong ref stays, so every later send, model change, and restart repeats it.

Likely fix area

These line up with the options in your report:

Count a session as resumable only once the CLI has confirmed it, rather than when T3 has opened a query and recorded a provider turn (openedNativeThreads and nativeThreadHasTurns currently count the latter).
Port the interrupt grace period to ClaudeAdapterV2. That narrows the race but wouldn't recover threads whose transcript was never written.
On a No conversation found result with num_turns: 0, retry once with a fresh sessionId open (same id or a new one) instead of failing closed, which would also unstick threads already in this state. The visible history lives in T3, not in the missing Claude transcript.

Until then, starting a new thread is the workaround.

A maintainer will decide on the fix direction.

Proposed fix in #15866: ClaudeAdapterV2.resumeThread checks the CLI's session storage before a resume and fails when there is no conversation, so the turn start falls back to a fresh native session. The PR also documents a CLI window (after system/init, before the first persisted prompt) where the id is dead for both --resume and --session-id, which is why the check is reactive instead of a persisted flag.

Same root cause as described on #20334, different trigger — posting a real-world occurrence in case it helps #15866.

Setup

T3 Code 0.1.0 (com.t3tools.t3code, latest release v0.1.0), Claude Code CLI 2.1.302, macOS, Claude Opus 5.5.
Two native Claude instances in one workspace, separate homes:
- claudeAgent -> homePath: ~/.claude-t3
- claudeAgent2 ("Claude 2 (max2)") -> homePath: ~/.claude-t3-max2

Trigger: the source account hit its usage limit, so T3 handed the thread to the other instance.
The thread (957cfee0-..., cwd ~/Desktop/gry/magazyn) was running on claudeAgent. On the last turn of that account:

{"type":"result","is_error":true,"api_error_status":429,"api_error_origin":"first_party","api_error":"usage_limit_reached","result":"You've hit your session limit \u00b7 resets 1:50pm (Europe/Warsaw)","session_id":"fa50b488-8431-41eb-ae5e-726e86f70753"}

T3 then ran a context handoff to claudeAgent2 (delta bundle: "Covered app runs: 116-263", "Selected 10 intact items; omitted 585 items") and opened the query on the target with the source account's native session id:

{"type":"query.open","options":{"model":"claude-opus-5-5","resume":"0de286a3-d8f8-48ec-a463-8d12e2a95f12","cwd":"~/Desktop/gry/magazyn","permissionMode":"bypassPermissions"}}

Result: every turn on the target fails identically and no fresh-session fallback takes over.

{"type":"result","subtype":"error_during_execution","is_error":true,"num_turns":0,"session_id":"0de286a3-...","errors":["No conversation found with session ID: 0de286a3-d8f8-48ec-a463-8d12e2a95f12"],"duration_ms":0}

Three consecutive failures: two follow-ups ("go on") and a delegated-subagent completion notification. The thread is wedged — the UI shows "Provider error" and the handoff stays "Context handoff pending"; a still-running delegated subagent keeps producing notifications that all hit the same wall.

Why the id cannot be found: the transcript exists only in the source home, ~/.claude-t3/projects/-Users-dawid-Desktop-gry-magazyn/0de286a3-....jsonl (its CLI continuation is fa50b488-....jsonl). In the target home, ~/.claude-t3-max2/projects/-Users-dawid-Desktop-gry-magazyn/ contains no transcripts at all (only memory/).

The stale id belongs to the thread, not to the instance, so it survives the switch — same as the maintainer's explanation on #20334. One extra detail that may matter for the handoff path: this thread has been hopping between the two accounts, an earlier handoff at run 116 went from-provider-instance:claudeAgent2 to-provider-instance:claudeAgent:e28e04c9-..., so the persisted native id is whichever account ran the thread last.

I have not rebound the thread yet; per #20334 switching it to an ACP provider is the recovery that worked there.

We hit this repeatedly on a headless t3 serve (0.0.4x nightlies of 2026-09-19 and 2026-09-21; the resume path is unchanged in 0.1.1-nightly.20261017.3238) and have a deterministic reproduction plus a concrete ask.

Root cause as we read it. updateResumeCursor stores whatever session id the Claude CLI reports for the session that is starting. If that session dies before it flushes its transcript (we kill it two seconds after start; a user typing into a thread while its model is being re-pinned does the same), no <id>.jsonl is ever written, but T3 already stored the id. From then on every turn runs --resume <id> and fails with No conversation found with session ID <id>, and the cursor is never re-derived. The thread's status still reads ready, so nothing looks wrong until someone types.

Reproduction (scratch thread, 2026-09-21):

New claudeAgent thread, one completed turn. Cursor resume=c362d324…, transcript present.
Dispatch a message and stop the thread two seconds later (session killed while starting).
Cursor is now resume=70c59a34…, for which no transcript exists on disk.
Every later message: turn/setPermissionMode failed, No conversation found with session ID 70c59a34…, Claude runtime stream failed. Permanently.

What we ask for, most useful first:

Do not store a new resume id until the session has proved itself (first completed turn, or the transcript file exists). A session that closes before that leaves the previous working cursor in place.
Fail soft on No conversation found: start a fresh session for the thread instead of failing every turn forever.
A supported cursor reset (thread.session.set { resumeCursor: null } or a --fresh-session turn option). Today thread/rollback clears it only when numTurns covers every turn, which discards the conversation.
Refuse or serialize a model re-pin while a turn is in flight.

Workaround we use: re-pin the thread to the home it came from, stop it, and wake it. Sometimes that recovers the original session; sometimes it mints a new one and the history is gone. Which one happens is not under the operator's control, so a real reset would help a lot. Happy to test #15866 on our server.

Verification blocked on this Linux triage VM at main b5a226e49c: the required T3 Browser tools are absent (preview_status and preview_open both return tool-not-found). No stop-before-init attempt ran, so this is not a failure to reproduce. The existing report provides detailed steps and logs; no additional reporter information is needed yet. This needs a triage environment with the collaborative Browser panel to verify the first-message → Stop before init → follow-up sequence. Leaving open.

Another occurrence, with a different trigger: T3 moved the thread to a fresh native session, but the turn that opened it never sent the CLI a prompt. Fresh ids can therefore end up never persisted even when nobody presses Stop. #15866's reactive check would cover this.

Setup: T3 Code 0.1.1 (macOS), Claude Code CLI 2.1.308, claude-opus-5-5. A long-running Claude thread, 268 runs; its native transcript was about 270 MB.

Sequence (UTC, 2026-10-22), from logs/provider/events.<thread>.log and statev2.sqlite (read only):

time	what
07:07:54	Run 264 fails with "Provider turn failed." while the CLI turn keeps running in the original session `a0680532-…`.
07:08–07:16	Runs 265–267 are rejected: "the previous turn is still running".
07:29:18	A background subagent of run 260 finishes. Run 268 is created for the notification (`kind: background_task`).
07:29:20.069	`context-handoff.updated` `strategy: full_thread_summary`, plus `context-transfer.updated` `resolution: portable_context`.
07:29:20.466	`provider-thread.updated` sets `nativeThreadRef` to a new id `b756919e-…` (`strength: strong`). `run-attempt.updated` stamps the same id.
07:29:21.325	The old query (`a0680532-…`) is closed.
07:29:23.377	`query.open` with `sessionId: b756919e-…`. That is correct for a new id. The CLI runs its SessionStart hooks (`hook_started`/`hook_response` carry `session_id: b756919e-…`).
07:29:23.697	Run 268 completes. No `prompt.offer` is ever sent on this query.
07:59:24	`query.close` (idle).
15:28:38	The next user turn: `query.open` with `resume: b756919e-…`, then `result/error_during_execution`, `num_turns: 0`, "No conversation found with session ID: b756919e-…".

So the new id got a provider turn (run 268, completed), and its attempt carries the native id. That is enough for nativeThreadHasTurns to be true, but the CLI never persisted a transcript, because it writes the JSONL only when the first prompt arrives. ~/.claude/projects/<cwd>/b756919e-….jsonl did not exist. The original a0680532-….jsonl was intact the whole time.

Also broken: fork. Forking the thread from an earlier message sends session.fork with sessionId: b756919e-… and upToMessageId: <a message in a0680532>. It fails with "Claude Agent SDK query failed.", so forking doesn't work as an escape hatch either.

Workaround that unbricked it: copy the original transcript to the missing id, cp a0680532-….jsonl b756919e-….jsonl (plus the a0680532-…/ subagents folder), in the same project directory. The next turn resumed b756919e-… normally.

Two notes for #15866:

This path confirms that system/init or hook events for an id don't prove a transcript exists. Here the CLI emitted session-scoped events for b756919e-…, but no prompt ever reached it.
A turn that only delivers a notification, without sending a prompt, probably shouldn't count toward nativeThreadHasTurns for a freshly minted id.

Another occurrence, with a third trigger: switching a thread back to a provider instance whose only earlier run failed before the CLI started. #15866's reactive check would stop the error, but this case shows a second effect that the check alone doesn't fix: the context handoff.

Setup: T3 Code 0.1.3-nightly.20261025.3655 (Linux, WSL2), Claude Code CLI 2.1.310, claude-opus-5-5. Three claudeAgent instances in one workspace: instance P (custom binaryPath launcher) and native instances A and B, each with its own home.

Sequence (UTC, 2026-10-25):

time	what
02:13	New thread on P. Run 1 fails: P's launcher refused to start and exited before the CLI ran, so there was no `system/init` and no transcript. T3 still stored native id `1a54ba68-1d63-4290-ac61-e4cb4327abd5` for P.
later	I switch the thread to A. Runs 2–103 work normally. A received a full handoff.
19:03	A hits its usage limit, so I switch back to P (launcher fixed by then). The handoff item says `Covered app runs: 2-103`. P is treated as having participated in run 1. T3 resumes `1a54ba68-…`, and the turn fails with `No conversation found with session ID: 1a54ba68-1d63-4290-ac61-e4cb4327abd5`. There is no `1a54ba68-*.jsonl` anywhere under P's home.
19:10	I switch to B (never used in this thread) instead. It gets the full handoff `1-104` and works.

Second effect, the handoff. docs/internals/context-handoffs.md sends "the delta since that provider last participated". A run that failed before the CLI ever started still counts as participation. So even if #15866's check makes P fall back to a fresh native session, that fresh session would get only the delta 2-103. It would miss run 1, which here holds the thread's first user message.

Suggested addition: when the turn start falls back to a fresh native session (or the stored id has no persisted conversation), treat the instance as never having participated, and send the full handoff.

Workaround: move the thread to an instance that has never run in it. Check that the handoff item covers run 1.

Another occurrence, with a different trigger: moving to a new OS install without carrying over every Claude transcript.

Setup: T3 Code 0.1.3-nightly.20261027.3754, Linux, two native Claude instances with separate config directories, used from the mobile app.

Sequence: A long-running thread's provider thread on instance A kept a strong nativeThreadRef, with the last successful turn on 2026-10-23. The transcript stayed in the old home directory and is absent from A's config directory. The thread then ran on instance B. Each switch back to A (2026-10-28 and 2026-10-31) opened a query with resume: <id> and got error_during_execution / No conversation found with session ID in about 15ms. Switching back to B works.

Cause: resumeThread calls hasEmptyClaudeTranscript, which returns false when no transcript file exists, so the provider_resume_fallback path never runs. The failed turn also leaves nativeThreadRef in place. The check is unchanged on main at 961026c6.

Scope: 8 of 11 provider threads on this instance reference sessions missing from its config directory. All 8 transcripts exist in the old home directory.

#15866 describes the fix this needs: treating a definitely missing transcript as eligible for fresh-session recovery. It would also recover these threads.

Produced by Claude Opus 5.5 in Claude Code via T3 triage.

Another occurrence, with a different trigger: the first turn after the V1 → V2 migration of a long legacy Claude thread. Nobody pressed Stop.

Setup: T3 Code 0.1.6 (Linux), claudeAgent, claude-opus-5-5. Long-running thread (115 turns, three auto-compactions). Its native transcript is ~166 MB.

Sequence (UTC), from logs/provider/events.<thread>.log, state.sqlite and statev2.sqlite (read only):

time	what
2026-10-31 03:21	Last successful V1 turn. `provider_session_runtime.resume_cursor_json` in `state.sqlite` holds `resume: f5b96a67-…`. That transcript exists and still resumes fine with `claude --resume`.
2026-11-01 16:02	V2 legacy import of the thread (`orchestration_v2_legacy_imports`: 682 messages, no `last_error`). The native session is not reused. A `manual_context` handoff from `legacy` is created, and the provider thread gets a new `nativeThreadRef: { nativeId: "4c78df73-…", strength: "strong" }`.
2026-11-02 13:57:42.540	First message after the update: outgoing `query.open` with `sessionId: "4c78df73-…"` (fresh) + `prompt.offer` with the handoff (~14 KB). No incoming event at all is logged for this run: no `command_lifecycle`, no `system/init`, no `result`. `~/.claude/projects/<cwd>/4c78df73-….jsonl` is never created.
13:58:31, 13:58:49, 13:59:02	Next three messages: `query.open` with `resume: "4c78df73-…"`. Again nothing incoming is logged.
14:49:52, 15:49:49	`query.open` with `resume: "4c78df73-…"` → `result { subtype: "error_during_execution", num_turns: 0, errors: ["No conversation found with session ID: 4c78df73-…"] }`

All six run attempts are failed, and the provider thread keeps the same strong native ref, so the thread can't recover. #15866's reactive check would cover the error.

Starting a fresh session after migration is expected (#14871). The problem is the same as in this issue: the first fresh run never persisted, and every later turn resumes the dangling id. One difference from the original report: I don't know why the first run produced no CLI output at all. Even command_lifecycle: queued never arrived, and nobody pressed Stop.

Redacted provider log excerpt (prompt contents and paths removed)

[2026-10-31T03:21:54.519Z] NTIVE: {"method":"claude/result/success","providerThreadId":"f5b96a67-6417-476f-a7f4-7861c2ddadfc","payload":{"subtype":"success","is_error":false,"session_id":"f5b96a67-6417-476f-a7f4-7861c2ddadfc"}}
[2026-10-31T03:21:54.542Z] CANON: {"type":"turn.completed","threadId":"0d718154-9daf-43ae-a5e5-6072004fe170","payload":{"state":"completed","stopReason":"end_turn"}}
[2026-10-31T03:34:14.878Z] CANON: {"type":"session.exited","threadId":"0d718154-9daf-43ae-a5e5-6072004fe170","payload":{"reason":"Session stopped","exitKind":"graceful"}}
[2026-11-02T13:57:42.540Z] NTIVE: {"providerSessionId":"provider-session:provider-instance:claudeAgent:thread:0d718154-9daf-43ae-a5e5-6072004fe170:40795242-f7f5-4f7b-ab77-8a7ded977a93","direction":"outgoing","type":"query.open","options":{"model":"claude-opus-5-5","sessionId":"4c78df73-b8a1-4721-af99-c6b46f487733","effort":"xhigh","permissionMode":"bypassPermissions","includePartialMessages":true,"hasExtraArgs":true,"hasCanUseTool":true,"hasEnvironment":true,"hasMcpServers":true,"cwd":"<redacted>"}}
[2026-11-02T13:57:42.541Z] NTIVE: {"providerSessionId":"provider-session:provider-instance:claudeAgent:thread:0d718154-9daf-43ae-a5e5-6072004fe170:40795242-f7f5-4f7b-ab77-8a7ded977a93","direction":"outgoing","type":"prompt.offer","message":{"role":"user","uuid":"e76a0773-b3b1-4dc9-8f8f-97bac64e4942","content":"Context handoff (manual_context): <rest redacted, 14150 chars total>"}}
[2026-11-02T13:58:31.387Z] NTIVE: {"providerSessionId":"provider-session:provider-instance:claudeAgent:thread:0d718154-9daf-43ae-a5e5-6072004fe170:40795242-f7f5-4f7b-ab77-8a7ded977a93","direction":"outgoing","type":"query.open","options":{"model":"claude-opus-5-5","resume":"4c78df73-b8a1-4721-af99-c6b46f487733","effort":"medium","permissionMode":"bypassPermissions","includePartialMessages":true,"hasExtraArgs":true,"hasCanUseTool":true,"hasEnvironment":true,"hasMcpServers":true,"cwd":"<redacted>"}}
[2026-11-02T13:58:31.388Z] NTIVE: {"providerSessionId":"provider-session:provider-instance:claudeAgent:thread:0d718154-9daf-43ae-a5e5-6072004fe170:40795242-f7f5-4f7b-ab77-8a7ded977a93","direction":"outgoing","type":"prompt.offer","message":{"role":"user","uuid":"cb17c367-4218-44af-a01d-eaa1b2c5e903","content":"Context handoff (manual_context): <rest redacted, 896 chars total>"}}
[2026-11-02T13:58:49.379Z] NTIVE: {"providerSessionId":"provider-session:provider-instance:claudeAgent:thread:0d718154-9daf-43ae-a5e5-6072004fe170:40795242-f7f5-4f7b-ab77-8a7ded977a93","direction":"outgoing","type":"query.open","options":{"model":"claude-opus-5-5","resume":"4c78df73-b8a1-4721-af99-c6b46f487733","effort":"medium","permissionMode":"bypassPermissions","includePartialMessages":true,"hasExtraArgs":true,"hasCanUseTool":true,"hasEnvironment":true,"hasMcpServers":true,"cwd":"<redacted>"}}
[2026-11-02T13:58:49.379Z] NTIVE: {"providerSessionId":"provider-session:provider-instance:claudeAgent:thread:0d718154-9daf-43ae-a5e5-6072004fe170:40795242-f7f5-4f7b-ab77-8a7ded977a93","direction":"outgoing","type":"prompt.offer","message":{"role":"user","uuid":"8843a0d4-6b6a-4baa-b527-1faf9ab1975c","content":"Context handoff (manual_context): <rest redacted, 839 chars total>"}}
[2026-11-02T13:59:02.663Z] NTIVE: {"providerSessionId":"provider-session:provider-instance:claudeAgent:thread:0d718154-9daf-43ae-a5e5-6072004fe170:40795242-f7f5-4f7b-ab77-8a7ded977a93","direction":"outgoing","type":"query.open","options":{"model":"claude-opus-5-5","resume":"4c78df73-b8a1-4721-af99-c6b46f487733","effort":"medium","permissionMode":"bypassPermissions","includePartialMessages":true,"hasExtraArgs":true,"hasCanUseTool":true,"hasEnvironment":true,"hasMcpServers":true,"cwd":"<redacted>"}}
[2026-11-02T13:59:02.664Z] NTIVE: {"providerSessionId":"provider-session:provider-instance:claudeAgent:thread:0d718154-9daf-43ae-a5e5-6072004fe170:40795242-f7f5-4f7b-ab77-8a7ded977a93","direction":"outgoing","type":"prompt.offer","message":{"role":"user","uuid":"3b33e712-d2b2-4941-8365-a1c4ff53f3f1","content":"Context handoff (manual_context): <rest redacted, 838 chars total>"}}
[2026-11-02T14:49:52.051Z] NTIVE: {"providerSessionId":"provider-session:provider-instance:claudeAgent:thread:0d718154-9daf-43ae-a5e5-6072004fe170:40795242-f7f5-4f7b-ab77-8a7ded977a93","direction":"outgoing","type":"query.open","options":{"model":"claude-opus-5-5","resume":"4c78df73-b8a1-4721-af99-c6b46f487733","effort":"medium","permissionMode":"bypassPermissions","includePartialMessages":true,"hasExtraArgs":true,"hasCanUseTool":true,"hasEnvironment":true,"hasMcpServers":true,"cwd":"<redacted>"}}
[2026-11-02T14:49:52.052Z] NTIVE: {"providerSessionId":"provider-session:provider-instance:claudeAgent:thread:0d718154-9daf-43ae-a5e5-6072004fe170:40795242-f7f5-4f7b-ab77-8a7ded977a93","direction":"outgoing","type":"prompt.offer","message":{"role":"user","uuid":"0ee8643a-0f02-4f77-ace5-a4db2928a2c4","content":"Context handoff (manual_context): <rest redacted, 838 chars total>"}}
[2026-11-02T14:49:52.057Z] NTIVE: {"providerSessionId":"provider-session:provider-instance:claudeAgent:thread:0d718154-9daf-43ae-a5e5-6072004fe170:40795242-f7f5-4f7b-ab77-8a7ded977a93","direction":"incoming","type":"result","subtype":"error_during_execution","is_error":true,"duration_ms":0,"num_turns":0,"session_id":"4c78df73-b8a1-4721-af99-c6b46f487733","errors":["No conversation found with session ID: 4c78df73-b8a1-4721-af99-c6b46f487733"]}
[2026-11-02T15:49:49.968Z] NTIVE: {"providerSessionId":"provider-session:provider-instance:claudeAgent:thread:0d718154-9daf-43ae-a5e5-6072004fe170:40795242-f7f5-4f7b-ab77-8a7ded977a93","direction":"outgoing","type":"query.open","options":{"model":"claude-opus-5-5","resume":"4c78df73-b8a1-4721-af99-c6b46f487733","effort":"medium","permissionMode":"bypassPermissions","includePartialMessages":true,"hasExtraArgs":true,"hasCanUseTool":true,"hasEnvironment":true,"hasMcpServers":true,"cwd":"<redacted>"}}
[2026-11-02T15:49:49.969Z] NTIVE: {"providerSessionId":"provider-session:provider-instance:claudeAgent:thread:0d718154-9daf-43ae-a5e5-6072004fe170:40795242-f7f5-4f7b-ab77-8a7ded977a93","direction":"outgoing","type":"prompt.offer","message":{"role":"user","uuid":"9f560dbf-be11-45b0-b8d2-e2f60013c1ff","content":"Context handoff (manual_context): <rest redacted, 839 chars total>"}}
[2026-11-02T15:49:49.975Z] NTIVE: {"providerSessionId":"provider-session:provider-instance:claudeAgent:thread:0d718154-9daf-43ae-a5e5-6072004fe170:40795242-f7f5-4f7b-ab77-8a7ded977a93","direction":"incoming","type":"result","subtype":"error_during_execution","is_error":true,"duration_ms":0,"num_turns":0,"session_id":"4c78df73-b8a1-4721-af99-c6b46f487733","errors":["No conversation found with session ID: 4c78df73-b8a1-4721-af99-c6b46f487733"]}

Workaround: claude --resume f5b96a67-… outside T3 works.

Navigation Menu

Repository navigation

[Bug]: Stopping a new Claude thread before the CLI's system/init bricks it: every later turn resumes a session that was never created (V2 regression of #2336) #15854

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Diagnosis

Impact

Version or commit

Environment

Logs or stack traces

Screenshots, recordings, or supporting files

Workaround

Filed by

Triage

What I found

Likely fix area

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: Stopping a new Claude thread before the CLI's system/init bricks it: every later turn resumes a session that was never created (V2 regression of #2336) #15854

Description

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Diagnosis

Impact

Version or commit

Environment

Logs or stack traces

Screenshots, recordings, or supporting files

Workaround

Filed by

Activity

juliusmarminge commented on Oct 5, 2026

Triage

What I found

Likely fix area

ThallesP commented on Oct 5, 2026

Dawidekk523 commented on Oct 18, 2026

MattRiddell commented on Oct 18, 2026

juliusmarminge commented on Oct 22, 2026

gnestor commented on Oct 22, 2026

DrugsAreMyLife commented on Oct 26, 2026

tristanmanchester commented on Oct 31, 2026

znxr commented on Nov 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions