[Bug]: Forking a running Claude thread replaces native history with a context handoff
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 42/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- typescript
- Lĩnh vực
- ai-infra-agents, backend
Hướng nghiên cứu
Start with apps/server/src/orchestration-v2/CommandPolicy.ts and ProviderTurnStartService.ts, then read ClaudeAdapterV2.forkThread and the Agent SDK's forkSession behavior. Reproduce a fork at a finished turn while the parent is running, checking transcript handling for a half-written line and whether upToMessageId excludes the active turn. Done means a running Claude source can be forked with native history while the parent continues, with the open questions resolved.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
- Use the Claude provider and let a turn finish.
- Send another message in that thread and leave it running.
- Fork from the finished turn, or open a side chat.
- Send the fork's first message before the parent finishes.
Expected behavior
The fork resumes a native copy of the Claude session up to the finished turn, with its real tool calls, outputs and prompt cache, while the parent keeps running.
Actual behavior
The fork starts a new Claude session whose first input is a T3-written "Fork context" summary (full_thread_summary). In my case the handoff kept 5 items and dropped 6, and native tool and reasoning state was not carried over. Idle forks of the same thread fork natively.
The cause is the busy-source rule added in #26901: decideForkExecution requires !input.sourceBusy, and startup checks again. #26901 gives the reason that Claude cannot fork a running session.
Why Claude may not need the fallback
The Agent SDK's forkSession doesn't use the live session. It reads the session's .jsonl transcript, cuts it at upToMessageId, rewrites UUIDs, and writes a new transcript. It has no check that the source is idle. A finished turn's messages are already in the transcript, so forking at that point should not need the source to stop.
The adapter's own guards in ClaudeAdapterV2.forkThread (the active-turn refusal and closeLiveQueryForNativeThread) look at the calling session's state. For a new fork, that is the target session, not the running parent. So I couldn't confirm from the code why a busy Claude fork failed before #26901.
#29239 (open, waiting for maintainer confirmation) adds an optional provider capability for native forks while the source runs, and enables it for Codex only. If that lands, Claude could set the same capability, possibly after an adapter change.
Open questions before enabling it for Claude
- What failed when a Claude fork of a running thread was tried before #26901? A repro or log would show whether the limit is in the SDK, the CLI, or the adapter.
- Does
forkSessionhandle a source transcript that the running session is still appending to, including a half-written last line? - Is the fork's
upToMessageIdalways a message in the finished turn, so nothing from the running turn gets in?
Impact
Minor bug or occasional failure
Version or commit
Seen on a personal fork built on nightly 0.1.8-nightly.20261109. The rule is unchanged on upstream 3a30b011c3.
Workaround
Wait for the parent to go idle before sending the fork's or side chat's first message.
Filed by Claude Opus 5.5 through Claude Code in T3 Code.
- Ngôn ngữ chính
- TypeScript
- Star
- 24.8k
- Fork
- 6.4k
- Merge trung bình
- 4 giờ 16 phút
- Pull request đã merge (30 ngày)
- 352
Chuẩn bị môi trường
Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của pingdotgg/t3code
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của pingdotgg/t3code
Issue tương tự
-
idea-scout idea:453
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 83/100
jeanibarz/agent-notebook#453 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
level/task
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 95/100
wazuh/wazuh-dashboard-plugins#9642 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 91/100
unicef/adt-studio#1112 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
feature request good first issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
TabularisDB/tabularis#1513 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 75/100