fix(server): fork Claude threads after project root changes#22836

Problem

Forking a Claude thread after changing its project's workspace root created a fork whose first turn failed: the SDK searched for the source transcript under the new directory, while it remained under the original one.

Change

Stop restricting forkSession to the current cwd. The SDK finds the native session ID within the selected Claude home, copies it at the requested assistant cursor, and the fork's first turn still runs at the current project root. Provider-home handling and the MCP contract are unchanged.

Scope and approval

Fixes #22796 GitCafe: https://git.cafe/pingdotgg/t3code/issues/22796 Triaged bug via the automated issue flow.

Runtime transcript with exact commands, SHAs, timestamps and outcomes · Sanitized runtime events · Exact MCP calls · Scoped check summary · Proof matrix.

Verification

References #22796.

Validation

• Reproduced UI and t3_thread_fork failures on 1688f96568; both forks complete at B on c0fdbfd6b9. Parent resume and unchanged-root fork controls passed; Codex comparison passed.
• One existing test rewritten to use the real SDK with an isolated Claude home and a transcript under an old workspace directory. Fails before implementation; passes after. 209 scoped tests pass across the adapter, ThreadFork integration, and ThreadMergeBack integration files at the final head. Both affected integration files reproduce four failures on the previous head and pass all six cases on origin/main. Server typecheck passes; scoped lint has only a preexisting unused-variable warning.
• Independent round-two Codex GPT-6.1-Sol and Claude Opus 5.5 reviewers: VERDICT: MERGE, no confirmed findings. Claude independently reran all 209 scoped tests; Codex independently verified SDK lookup, earlier-cursor truncation, full-copy behavior, and distinct fork identities.
• CI aggregate Check is successful on f3ecffb6d9. The workflow requires the entire server matrix to succeed before that aggregate can pass. Both previously failing shards, Test Server 2 and Test Server 5, are successful. GitCafe reports 26 successful and zero failing checks but retains Test Server 3 as queued despite the successful aggregate; its allowed failed-log read returned no failed log. cafe ci status and cafe ci list expose no run for this head. This metadata discrepancy is disclosed rather than represented as a 27/27 GitCafe summary.

Evidence (superseded by ## Evidence below, recaptured at 6c15210198)

The committed adapter test contains the rebuildable fixture. Server-only change: no render paths or fork dialog changed, so pixel comparisons do not apply. Supplementary real-app captures show the first-turn outcome (Chromium 154/Linux, no emulation, 1280×800 CSS pixels, DPR 2, light appearance):

What else changed: one existing test now copies a real synthetic transcript. Since the first review, the recorder and eight outbound fork frames across six replay fixtures omit the stale directory restriction. The strict replay matcher, transcript content, cursors, session IDs, and subsequent resume expectations are unchanged. These stale frames caused all four original CI failures: the replay mismatch left fork runs in starting. Production code is unchanged since the first reviewed head; the real-SDK moved-root regression still fails with the main adapter and passes with the fix. Proof audit pass 2 was not rerun because this round changed only test infrastructure and fixtures; both earlier proof audits remain applicable. The screenshots differ in titles, sidebar thread count, timestamps, fixture prompt, and failure/success content because they record separate attempts; no layout change is claimed. No dependency patch or production parser/regex/loop added.

Unverified: mobile fork, Windows/macOS runtime, remote/relay connections, providers beyond the Codex comparison, live no-cursor fallback, and the preexisting separate subagent-launch cwd pinning. Earlier-cursor truncation is SDK-owned; the regression test proves cursor forwarding and inheritance, not the SDK's truncation algorithm.

Both proof audits: SUFFICIENT. Audit results.

Model: GPT-6.1-Sol. Harness: Codex in T3 Code.

Evidence

Recaptured on the current branch; this supersedes the runtime links and the screenshots above, which were captured at f3ecffb6d9 and earlier. Before = merge-base 8d3b061121. After = 6c15210198, which merges main into this branch. The later commits fbe839d80b and 5434747675 only add the driver script and its knip entry, so the server code is unchanged since the capture.

Driver: apps/server/scripts/evidence/pr-22836-fork-moved-root.ts. The same file ran at both SHAs. It starts a real apps/server/src/bin.ts start with isolated --base-dir/T3CODE_HOME and an isolated CLAUDE_CONFIG_DIR, which exercises the in-process fork path. It then drives the server through HTTP project.create / project.update{workspaceRoot} and the WS RPCs orchestration.launchThread, orchestration.dispatchCommand (thread.fork, message.dispatch, thread.merge_back) and orchestration.getThreadProjection.

Fixture matrix · Captures · before summary · after summary · before server.log · after server.log · before moved fork projection · after moved fork projection

Environment: Linux 6.1.102 x86_64, Node v26.12.1, Claude Code CLI 2.1.303, @anthropic-ai/claude-agent-sdk 0.3.276, claude-sonnet-4-6 through the maintainer's API proxy. T3 and Claude state lived only under /tmp.

What else changed between the before and after runs

• Control rows match field for field. Only ids and timestamps differ.
• After the fix, Claude creates an empty projects/…-moved-b/ dir, because the fork's turn runs at cwd B.
• At both SHAs, after project.update the source thread's later turns still record cwd A. Only new forks pick up B. This is not a regression and is outside this PR.
• Before already contains the 25 commits merged from main, so the only server delta between the runs is this PR's diff.
• A second, exploratory run pair gave the same outcome for every row.

Fixes pingdotgg/t3code#22796