Skip to content

[Bug]: Grok thread stays running forever after t3_worktree_handoff; later messages stay queued #35274

Open

Description

@leonhoulier

Note

🤖 Claude Opus 5.5 responding on behalf of leonhoulier

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. Fresh T3 home, Grok provider enabled, a git project.
  2. Start a Grok thread and let one turn finish.
  3. In the next turn, ask the agent to call t3_worktree_handoff with no continuationPrompt.
  4. After the tool returns, send another message.

Expected behavior

The hand-off turn ends, as it does for Codex since #24545, and the next message runs in the new worktree.

Actual behavior

The worktree is created and bound to the thread, but the hand-off run never settles. The thread stays running with the hand-off run active, and every later message stays queued. I watched it for 30+ minutes, reproduced on 3 of 3 fresh threads.

The same test with other providers on the same server:

Provider Hand-off turn Next message
Codex completed runs in the worktree
Claude failed: "The provider event stream closed unexpectedly" (#22971) runs in the worktree
Muse failed: same message runs in the worktree
Grok stays running forever stays queued

From the server trace, in this order:

  1. mcp.tool.t3_worktree_handoff succeeds.
  2. ProviderSessionManager.detach runs. Inside it, AcpAdapterV2.interruptTurn exits Interrupted after about 1.6 s while session/close succeeds.
  3. The run's event stream then fails with ProviderAdapterEventStreamError … Workspace changed., logged as "orchestration V2 provider event ingestion failed".
  4. The ingestion-failure handler in RunExecutionService.ts (around line 1734) calls session.interruptTurn again with requestRuntimeRestart: true before writing the failed terminal. That second AcpAdapterV2.interruptTurn span never ends, so the terminal write after it never runs.

My guess, which I haven't verified: the first interrupt is cut off while it holds runtimeTransitionPermit, or its transition fiber is forked into the session scope the detach just closed. The second interrupt then waits on the permit forever. Claude and Muse don't hang because their interrupts return, as a success or a failure.

Impact

Major degradation or frequent failure

Version or commit

main at e9e934bb3d, also 65c0195b46

Environment

macOS (Darwin 25.2, arm64), Node 24.18.1, Grok CLI 1.0.77, model grok-4.7-build-fast, full access. Isolated dev server (vp run dev --home-dir <tmp> --no-seed), threads driven with t3 thread start/send.

Logs or stack traces

WARN orchestration V2 provider event ingestion failed
  RunExecutionIngestError: Failed while ingesting orchestration V2 run execution run:thread:mcp%3A…:ordinal:2.
  [cause]: ProviderAdapterEventStreamError: Failed while streaming grok provider session … events.
    [cause]: Error: Workspace changed.

Workaround

None found. I didn't try Stop.

Related: #22971 (the same hand-off ends failed for Claude), #24545 (the fix for Codex), #22825 (a draft that waits for the turn's terminal on detach).

Activity

  1. leonhoulier commented on Nov 12, 2026

    @leonhoulier
    Author

    Note

    🤖 Claude Opus 5.5 responding on behalf of leonhoulier

    Draft #22825, merged onto main at e9e934bb3d, resolves this: the Grok hand-off turn completed 2 of 2 times, and the next message ran in the worktree. Results for all four providers are in this #22825 comment.

  2. dmnyc commented on Nov 14, 2026

    @dmnyc

    This also affects GLM via the ACP registry (acpRegistry_glm_agent, glm-5.3-flash) — not in the provider table above. On released 0.1.5, 7 of 10 GLM runs that called t3_worktree_handoff settled as failed: the tool call succeeds, the run fails ~9 ms later with ProviderAdapterEventStreamError: Workspace changed. ("provider event stream closed unexpectedly") — i.e. the Claude/Muse row, not the Grok row. Timeline and run ids in #36209 (closed as a dup of this).

    One gap worth tracking here, since the draft fix (#22825) was closed unmerged: a handoff with continuationPrompt. The queued worktree-continuation run didn't start on its own even after the handoff run settled failed — it only ran after a manual re-prompt ~2 minutes later. None of the matrix tests here or in #22825 exercised that path.

  3. leonhoulier commented on Nov 14, 2026

    @leonhoulier
    Author

    Note

    🤖 Claude Opus 5.5 responding on behalf of leonhoulier

    The Grok hang no longer reproduces on main at 2dd6cddbc3: the hand-off turn completed 3 of 3 times, and the next message ran in the worktree. Details are in this #35390 comment. I didn't test GLM or a hand-off with a continuationPrompt, which dmnyc raised above, so I'm leaving this open.

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

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions