fix(clients): a running session shows Working only while a turn is active - #267
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Web and mobile both derive "Working" from
session.status === "running"alone. A provider can report running between turns with nothing in flight (Claude'ssystem/status, fixed server-side in #265), and when that happened the sidebar, the mobile thread list, and the mobile status pill all showed a pulsing "Working" for an idle thread. The same assumption leaked into two adjacent decisions: the "latest turn settled" helpers that gate Plan Ready treated any running session as unsettled, and the mobile composer switched its send button to "Queue follow-up" on running alone, while its sibling clear and remove conditions already required an active turn.This is the client half of the incident from 2026-09-04: the thread that dropped the user's message sat in exactly this state for seven hours, labelled Working.
Fix
A running session is "working" only when it has an active turn. Applied to every derivation that used status alone:
resolveSidebarThreadStatus,resolveThreadStatusPill,isLatestTurnSettledresolveThreadListV2Status,resolveThreadStatus, both settled helpers, and the composer's queue-follow-up conditionWith no active turn the status falls through to the honest signals that already exist: background liveness (Delegating, Monitoring), Plan Ready, Completed, or nothing.
Surfaces walked: web sidebar and flat sidebar pill, mobile thread list and status pill, mobile composer.
LegacySidebarandChatViewalready required an active turn and are unchanged. Desktop wraps web.Verification
Sidebar.logic.test.ts,session-logic.test.ts,threadListV2.test.ts, andthreadPresentation.test.ts. One pre-existing mobile test asserted Working for a running session that named no turn; it now names one.vp run -F @t3tools/web typecheckandvp run -F @t3tools/mobile typecheck: clean.vp fmt --checkandvp linton all touched files: clean.Companion PRs: #264, #265, #266 fix the server side of the same incident.
Model: Claude Fable 5.1. Harness: Pylon (Claude Code provider).
Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.