fix(orchestrator): Keep active web timeline visible while work is queued

[mwolson]

Summary

• Keep a running turn's web timeline and in-thread elapsed time attached to the
  run that still owns provider work when a newer follow-up is queued.
• Keep the in-thread Working row and sidebar Working status visible for that
  provider-owning run.
• Reuse deriveThreadActivityRun, which is already part of the
  t3code/codex-turn-mapping base, while preserving the latest run for queue
  semantics.

Problem and Fix

Problem and Why it Happened	Fix
ChatView used the highest-ordinal run for both queue presentation and live activity. Once a newer queued run appeared, MessagesTimeline treated the older running turn as settled and folded its commentary and tools behind a premature "Worked for" row. Elapsed-time presentation also lost the running turn's start time.	Derive latest, activity, and runtime state together. Keep the latest run for queue semantics, but pass the shared deriveThreadActivityRun result to settlement, elapsed-time, and timeline presentation.
The in-thread Working row and sidebar status pill also followed the newer queued run's status, so live work could lose its elapsed row and appear as Connecting.	Treat a non-null active run ID as provider-owned work. Keep queued-only threads Connecting, while running-plus-queued threads remain Working.

Validation

• Focused web and client-runtime tests: 4 files, 160 tests passed.
• Web TypeScript check passed.
• Targeted formatting and lint checks passed.
• Matching isolated real-Codex before and after replays:
  • The base folded the turn as "Worked for 3.3s" while provider work was still
    running and hid its command rows.
  • The final branch kept the command rows visible with "Working for 38s" while
    the newer run remained queued.
  • Both replays let the queued follow-up start only after run 1 completed, and
    both runs settled successfully.
• Compatibility replay with
  #4762 web-timeline-inflight-tool-rows:
  • The combined focused suite passed 119 tests.
  • Active commentary, completed output, and a running tool row remained visible
    together above the queued follow-up.
  • No premature "Worked for" fold appeared.
• Reusable manual coverage:
  Codex background, scenario 9.

UI Changes

The visible change is limited to the active-plus-queued state. The running turn
remains expanded with its in-thread Working row and sidebar Working status until
it settles. After settlement, its normal "Worked for" fold can appear.

Validated before and after active-plus-queued screenshots are attached in a PR
comment.

Known Limitation

The sidebar's Working duration uses compact thread-shell data, which has run IDs
but no activity-run timestamps. Its timer can still restart when the queued run
becomes latest or runtime.updatedAt changes. The Working status itself remains
visible.

Checklist

• This PR is small and focused.
• I explained what changed and why.
• I included before and after screenshots for the UI change.
• A video is not applicable because this changes run selection, not
  animation or transition behavior.

---

Note

Medium Risk
UI-only run-selection logic in a core chat path; behavior change is scoped to multi-run queued states with tests, but timeline/settlement bugs are user-visible if wrong.

Overview
Fixes active + queued threads where a newer follow-up was treated as the live turn: the running turn folded early (“Worked for…”), tool rows hid, and UI showed Connecting instead of Working.

ChatView now derives latest, activity, and runtime together via deriveChatViewThreadExecution (reusing deriveThreadActivityRun). Latest run still drives queue semantics; activity run drives settlement, elapsed time, MessagesTimeline’s latestRun, and the in-thread working row. isChatViewThreadWorking treats any non-null activeRunId as in-progress work, not only phase === "running".

Sidebar status pills count queued as Working when activeRunId is set; queued-only threads stay Connecting.

^{Reviewed by Cursor Bugbot for commit a211c7d. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Keep active web timeline visible while a run is queued behind a running run

• Introduces deriveChatViewThreadExecution and isChatViewThreadWorking in ChatView.logic.ts to separate the "activity run" (the currently executing provider work) from the "latest run" (which may be a newer queued run).
• ChatViewContent now uses the activity run for settled checks, timers, and MessagesTimeline.latestRun, so the timeline stays anchored to the running run instead of jumping to the queued one.
• resolveThreadStatusPill in Sidebar.logic.ts now returns 'Working' when runtime.status is 'queued' and activeRunId is non-null (previously showed 'Connecting').
• Behavioral Change: isWorking becomes true for a queued runtime that has an activeRunId, which affects loading indicators and input disabling in the chat view.

^{Macroscope summarized a211c7d.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 1fa06fcb-3edf-428d-87ef-95b82f147d10

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[mwolson]

Before and after

Before: the base folds the still-running turn and hides its active command rows.

After: the active command rows and Working timer remain visible while the follow-up is queued.

[macroscopeapp]

Approvability

Verdict: Approved

Straightforward UI bug fix that keeps the active work timeline visible when a newer run is queued. Changes are self-contained to UI state logic with good test coverage and no runtime behavior changes beyond the intended fix.

^{You can customize Macroscope's approvability policy. Learn more.}