fix(clients): async questions keep a running thread Working

[Gigioxx]

Optional async questions made running threads appear to await input even while the provider continued working. Both shell builders now carry a backward-compatible blocking flag. Shared client status and agent awareness keep nonblocking questions Working during live work, then show Input when it ends. Blocking questions, secret requests, and older-server payloads retain Input behavior.

A waiting secret also takes priority over a pending nonblocking question, so an unanswered optional question cannot hide a later secret card. Real blocking runtime requests retain their existing precedence. No provider adapter, request response capability, or general request ordering changed.

Continues @Gigioxx's work in #15430, preserving the author's commits and merging current main. Main's subagent-status field is preserved.

Verification:

• Retained 83 cases across the three existing focused suites (83 before → 83 after), plus 38 existing contract tests and 29 existing snooze tests: 150 pass across five files, including 29 existing snooze cases. Removed duplicate test setup; extended the existing secret lifecycle test for secret-only and coexisting async input in both SQL and memory builders, without new cases or a second status matrix. All main cases remain.
• Main fails the three async-status regressions. Review candidates failed the secret-blocking and overlap assertions; final code passes them. Scoped lint/format and server/contracts/shared/client-runtime/web/mobile package typechecks pass on the applicable final bytes. The existing async case also proves pending input prevents snoozing and wakes an already snoozed thread; no new cases were added for those assertions.
• Five fresh parallel full-PR review rounds with Claude Opus 5.5 and GPT-6-Sol. Confirmed secret classification, overlapping secret, Snooze availability and snooze/wake mismatches were fixed. Both reviewers are clean at final head 85dfbea5.
• Live headless Linux web with actual Codex on final candidate: optional question plus foreground command stays Working; after completion its unanswered question shows Input. A blocking request_secret card shows Input alone and after an unanswered async question in the same run. Both secret cards were declined without entering any value. A running thread snoozed through the real dispatch service wakes when its async question arrives, stays Working, and cannot be snoozed again while the request is pending. Persisted state confirms all verification runs completed. Live state while running.

Before — main labels an async working thread Input:

After — final candidate stays Working with the same pending question:

Before recording · After recording

Snooze → async question wakes the still-working thread.

After completion — the unanswered question shows Input:

A secret card still shows Input, including when an async question is also pending:

Web/desktop and mobile use the shared client presentation; relay awareness consumes the same summary. Live verification covered local Linux web and Codex only. Not exercised: macOS, Windows, iOS, Android, Electron desktop, remote/relay/tunnel or other providers. Main's separate parent-attention behavior for delegated child questions is unchanged. Human maintainer review remains required.

Implemented through T3 Code's Codex harness with GPT-6.1-Sol; tests by GPT-6-Astra; independent reviews by GPT-6-Sol and Claude Opus 5.5 through T3 Code.

[macroscopeapp]

Approvability

Verdict: Approved at 85dfbea

Macroscope's review found this PR approvable — This is a focused, backwards-compatible fix for how async questions are represented while a run is still working, including matching awareness and snooze behavior. It introduces no new capability, schema migration, deployment change, sensitive-code change, or static-analysis override, and the production logic is covered by targeted tests.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

Warning

Review limit reached

Only developers with an assigned seat can use this organization's usage-based review budget, and seats here are assigned manually. Ask an admin to assign a seat, or change the review continuation mode in Billing.

Next included review available in 2 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used all 10 included reviews currently available.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

• Configuration used: Path: .coderabbit.config.ts
• Review profile: CHILL
• Plan: Advanced
• Run ID: dbf13116-e1c1-427d-a06a-551dfbf6110a

📥 Commits

Reviewing files that changed from the base of the PR and between edd5263 and e40bc3d.

📒 Files selected for processing: 8

• apps/server/src/orchestration-v2/ProjectionStore.test.ts
• apps/server/src/orchestration-v2/ProjectionStore.ts
• packages/client-runtime/src/state/entities.test.ts
• packages/client-runtime/src/state/models.ts
• packages/client-runtime/src/state/threadSettled.ts
• packages/contracts/src/orchestrationV2.ts
• packages/shared/src/agentAwareness.test.ts
• packages/shared/src/agentAwareness.ts

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository: pingdotgg/t3code/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: 21a2d714-05cb-4872-ac7b-e4fb0aed5b19

📥 Commits

Reviewing files that changed from the base of the PR and between 1a9de45 and edd5263.

📒 Files selected for processing (1)

• apps/server/src/orchestration-v2/ProjectionStore.test.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 3 remain after this review.

📝 Walkthrough

The change adds an optional blocking field to pending runtime request summaries. Thread presentation and awareness phase resolution use that field and runtime status to distinguish blocking user input from nonblocking questions.

Changes: Async question status

Layer / File(s)	Summary
Add blocking metadata to pending requests packages/contracts/src/orchestrationV2.ts, apps/server/src/orchestration-v2/ProjectionStore.ts, apps/server/src/orchestration-v2/ProjectionStore.test.ts	The pending request summary gains an optional blocking field. Both shell-building paths set it to false for the message response capability and true otherwise. Projection tests check both values in SQL-backed and in-memory shells.
Present pending input by runtime state packages/client-runtime/src/state/models.ts, packages/client-runtime/src/state/entities.test.ts	presentThreadShell reports pending input for blocking requests, including requests without the field, or when the runtime is inactive. Tests cover blocking, nonblocking, and omitted values.
Resolve awareness phase for nonblocking input packages/shared/src/agentAwareness.ts, packages/shared/src/agentAwareness.test.ts	The resolver keeps an active run in its status phase for explicitly nonblocking user-input requests. The test covers a running thread.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix · Severity of issue fixed: Low

Suggested reviewers: juliusmarminge

Merge Risk: ⚪ Minimal · up to edd52

No merge-blocking issue is identified; the change is ready for normal checks.

### Architecture Summary

Architecture risk: 🔵 Low · up to edd52

The change affects 4 systems.

Changed systems: apps/server, packages/client-runtime, packages/shared, packages/contracts

Architecture concerns
No architecture-level concerns identified.

Review details

Systems and components

• observed — apps/server (service) was modified; 2 changed files map to changed impact.
• observed — packages/client-runtime (library) was modified; 2 changed files map to changed impact.
• observed — packages/shared (library) was modified; 2 changed files map to changed impact.
• observed — packages/contracts (library) was modified; 1 changed file maps to changed impact.

Before / after behavior

• observed — Modified behavior in apps/server/src/orchestration-v2/ProjectionStore.ts: threadShellFromProjection now derives the pending request’s blocking value from whether its response capability type differs from "message".
• observed — Modified behavior in apps/server/src/orchestration-v2/ProjectionStore.ts: shellFromState applies the same response-capability rule when constructing a shell from stored state.
• observed — Modified behavior in packages/client-runtime/src/state/entities.test.ts: Added coverage for pending user-input requests: a running shell reports pending input for blocking: true or an omitted blocking value, but not for blocking: false; a completed shell with no active run reports pending input even when the request is nonblocking.
• observed — Modified behavior in packages/client-runtime/src/state/models.ts: presentThreadShell now stores the result of shellRuntime and considers only preparing, starting, and running active for pending-input presentation.

Pre-merge checks: 4 · 1

Failed checks: 1 warning

Check name	Status	Explanation	Resolution
Docstring Coverage		Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 4 functions across 7 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

Passed checks: 4 passed

Check name	Status	Explanation
Linked Issues check		[#15258] requires async user_input questions to leave a running thread in Working state, while blocking or completed-run questions remain Input. presentThreadShell suppresses hasPendingUserInput…
Out of Scope Changes check		The contract field, server projection changes, client-runtime presentation rule, awareness rule, and related tests directly implement or verify [#15258]. No unrelated change appears in the reviewed pu…
Title check		The title clearly and concisely describes the primary change: async questions no longer make a running thread appear to await input.
Description check		The description provides a clear problem statement, implementation summary, scope details, extensive verification results, limitations, and links to related work and evidence. It does not use the temp…

Full details: Linked Issues check

Explanation

[#15258] requires async user_input questions to leave a running thread in Working state, while blocking or completed-run questions remain Input. presentThreadShell suppresses hasPendingUserInput only for blocking: false during preparing, starting, or running; omitted blocking remains blocking. ProjectionStore supplies the flag for both shell projection paths, and the contract keeps it optional for older servers. The shared awareness phase applies the same rule. Existing sidebar, mobile, notification, and snooze consumers use hasPendingUserInput. Tests cover async, blocking, omitted-field, completed-run, shell projection, and awareness cases.

Full details: Out of Scope Changes check

Explanation

The contract field, server projection changes, client-runtime presentation rule, awareness rule, and related tests directly implement or verify [#15258]. No unrelated change appears in the reviewed pull request summary.

Full details: Description check

Explanation

The description provides a clear problem statement, implementation summary, scope details, extensive verification results, limitations, and links to related work and evidence. It does not use the template headings and does not explicitly document maintainer approval, but it is otherwise sufficiently complete and directly related to the change.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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

Dismissing prior approval to re-evaluate 1a9de45

Dismissing prior approval to re-evaluate edd5263

[juliusmarminge]

Taking over this one. I will rebuild the async-question status fix on current main, retain focused projection and client behavior coverage, and verify the web behavior before pushing here.

Dismissing prior approval to re-evaluate 85dfbea