# \[Bug\]: V2 Claude run stays "running" forever after the CLI reports result/success \(thread stuck on "Thinking"\) · Issue \#15197 · pingdotgg/t3code

[View on GitCafe](https://git.cafe/pingdotgg/t3code/issues/15197)

Repository: [pingdotgg/t3code](https://git.cafe/pingdotgg/t3code)

Visibility: public

State: backlog

Priority: 0

## Description

[Discussion and activity](https://git.cafe/pingdotgg/t3code/issues/15197)

---

### Before submitting

- [x] I searched existing issues and did not find a duplicate.
- [x] I included enough detail to reproduce or investigate the problem.

### Area

apps/server (orchestration V2, Claude adapter)

### Steps to reproduce

Intermittent. Happened once in about 120 Claude runs in my local history.

1. Start a new thread with the Claude provider (`claude-opus-5-5[1m]`, `bypassPermissions`) in a worktree.
2. Send a normal coding prompt. The agent runs about 9 tool turns, including a foreground Bash command (tests, build, lint) and a git commit, then writes its final answer.

### Expected behavior

When the Claude CLI emits `result` / `subtype: success` / `terminal_reason: completed`, the run moves to `completed` and the thread goes idle.

### Actual behavior

The final assistant message renders, but the thread keeps showing "Thinking" and the "Working for Xm Ys" timer keeps counting indefinitely.

The provider log shows the turn ended cleanly at `2026-10-03T13:40:46.593Z`. The last two events are:

```json
{"type":"result","subtype":"success","stop_reason":"end_turn","terminal_reason":"completed","is_error":false,"num_turns":9,"duration_ms":49562,"queued_turn_count":0,"result_index":0, ...}
{"type":"command_lifecycle","command_uuid":"ed0f6284-...","state":"completed", ...}
```

Server state in `statev2.sqlite`, checked more than 20 minutes later:

- `orchestration_v2_projection_runs`: `run:thread:<id>:ordinal:1` has `status = running` and `completed_at = NULL`.
- `orchestration_v2_projection_run_attempts`: attempt 1 has `status = running`.
- `orchestration_v2_projection_provider_turns`: the provider turn has `status = running`.
- `orchestration_v2_projection_provider_sessions`: the session has `status = ready`.
- `orchestration_v2_effect_outbox`: no pending or failed rows. No `checkpoint.capture` was ever enqueued for this run, so this is not the `waiting` / stalled-capture case from #15124.

Other details:

- The run had one `task_started` / `task_notification` pair (`local_bash`, `is_backgrounded: false`, `status: completed`) at 13:40:38, about 8 s before the result.
- One `command_execution` turn item ended as `failed` at 13:40:18.
- Neither looks unusual: other runs in the same session with the same patterns completed normally.
- Server trace spans in the 13:40:44–13:40:50 window all exited with `Success`. I could not find an error.

The provider session stays `ready` while the run, attempt and provider turn stay `running`. That suggests the adapter received the `result` but the run-terminal transition was never committed.

### Impact

Major degradation or frequent failure. The thread looks busy forever, and it is unclear whether the agent is still working.

### Version or commit

`0.0.46-nightly.20261003.2623` (`fed41fa88bb2`), the latest nightly at the time of writing.

### Environment

Desktop (AppImage), Linux (Arch-based, Hyprland), Claude provider via Claude Agent SDK, orchestration V2.

### Logs or stack traces

The provider event log and the server trace for the thread are available on request. I'm not attaching them because they contain prompt text and local paths.

### Screenshots, recordings, or supporting files

_No response_

### Workaround

Press Stop, or restart the app.

### Related issues and PRs

- #4452: same symptom on the V1 Claude path (CLI completed, session stuck `running`). Closed as fixed by #5891 and #7719. This report is a V2 recurrence.
- #15124: V2 run shows working after the provider turn succeeds, but that is the `waiting` (checkpoint-pending) state. Here the run never left `running`.
- #14046: client-side "Thinking" until reload. Here the server state itself is stuck, so a client reload alone should not clear it (not yet tested).