[Bug]: Pending async questions lose their thread-list indicator while the agent keeps working#24914

Before submitting

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

Area

apps/web (also apps/mobile and packages/client-runtime)

Steps to reproduce

1. In a Codex thread, give the agent a task where it asks you an async question (request_user_input_async) and then keeps working in the foreground for a while, for example running a longer test suite.
2. Don't answer the question.
3. While the agent is still working, look at the thread in the sidebar, the status pill, or the mobile thread list.
4. Compare with the thread itself: t3_thread_read reports an active run with pendingRequestCount > 0, and t3_pending_request_list returns the open question.

Note: these steps come from an observed case and from reading the source. I did not run a separate fresh reproduction.

Expected behavior

A running thread stays in Working, as fixed in #15258 / #15430. The thread list should still show that the thread has a pending question, which is the purpose of the pending-answer badge added for #877.

Actual behavior

While the provider turn is active, the row shows only Working. No question-specific indicator appears in the sidebar, the status pill, or the mobile list. The pending-question indicator (Input) appears only after the provider turn ends.

Observed case (historical snapshot, IDs omitted): a Codex thread had two pending async questions while the agent kept running commands and tests for several minutes. During that time the thread was listed only under Working. Both questions were later answered by message.

Before #15430, pending async questions showed Input in the list, though with the wrong run status. Since #15430, the list shows no sign of them while the agent works.

Code path on main at 5b354026:

• ProjectionStore derives blocking: request.responseCapability.type !== "message" for the pending request summary (apps/server/src/orchestration-v2/ProjectionStore.ts).
• presentThreadShell (packages/client-runtime/src/state/models.ts) clears hasPendingUserInput for nonblocking requests while the runtime status is preparing, starting or running. The raw request is still available under source.pendingRuntimeRequest, but the status renderers don't read it.
• resolveSidebarThreadStatus and resolveThreadStatusPill (apps/web/src/components/Sidebar.logic.ts) and resolveThreadListV2Status (apps/mobile/src/features/threads/threadListV2.ts) rely on hasPendingUserInput for the thread's own pending questions, so they show Working only.
• The regression test from #15430 (packages/client-runtime/src/state/entities.test.ts) explicitly expects hasPendingUserInput: false while the agent is working.
• Web attention notifications use the same resolved status and skip Working threads, so nothing else in the UI points to the question either. The only indirect effect is that Snooze is disabled while a request is pending.

Impact

Minor bug or occasional failure

Version or commit

Observed on 0.1.3-nightly.20261025.3669. Source inspected at main @ 5b354026 (2026-10-25).

Environment

Linux host, web client, Codex provider

Logs or stack traces

Historical thread snapshot from the T3 MCP tools while the agent was still working (IDs omitted):

Related

No exact duplicate found. Related:

• #877: pending-answer badge for active questions (the indicator that is now suppressed during work)
• #15258 / #15430: async questions no longer show as Awaiting Input on running threads (this regression came with that fix)
• Discussion #20096: request for separate "work running" and "reply needed" states
• #22097: a turn that ends with a plain-text question stays in Working
• #24096: parent thread shows Awaiting Input for questions from delegated tasks

Model: Claude Opus 5.5. Harness: Claude Code. Orchestrator: T3 Code.