Sign up
View stargazersSign up

[Bug]: Claude run stuck running forever and Stop hangs at "Stopping" when a resumed native query never responds#33001

opened1d agobyPphamngocduy98

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

Summary

A Claude Agent run can stay running indefinitely when the native Claude process never answers a newly opened query. After that, clicking Stop shows "Stopping" forever. The run never terminalizes, and the thread can't be used.

Related, but not the same: #24842 (stuck phases with status frames) and #20404 (Stop feedback).

What happened

Version 0.1.8-nightly.20261108.4353, Windows 11 (26200), desktop app, Claude Agent provider (claude-opus-5-5, effort medium, runtime mode auto).

Timeline from the thread's provider event log (logs/provider/events.<threadId>.log) and thread activity:

Time (UTC)Event
11:37:28Previous turn finishes normally: result (subtype: success), then command_lifecycle: completed.
11:38:46.889New run (ordinal 73) starts.
11:38:47.224Outgoing query.open with resume: <previous session id> (a new native query, not a reuse of the existing one).
11:38:47.225Outgoing prompt.offer with the user message.
(nothing)No incoming frame at all: no system/init, command_lifecycle, stream_event, error, or process-exit event. This is the last line in the provider log.
13:33:11User clicks Stop. Thread activity records run_interrupt_request ("Stopped by user"). Nothing is written to the provider log, so no interrupt or close reached the adapter or native process.
16:18+The run is still running (activeRunId = ordinal 73, completedAt: null). The UI shows "Working for 4h 38m" and "Stopping 2h 44m".

At 16:18 UTC, no claude.exe process with --resume=<that session id> existed. The only claude.exe children of the server process belonged to other threads. So the native process for this query either never started or exited, and the adapter never noticed, because no exit, error, or stream-end event was logged.

Expected behavior

  • If the native query produces no frame (not even system/init) within a bounded time after query.open/prompt.offer, or its process exits or never spawns, the run should fail visibly and release the thread.
  • Stop should always terminalize the run, even when the native process is already gone or doesn't acknowledge the interrupt. Mark the run interrupted after a short grace period instead of waiting for the provider indefinitely.

Actual behavior

The run stays running forever, and Stop stays stuck at "Stopping". The only way out appears to be restarting the app or server.

Notes

  • The earlier turns in the same thread (same server instance, started 11:09 UTC) worked normally. Those turns sent prompt.offer on the already-open query. This turn opened a new query with resume instead, about 80 seconds after the previous result, and that new query never produced any output.
  • The thread was long-running (about 73 runs, about 840 timeline items, about 185k cached context tokens).

🤖 Generated with Claude Code

Ppaulonteri2h ago
Synced from GitHub

Still reproduced on the latest stable release, T3 Code 0.1.8. The CLI exit has a separate root-user cause. The hang matches this issue: the run stays running because the CLI exits before the first frame.

Environment

  • Server: T3 Code 0.1.8 on Linux x64 (kernel 6.8.0-149-generic). The process user is root.
  • Client: T3 Code Desktop 0.1.8 on macOS, connected to that server.
  • Claude Code: 2.1.322. Model: claude-opus-5-5.
  • v0.1.8 does not contain "Claude provider query ended before the turn could start."
  • #33008 merged to main at 2026-11-10 10:08 UTC. No release or nightly published after that merge includes it. The newest nightly is v0.1.9-nightly.20261110.4465, published at 09:24 UTC.

What happened

Three Claude threads stayed on Working and showed no assistant text.

  1. New thread, Full access. The user message was at 2026-11-10 08:25 UTC. The provider log shows query.open with permissionMode: bypassPermissions and allowDangerouslySkipPermissions: true, then prompt.offer. There is no incoming frame. Later messages failed in ClaudeAdapterV2.steerTurn and did not start. At 09:51 UTC the server restarted, cancelled the turn, and resumed it. The resume at 09:52 UTC used resume and the same bypass flags. There is still no incoming frame. At 10:05 UTC that run was still running. No Claude Code 2.1.322 process remained for it.

  2. Two existing threads opened turns at 08:27 UTC with the same bypass flags. Those turns also had no incoming frames. The 09:51 UTC restart resumed them. Those resumed runs failed at 10:04 UTC. A follow-up "hi" opened a new query with permissionMode: auto and no bypass flag. The first incoming frame was result with subtype: error_during_execution, then prompt.offer. Those new runs were still running. Older messages stayed queued. One queued run dated from 2026-11-06.

CLI check on the same server, as root

claude -p "Reply with the single word pong." --dangerously-skip-permissions

Exit code 1. The stderr line is:

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

The same prompt without that flag exits 0 and returns a model reply. Other Claude threads on this server that opened with permissionMode: auto did receive incoming frames on 2026-11-10.

Relation

#15882 is the root refusal. Version 0.1.8 can show that reason only after the query stream fails. Here the CLI exits before the first frame, the stream does not fail the turn, and the run stays running. Steer and interrupt then fail because the adapter has no live query. A server restart resumes the stuck turn.

Workaround on this server: start a new thread in Auto. Do not use Full access while the server runs as root. Do not resume a session that already died in Full access.

Reported from a T3 Code triage session. Model: grok-4.7.