Sign up
View stargazersSign up

[Bug]: Merging a fork back gives no sign it worked until the next message is sent#15063

openedOct 3, 2026byLLunarRed

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

  1. Open a thread with at least one finished turn (I used Codex, GPT-6.1-Sol).
  2. Fork it, and send a turn in the fork.
  3. In the fork, open the Lineage section of the thread details.
  4. Click "Merge this conversation back into ".

Expected behavior

The source thread shows that the fork's context was merged and will be included in the next turn, so it's clear the merge worked.

Actual behavior

The app switches to the source thread, which looks exactly as it did before the merge. Nothing shows that the merge happened. The "Context handoff GPT-6.1-Sol → GPT-6.1-Sol" divider only appears after I send a new prompt, so until then there's no way to tell whether the merge worked. After that prompt, the agent in the source thread did know what I had done in the fork, so the merge itself works. Only the confirmation is missing.

From reading main @ 8283b481a3: thread.merge_back saves a context transfer with status: "pending" (apps/server/src/orchestration-v2/Orchestrator.ts), but the timeline only draws "Context handoff" for handoff items, which are created when the next run uses up the transfer (packages/client-runtime/src/state/itemSupport.ts). Pending transfers don't appear anywhere in the timeline. Since that code is in client-runtime, mobile probably behaves the same way, but I've only tried desktop.

Impact

Minor bug or occasional failure

Version or commit

v0.0.46-nightly.20261003.2610

Environment

macOS 27.0, T3 Code desktop app, Codex (GPT-6.1-Sol)

Logs or stack traces

No response

Screenshots, recordings, or supporting files

No response

Workaround

Send another prompt in the source thread. The handoff divider appears then, which confirms the fork's context was included.

LLunarRedOct 3, 2026
Synced from GitHub

One related gap in the same flow: after merging back, nothing tells you when the fork is safe to put away.

The fork's history is read only when the next message is sent in the source thread (Orchestrator.ts, where mergeBackSourceProjection is loaded). If the fork's records can't be found at that point, sending fails with "Pending merge-back transfer … has no resolvable source run." So the fork needs to stay around until the handoff has been used, but the UI doesn't say that, and there's no guidance anywhere on whether to archive, settle, or delete a fork once you're done with it.

If this gets fixed with a visible "pending merge" marker on the source thread, that marker could also say when the fork can be archived (for example, once the handoff divider appears).

JJulius Marminge18d ago

Reproduced on Linux in the web dev app at b5a226e49c, using isolated copied state and Codex GPT-6-Astra. Completed a source turn, forked from the response, completed a fork turn, then used Lineage → Merge back. The source timeline showed no merge/pending-handoff indication. Sending the next prompt made the Context handoff divider appear, and the source correctly recalled a marker introduced only in the fork.

Before sending the next prompt: After merge, no pending confirmation

After sending the next prompt: Handoff divider and recalled fork marker

The desktop shell and native mobile clients were not checked.