Sign up
View stargazers13Sign up

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

opened1d agobyAAksharP5

Before submitting

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

Area

apps/web, also used by desktop.

Steps to reproduce

  1. Launch an app-owned child with delegate_task, using gpt-6-astra with High effort.
  2. Open the child thread, switch to gpt-6.1-sol with Extra High effort, and run a follow-up.
  3. Return to the parent, open thread details, and hover the child in Lineage.

Expected behavior

Lineage shows the child's current model, provider account, and options. Historical task cards can retain the settings used for their original task.

Actual behavior

The child view shows Sol / Extra High, while the parent's Lineage hover card still shows Astra / High. The hover card reads the original subagent record rather than the child thread's current selection.

Impact

Minor bug or occasional failure. The stale label makes users doubt whether a requested model switch took effect.

Version or commit

Reproduced on upstream main 22840ab943b8418744b48223411e46ba4fdcef1a. The same code remains on ef92441313da327139df75daa8f723c0f42348f6.

Environment and verification

Linux, Chromium, isolated local web client. A synthetic persisted parent/child fixture reproduces the mismatch without private conversation data or live provider execution. A focused browser regression fails for Astra-to-Sol and Codex-to-Claude changes on main; both native-metadata controls pass.

Screenshots

Same fixture, dark theme, 1440 × 900 CSS viewport, DPR 1. Matching crops show the parent tooltip after the child has switched to Sol.

BeforeWith the prepared fix
Before: Lineage incorrectly shows Astra and high effortAfter: Lineage shows Sol and xhigh effort

Related work

  • #15334 fixed follow-up status and timers, but leaves the model unchanged.
  • #15250 concerns missing metadata for provider-native Codex children.
  • #17420 adds model traits and original launch snapshots. This report concerns current-session metadata in Lineage.

Investigated with GPT-6.1-Sol through Codex in T3 Code; the prepared fix was reviewed by GPT-6-Astra at High effort.

EEtanHey1d ago
Synced from GitHub

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:

text
1Original subagent: origin=app_owned
2 driver/providerInstanceId=claudeAgent
3 model=claude-opus-5-5
4Current child selection:
5 instanceId=codex
6 model=gpt-6.1-sol
7 reasoningEffort=xhigh
8Context handoff:
9 strategy=full_thread_summary
10 status=ready
11 delivery.status=injected
12 ready at 2026-10-22T20:44:54.110Z
13Later 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).