[Bug]: Lineage keeps a delegated child's launch model after it changes #23837

Activity

1. EtanHey commented on Oct 22, 2026

   

   EtanHey

   on Oct 22, 2026

   Last edited by EtanHey

   Contributor

   More actions

   Additional real-install confirmation of #23837, including a Claude-to-Codex provider handoff.

   Environment: T3 Code Nightly desktop app on macOS arm64 (Darwin 27.0.0), connected to its local server. Affected server version: 0.1.2-nightly.20261022.3541, confirmed by /.well-known/t3/environment. The separate triage CLI version is 0.1.2.

   Observed behavior: An app-owned delegated child began on Claude Opus 5.5, then switched to Codex GPT-6.1-Sol with Extra High effort. The user reports that the child view shows the current model while the parent's Lineage still identifies it as Claude.

   Read-only database evidence from that same child:

   Original subagent: origin=app_owned
     driver/providerInstanceId=claudeAgent
     model=claude-opus-5-5
   Current child selection:
     instanceId=codex
     model=gpt-6.1-sol
     reasoningEffort=xhigh
   Context handoff:
     strategy=full_thread_summary
     status=ready
     delivery.status=injected
     ready at 2026-10-22T20:44:54.110Z
   Later Codex runs and provider turns: completed
   

   Source confirmation: At the affected release commit 044f07257c9684ae4543bd1e1ebf9c394e9e3830, ThreadRelationshipsControl.tsx selects the provider from agent.providerInstanceId before the child thread's provider (lines 479–484), and passes agent.model / agent.modelSelection to the hover card (lines 499–507). The row icon uses that same provider driver. This matches the issue's diagnosis and the code addressed by #23838.

   The handoff and completed Codex turns are persisted runtime evidence; I did not trigger a new handoff or run the proposed fix. No database or application changes were made. A user-supplied screen recording is available but is not attached to this comment.

   Investigated via t3 triage by Codex (GPT-6.1-Sol).
2. juliusmarminge commented on Oct 24, 2026

   

   juliusmarminge

   on Oct 24, 2026 – with GitCafe Production

   Member

   More actions

   Reproduced in the isolated web app on 7f7daad985: a synthetic app-owned child has Sol / Extra High selected, while the parent’s Previous agents Lineage hover shows Astra / high. Runtime steps and evidence. Existing #23838 addresses this; two independent static reviews found no blockers and all 29 head checks pass. The PR remains open and unmerged.
3. juliusmarminge commented on Nov 12, 2026

   

   juliusmarminge

   on Nov 12, 2026

   Member

   More actions

   I tried to reproduce this on the current build and could not.

   Commit 3c68642 (origin/main). Ran the web app from an isolated worktree with T3CODE_DEV_SEED=0 vp run dev on a fresh database, with a scratch git project. (1) Started a Codex parent thread that called delegate_task for an app-owned child on gpt-6-astra with high effort; the child ran and completed, and its composer read 'GPT-6-Astra, High'. (2) Opened the child in the web UI, switched the composer to GPT-6.1-Sol / Extra High (the timeline showed '6 Astra High → 6.1 Sol Extra High') and sent a follow-up, which completed. (3) Opened the parent, opened Thread details > Lineage > Previous agents and hovered the child: the card read '6.1 Sol · xhigh', the current selection. The parent's subagent table now held a second app-owned record for the same child thread with modelSelection gpt-6.1-sol/xhigh (written by the follow-up path in Orchestrator.ts that copies run.modelSelection, added in #17696). (4) Provider change: switched the same child to Claude Haiku 5.5 and sent another follow-up (with a context handoff); a third record was written with providerInstanceId claudeAgent, and the parent's hover card read 'Haiku 5.5'. (5) Delegated a second child (Astra/High) running sleep 300, stopped it from the UI (status interrupted), switched it to Sol / Extra High and sent a follow-up; the parent's hover card read '6.1 Sol · xhigh'. The stale label appears only when the parent holds the original subagent record without a follow-up record, which is the state the reporter's and the maintainer's synthetic fixtures built. A real follow-up writes that record, including on the reporter's commit, which already contains #17696.

   Closing as not planned. If it still happens for you, reply with the exact steps and the version you are on and it will be looked at again.
4. juliusmarminge

   closed this as not plannedon Nov 12, 2026