fix(clients): provider subagent threads never show a composer

[juliusmarminge]

#13624 kept a composer below the provider-subagent bar for the case where a native subagent asks for an approval or an answer in its own thread. With #13726, every provider asks those on the top-level parent thread, so that path can't occur anymore. The maintainer rule is that there is no composer on a provider-native subagent thread; only T3 delegate_task children keep one.

Stacked on #13726.

What changed

• Web. ProviderSubagentBar now always replaces the composer on a provider-native subagent thread.
  • hideThreadSettings on ChatComposer had no other caller and is removed. The same goes for the composerModelPickerCanStayOpen helper it needed and that helper's test.
  • overlayComposerIsResting stays, because swapping in the bar still has to drop the resting reservation.
• Mobile. A message already in the outbox for a provider-native subagent thread could still be edited. ComposerQueuedEditBanner's Cancel then discarded it, because there is no composer to finish the edit in. This was the review finding on fix(clients): native subagent threads show status instead of a composer #13624.
  • ThreadFeed's onEditPendingMessage is now nullable, and ThreadDetailScreen passes null on those threads, so the pencil action isn't rendered.
  • Mobile never had a composer-below-the-bar path. Its pending approval and question cards sit above the bar and now never appear on these threads.
• Docs. docs/user/thread-sidebar.md now says the parent thread asks when such a subagent needs an approval or an answer.

Verification

• vp exec tsc --noEmit -p . in apps/web, apps/mobile, packages/client-runtime and packages/contracts: no errors or warnings. apps/server is also clean on the base PR.
• vp test run src/components/composerFooterLayout.test.ts (web): 41 passed.
• vp lint on the touched files shows 162 warnings before and after, all React-compiler warnings already on the base branch.
• vp run knip:check passes.
• Not run: a real-client pass on web or mobile. There are no mobile tests for ThreadFeed or ThreadDetailScreen, and I didn't add render-to-markup tests.

Model: Claude Opus 5.5 (Claude Code)

🤖 Generated with Claude Code

---

[macroscopeapp]

🟠 High components/ChatView.tsx:4046

Provider-native child threads with persisted pending approvals or user inputs become permanently unresponsive: composerMounted is false, so ChatComposer—the only renderer for those controls—is removed and the subagent remains blocked. This affects in-flight subagents across reconnects or deployment because changing future server routing does not migrate existing pendingApprovals/pendingUserInputs; keep the response controls mounted for existing requests or render them in the provider subagent bar.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/components/ChatView.tsx around line 4046:

Provider-native child threads with persisted pending approvals or user inputs become permanently unresponsive: `composerMounted` is `false`, so `ChatComposer`—the only renderer for those controls—is removed and the subagent remains blocked. This affects in-flight subagents across reconnects or deployment because changing future server routing does not migrate existing `pendingApprovals`/`pendingUserInputs`; keep the response controls mounted for existing requests or render them in the provider subagent bar.

[macroscopeapp]

Approvability

Verdict: Would Approve

Macroscope's review found this PR approvable — This is a narrowly scoped cross-client UI fix that removes composer interactions from provider-owned subagent threads while preserving ordinary and T3-managed subagents. A remaining high-severity finding flags that persisted pending approvals or user inputs may lose their response controls when the composer is unmounted.

Not approved because:

• 1 blocking correctness issue found at or above your repo's Minimum Blocking Severity

No code changes detected at 685bd61. Prior analysis still applies.

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ No successful main baseline artifact is available yet. This run establishes the initial measurement.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	—	4.9 KiB	—	6.8 KiB	✅
Codex	Thread snapshot wire	—	3.7 KiB	—	4.9 KiB	✅
Codex	Live turn WebSocket wire	—	1.2 KiB	—	2.0 KiB	✅
Codex	Live turn WebSocket decoded	—	20.4 KiB	—	29.3 KiB	✅
Codex	Live turn messages	—	2	—	8	✅
Claude	Total thread wire	—	4.9 KiB	—	6.8 KiB	✅
Claude	Thread snapshot wire	—	3.7 KiB	—	4.9 KiB	✅
Claude	Live turn WebSocket wire	—	1.2 KiB	—	2.0 KiB	✅
Claude	Live turn WebSocket decoded	—	20.8 KiB	—	29.3 KiB	✅
Claude	Live turn messages	—	2	—	8	✅

Baseline: unavailable · PR result: 685bd61 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 106.1 KiB
• Claude decoded thread snapshot: 106.4 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.