Auto-approve mode: follow-up work from the #39015 review #39412

Follow-up work from the auto-approve mode review in #39015. None of these block that PR — the mode is behind the experimental.auto_approve beta flag, every item below fails safe (an extra prompt, never an unintended approval), and each is listed under "Known limitations" in the PR description.

Roughly in priority order.

1. Let reasoning-capable models act as classifiers

The highest-impact item. The mode defaults to the active provider's small model, and the common defaults (gemini-3-flash, claude-haiku) expose no non-reasoning variant. The classifier rejects reasoning output by design, so those models can never return a usable verdict, and a user who enables the flag without setting auto_approve.model gets a mode that reviews nothing.

Today this is legible rather than fixed: show_details reports why no verdict was reached, and the docs tell users to pick a non-reasoning model. A real fix means disabling reasoning for the classifier request specifically. That cannot be done by merging options — mergeDeep cannot remove thinking.budgetTokens, and a half-merged {thinking:{type:"disabled",budgetTokens:16000}} is an API error — so it needs a "strip reasoning" path through LLMRequestPrep.prepare touching each provider branch. Anthropic additionally requires max_tokens above the thinking budget.

2. skill permissions are judged by filename

auto-approve.ts approves a skill request on patterns: ["<name>"] with no view of what the skill file injects. Either exclude skill from the classifiable set or include the resolved location plus a bounded excerpt in the evidence.

3. Overlay targets the client's default instance

The TUI sends the review overlay through the SDK client's default directory. A session belonging to a different workspace would have its overlay applied to the wrong instance. permission.tsx sits above SyncProvider, so it has no session→workspace map without moving the logic or plumbing one in.

4. Two ask sites carry no tool identity

evidence() requires request.tool, so these can never be classified:

• doom_loop (session/processor.ts) — arguably correct to leave, since there is no tool call to anchor to and "you seem stuck, continue?" is a human judgment.
• The subagent-internal tool context (session/prompt.ts) — currently masked by the blanket subagent refusal, so only relevant if subagent classification is ever revisited.

5. Plugins can rewrite the classifier prompt

chat.system.transform and chat.params hooks run on classifier requests, so a plugin can alter the policy text or the token cap. Plugins are already arbitrary in-process code, so this is not an escalation, but bypassing hooks for the classifier would keep the security-relevant prompt fixed.

6. Root-cause the HTTP API exerciser teardown hang

4e5f984b4 bounds disposeApps() at final teardown so bun run test:httpapi can no longer hang forever after printing a clean summary — two runs were found stuck for over two hours past a passing result, which would have hung CI rather than failing fast. That is a guard, not a diagnosis: some web handler's dispose() never settles and the underlying unclosed handle is still unidentified. The bound only applies to final teardown; the per-scenario reset deliberately still waits unbounded, because abandoning a live handler there leaks state into the next scenario.

7. Cosmetic

Locale.titlecase renders the classifier agent as "Auto-Approve" where modeLabel uses "Auto-approve"; custom agents sort after build/review in the Tab ring.