[Bug]: Claude thread resumes the pre-/clear session, so replies go to the old conversation#24153

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

1. Work in a Claude thread until it holds a long session (here ~700K tokens, session A).
2. Send /clear. Claude Code starts a new session B, and the thread keeps working in it.
3. Run a few turns in B (here a /grill-with-docs skill that asked numbered questions Q1–Q13).
4. Some minutes later, reply in the same thread to B's last message ("9. yes, 10. yes, …").

Expected behavior

The reply goes to session B, the one the thread has shown since the /clear.

Actual behavior

The reply resumes session A, the one from before the clear. In the Claude transcripts the reply is written to A's JSONL, with parentUuid set to A's last assistant message from before the /clear. B's questions never show up in A. The agent answers that it has no numbered questions open, even though they're on screen right above. Because A is near the context limit, the turn autocompacts too.

From the user's side, the thread silently swaps the model's memory back to the old conversation. The UI gives no sign of it.

Impact

Major degradation or frequent failure

Version or commit

0.1.1-nightly.20261018.3315 (desktop)

Environment

macOS 26 (Darwin 25.6.0), T3 Code Nightly desktop, Claude Code 2.1.309, Claude Opus 5.5 (1M context)

Logs or stack traces

Workaround

Start a new T3 thread instead of using /clear.

Notes

This is the Claude half of #19356 and #20078. Both were closed as duplicates of #7402. #7402 was then closed as a Codex /clear enhancement, and its last comment says "The Claude session-id restoration described above is a separate provider behavior". That leaves no open issue for it. #19356 traced it to the Claude adapter keeping the nativeThreadRef.nativeId stored at thread creation, rather than the session_id Claude Code reports after /clear. Here too it was triggered by a server restart between the two turns (see Root cause).

Root cause

Traced on main @ 66ee628e0 (apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts), and confirmed in this thread's provider log:

1. The thread's Claude session id is providerThread.nativeThreadRef.nativeId. It is set once, when the provider thread is created (nativeThreadRef: { nativeId: input.nativeThreadId, … }, around line 1670), and never updated afterwards.
2. After /clear, Claude Code reports the new id in system/init (message.session_id). The init handler (around line 9390) only reads permissionMode from it. conversation_reset isn't handled anywhere.
3. Whenever the process has to be reopened, makeClaudeQueryOptions passes resume: input.nativeThreadId (around line 1339), which is still the pre-clear id. That happens after a server restart, after the 30-minute idle release, or after a model or permission change that can't be applied live.

So /clear only holds while the same Claude process stays alive. The first time the process is reopened, the thread goes back to the old conversation.

Possible fix: when system/init (or conversation_reset) carries a session_id that differs from nativeThreadRef.nativeId, persist the new id on the provider thread. That could go through the same provider-thread update the turn-end path already emits (around line 6880), so every later resume targets the current session.