Skip to content

[Bug]: Checkpoint revert fails with "No active provider session with workspace cwd is bound to this thread" even when session projection is ready #10470

Closed

Description

@ss21dq

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 (checkpoint revert / provider session binding)

Steps to reproduce

  1. 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).
  2. Let the app/server go through a restart (in this case: an auto-update from an older nightly to 0.0.38).
  3. 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).
  4. 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

Activity

  1. juliusmarminge commented on Sep 7, 2026

    @juliusmarminge
    Member

    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.

  2. added
    via-triageFiled through npx t3 triage
    bugSomething is broken or behaving incorrectly.
    acceptedfeature request accepted
    on Sep 7, 2026
  3. juliusmarminge commented on Sep 12, 2026

    @juliusmarminge
    Member

    Fixed by #11338 (merged to main) — rewinds recover inactive sessions after restart (replacement session IDs / native boundaries) before rolling back provider history and files.

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

    acceptedfeature request acceptedbugSomething 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