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]: Checkpoint revert fails with "No active provider session with workspace cwd is bound to this thread" even when session projection is ready #10470
Have a thread with several completed turns using the Claude Agent provider (claudeAgent), no isolated worktree (repo opened directly, worktree_path is null for the thread in state.sqlite).
Let the app/server go through a restart (in this case: an auto-update from an older nightly to 0.0.38).
Immediately after the new server comes up, open the thread and use checkpoint revert to roll back to an earlier turn (turn 9 in this case).
Retry the revert.
Expected behavior
Checkpoint revert either succeeds, or transparently re-establishes a provider session bound to the thread's workspace cwd before attempting the revert, the way a new chat message does.
Actual behavior
Checkpoint revert fails immediately, every time, with:
{"turnCount":9,"detail":"No active provider session with workspace cwd is bound to this thread."}
Confirmed via projection_thread_activities in state.sqlite: 8 consecutive checkpoint.revert.failed events for the same thread between 2026-09-07T02:45:16Z and 2026-09-07T03:11:23Z — the last one just 38 seconds after the new server process started (server-runtime.json → startedAt: 2026-09-07T03:10:45.871Z). Same failure also occurred once earlier, on 2026-08-28.
At the time of failure, projection_thread_sessions for the thread already reports status = ready, provider_name = claudeAgent, active_turn_id = NULL — i.e. the projection looks healthy, but checkpoint revert still can't find a live provider process to bind to the workspace cwd. This looks related to the provider-session/projection reconciliation work in #4584, #7719, and #7463, but those are about turns getting stuck on Working after a crash/restart — this is a different trigger: the session projection is already settled (ready), yet the specific checkpoint-revert path still can't obtain a bound session.
Sending a plain chat message to the same thread (starting a fresh turn) is not something I've verified recovers it yet — flagging that as untested, not a confirmed workaround.
Impact
Minor degradation — blocks checkpoint revert on the affected thread; other thread actions (new messages) appear unaffected.
Version or commit
T3 Code (Alpha) 0.0.38 (Windows, desktop installer)
Environment
Windows 11 Pro (10.0.26200), desktop app, Claude Agent provider
Logs or stack traces
state.sqlite / projection_thread_activities:
kind = 'checkpoint.revert.failed'
payload_json = '{"turnCount":9,"detail":"No active provider session with workspace cwd is bound to this thread."}'
created_at: 2026-09-07T02:45:16.143Z, 02:45:51.003Z, 02:46:25.889Z, 02:57:00.328Z,
02:58:31.836Z, 02:58:36.256Z, 03:11:14.390Z, 03:11:23.317Z
(earlier occurrence: 2026-08-28T11:59:33.440Z, 11:59:41.144Z)
server-runtime.json:
{"pid":28088,"host":"127.0.0.1","port":3773,"startedAt":"2026-09-07T03:10:45.871Z"}
projection_thread_sessions (at time of last failure):
status = ready, provider_name = claudeAgent, active_turn_id = NULL
Thanks for the detailed SQLite timeline — this is a real bug, and not a duplicate of the restart-reconciliation issues.
What's going on
projection_thread_sessions.status = ready is persisted orchestration state. Checkpoint revert does not use that. CheckpointReactor.handleRevertRequested asks providerService.listSessions() for a live process with a workspace cwd and fails immediately if none exists:
No active provider session with workspace cwd is bound to this thread.
That matches the 8 checkpoint.revert.failed rows (and the earlier 2026-08-28 pair). Startup reconcile (reconcileProviderSessions from #7719 / #10421) only settles starting / running orphans (or ready sessions marked for update-continuation). An idle thread that already finished its turn is left ready after a restart, with no provider process. A new chat message goes through ensureSessionForThread and recreates one; revert does not.
So the session projection looking healthy is expected here — it's a different trigger from #4584 (stuck Working), #5454 (pending user-input after session death), and #8958 (Codex paginated rollback). The 02:45–02:58 failures on the old process plus the two at 03:11 (38s after 0.0.38 came up) also show this isn't just a cold-start race.
Revert needs a live session for two reasons: git restore cwd, and rollbackConversation (Claude Agent does support rewind). Capture already falls back to project workspaceRoot / worktreePath via resolveCheckpointCwd; revert hard-requires the live session instead. rollbackConversation even has allowRecovery: true, but the reactor never gets there.
Workaround (code-confirmed, not yet tried on this thread)
Send a normal chat message on the same thread, then retry revert. That should spawn the missing session. If it doesn't, say so.
Fix direction
Have revert re-bind / recover a provider session before requiring cwd (same idea as turn-start), and only emit this error when cwd still cannot be resolved. The existing “fail when there is no active session” tests in CheckpointReactor and the orchestration integration suite would need to follow that.
Accepted as a server bug. No extra logs needed unless the workaround fails.
Fixed by #11338 (merged to main) — rewinds recover inactive sessions after restart (replacement session IDs / native boundaries) before rolling back provider history and files.
Activity
juliusmarminge commentedon Sep 7, 2026
Thanks for the detailed SQLite timeline — this is a real bug, and not a duplicate of the restart-reconciliation issues.
What's going on
projection_thread_sessions.status = readyis persisted orchestration state. Checkpoint revert does not use that.CheckpointReactor.handleRevertRequestedasksproviderService.listSessions()for a live process with a workspace cwd and fails immediately if none exists:That matches the 8
checkpoint.revert.failedrows (and the earlier 2026-08-28 pair). Startup reconcile (reconcileProviderSessionsfrom #7719 / #10421) only settlesstarting/runningorphans (orreadysessions marked for update-continuation). An idle thread that already finished its turn is leftreadyafter a restart, with no provider process. A new chat message goes throughensureSessionForThreadand recreates one; revert does not.So the session projection looking healthy is expected here — it's a different trigger from #4584 (stuck
Working), #5454 (pending user-input after session death), and #8958 (Codex paginated rollback). The 02:45–02:58 failures on the old process plus the two at 03:11 (38s after0.0.38came up) also show this isn't just a cold-start race.Revert needs a live session for two reasons: git restore cwd, and
rollbackConversation(Claude Agent does support rewind). Capture already falls back to projectworkspaceRoot/worktreePathviaresolveCheckpointCwd; revert hard-requires the live session instead.rollbackConversationeven hasallowRecovery: true, but the reactor never gets there.Workaround (code-confirmed, not yet tried on this thread)
Send a normal chat message on the same thread, then retry revert. That should spawn the missing session. If it doesn't, say so.
Fix direction
Have revert re-bind / recover a provider session before requiring cwd (same idea as turn-start), and only emit this error when cwd still cannot be resolved. The existing “fail when there is no active session” tests in
CheckpointReactorand the orchestration integration suite would need to follow that.Accepted as a server bug. No extra logs needed unless the workaround fails.
juliusmarminge commentedon Sep 12, 2026
Fixed by #11338 (merged to main) — rewinds recover inactive sessions after restart (replacement session IDs / native boundaries) before rolling back provider history and files.