Repository navigation
fix(server): a Claude fork no longer reads as finished the moment it starts - #26405
Batuhan1999 wants to merge 1 commit into
Conversation
…starts A fork's transcript opens with its own view of the parent's Agent call, a tool result reading "Fork started — that fork is you." The adapter took it for the launch result and settled the fork as completed within milliseconds, so a running fork showed as done, and a fork later interrupted by a steer showed as failed after 0s. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — The change prevents a Claude fork's launch acknowledgment from prematurely marking it finished. Parent results and task notifications continue to control completion, keeping the change narrowly scoped. You can add or adjust custom eligibility rules. Learn more. |
|
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Ignore fork launch acknowledgement apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts, apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.test.ts |
The adapter skips a result whose tool-use ID matches the enclosing message’s parent tool-use ID. The test verifies that the launch acknowledgement is not recorded as the result and that a later interrupted tool result settles the subagent as failed. |
Priority:
Estimated code review effort: 2 (Simple) | ~10 minutes
Change: Bug fix
Suggested labels: bugfix, size:S
Suggested reviewers: juliusmarminge
Merge Risk: 
Minimal · up to 47843
-
No actionable merge-blocking risk remains from the reviewed change.
Pre-merge checks: 
4
-
Full details: Title check
-
Explanation
The title follows conventional commit format and names the change: a Claude fork no longer reads as finished when it starts. The raw summary and PR objectives both describe a guard in ClaudeAdapterV2 that skips a launch-call tool_result from the fork's own transcript, so the title matches the main change. It is specific enough for a teammate scanning history to understand the primary fix.
Full details: Description check
-
Explanation
The description follows the template. It has Problem, Change, Scope and approval, and Verification sections. The Problem section explains the bug, the cause, and reproduction timing from a real session. The Change section explains the guard and why only the parent's result should settle the subagent. The Scope section argues the fix is small and obvious. The Verification section lists a new focused test with before and after results and the suites run. It also notes what was not checked, which the template asks for. The description does not include a model and harness line in the required form, but it does include one at the end.
-
Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.
|
Closing in favour of #26459, which makes the same change. Thanks for the work here! |
Problem
A Claude fork (
Agentwithsubagent_type: "fork") is marked finished a few milliseconds after it starts. A running fork shows as completed, with the result "Fork started — that fork is you." A foreground fork that the user's steer interrupts later shows as Failed 0s, even though it worked for minutes.The cause: a fork inherits the parent's history, so its transcript opens with its own copy of the parent's
Agentcall. That copy is atool_resultfor the parent'stool_use_id, reading "Fork started — that fork is you.", and arrives withparent_tool_use_idset to that same id.ClaudeAdapterV2took it for the launch result and settled the subagent ascompleted, withcompletedAtset at launch.Seen in a real session (times from the Claude session log and the T3 projection):
Agent(fork, foreground).tool_result"Fork started — that fork is you."completed,completedAt10:04:08.253.[Request interrupted by user for tool use]arrives, and the status becomesfailedwhilecompletedAtstays at launch. The UI shows "Failed 0s".Change
When a
tool_resultfor a subagent's launch call arrives in a frame whoseparent_tool_use_idis that same call, it comes from inside the subagent's own transcript, so the adapter skips it. Only the parent's own result for the call settles the subagent. Background launch acks and task notifications are handled as before.Scope and approval
This is a very small, focused fix for an obvious bug: a 5-line guard in one adapter branch, plus one test. The subagent's own copy of its launch call is never the parent's result for it, and settling on it leaves the subagent's status and elapsed time wrong.
Verification
does not settle a fork on the launch result its own transcript opens withinClaudeAdapterV2.test.tsreplays the frames from the session above:task_started, then the fork's "Fork started" frame, then the parent's interrupted result.expected [ 'running', 'completed' ] to deeply equal [ 'running', 'failed' ].runninguntil the parent's result settles it.ClaudeAdapterV2.test.ts: 245/245 pass.ClaudeReplayFixtures.integration.test.ts: 38/38 pass.apps/servertypecheck, lint and format are clean.Separately, a steer-interrupted subagent is still reported as
failed, notinterrupted. This PR leaves that as is.Model and harness: Claude Opus 5.5 in Claude Code (T3 Code).
🤖 Generated with Claude Code