Thread list has no persistent "needs my action" state, so pending questions vanish and text offers never show

[bompus]

What happened

I run about 30 active threads, including a manager thread with 20+ orchestrator threads under it. I can't tell which ones are waiting on me. The "Awaiting Input" pill shows for about 5% of the threads that actually need me, and it disappears when something else messages the thread. I then have to scroll back through old messages to find the question the agent asked.

What I want: a sticky "needs action" state per thread that survives turns, other threads' messages and card cancellation until I reply or dismiss it, and a sidebar section or sort that lists those threads oldest-first as a queue (pending approvals, questions, and a turn that ended asking me something).

Diagnosis

From source at v0.1.7-nightly.20261102.4080 and the local database (read-only):

• The pill comes from hasPendingUserInput = pendingRuntimeRequest?.kind === "user_input" (packages/client-runtime/src/state/models.ts). It only exists while a real question-card request is pending.
• When a provider turn ends, is interrupted or is cancelled, dismissNativeUserInputs (apps/server/src/orchestration-v2/ProviderEventIngestor.ts) marks that thread's pending native user-input requests cancelled, which clears the indicator.
• In my database, 59 of 75 cancelled or expired user_input requests were live cards, mostly on one orchestrator thread over 4 days. I did not isolate the exact message-arrives-mid-question trigger.
• An agent that asks in plain text (a numbered options list) creates no request at all, so the sidebar can never show it. I told my agents to ask in text because cards kept being cancelled. Since then there were only 35 question cards in about 2 weeks against 3,678 threads, so the pill is almost never on.
• So the indicator is a live property of the current run, not a persistent record that a thread is waiting on the user.

Steps to reproduce

1. Make a thread ask a question card and leave it unanswered.
2. Message that thread from another thread (for example via t3_thread_send) or interrupt it.
3. The pill disappears and the thread looks idle.

Separate case: have an agent end its turn with a plain-text question. The thread never shows any indicator.

I have not run a clean isolated reproduction of step 2.

Version

T3 Code Desktop 0.1.7-nightly.20261102.4080 (Windows client) against a Linux server on the same version. The triage CLI version is the same.

Environment

Linux x64 server (Windows desktop client), Claude and Codex providers, about 3,700 threads in the database.

Evidence

orchestration_v2_projection_runtime_requests, kind user_input: 1085 resolved, 60 cancelled, 15 expired. Of the 75 cancelled or expired, 59 had responseCapability live. Since 2026-10-18: 32 resolved, 3 cancelled.

Related issues

#24914 (open: async questions lose their indicator while the agent works, a narrower case), #15258, #15900, #24593.

Fix applied or workaround

None found. Question cards get cancelled; plain-text questions show no indicator.

Filed by

Drafted by Claude Sonnet 5.5 (Claude Code) in a T3 Code triage session.

[bompus]

Correction to the diagnosis above: the main cause of cancelled cards is a steer. t3_thread_send with mode: "auto" steers the running turn and the Claude SDK aborts the pending question. This is #26841, and I confirmed it with auto vs queue on two threads. The dismissNativeUserInputs path I cited applies when a turn ends or is interrupted, and is secondary. The request here (a persistent "needs my action" state that survives card cancellation, and text offers that never show an indicator) still stands. Related: #26841, #28775.