feat(server): MCP tools for an inbox, approvals, thread diffs, and more thread actions

[maria-rcks]

Stacked on #15219. Its explicit threadId/projectId targets make these tools usable from outside a thread.

Problem

With #15219 an MCP client can target any thread, but it still can't do much once it gets there. Nothing tells it which threads need attention. It can't approve a command, read what a thread changed, or delete a thread, mark one read, or toggle auto-settle. The app's own commands already do all of these.

Change

These are thin wrappers over existing commands and services. Nothing new in orchestration.

• t3_inbox (read-only): active threads that need attention, built from thread shells. Pending requests come first, then failed runs, then unread completed work. Snoozed and settled threads only show for pending requests, using the client's snooze early-wake rule. Scoped to a project. A client outside a thread can see every project.
• t3_thread_organize: new actions mark_read (thread.visit, the reverse of mark_unread), auto_settle_on/auto_settle_off, and delete. Delete requires a full-access caller.
• t3_pending_request_list/read/respond now cover approvals. respond takes a decision, limited to the options the provider offered, or the composer's defaults when it offered none. list keeps requestIds and adds requests with each kind. Approving requires a full-access caller, since it lets the caller run commands in another thread. Declining or cancelling only stops a command, so any caller that can reach the thread may do it. New t3_pending_request_dismiss maps to thread.user-input.dismiss.
• t3_thread_diff (read-only): a thread's working-tree and branch diffs via ReviewService, with a character budget. Requesting one file resolves a rename's old path.
• The tool rows for pending requests now say "requests" instead of "questions", because they also cover approvals.

Verification

• Server and client-runtime typecheck pass. The touched MCP, adapter-allowlist and presentation tests pass, and lint is clean.
• I ran it live in a dev app with Claude Sonnet 5.5. Thread A ran in full-access mode and thread B in supervised mode.
  • A found B's pending command approval through t3_inbox, read it, and accepted it. B's command ran.
  • On a second approval, A declined. B stopped and the command never ran.
  • A also toggled auto-settle on itself and marked B unread, then read.
  • t3_thread_diff returned both diff sources.
  • From B, delete was refused in both forms: on itself (capability_denied) and on A (mode check).

Not verified: the outside-client path over OAuth (#15220), t3_pending_request_dismiss (no dismissable question came up), a one-file diff of a renamed file (no rename on the branch). Inbox snooze hiding was checked live, and a before screenshot of the old "Answered pending questions" label.

Still missing (follow-ups, not in this PR)

Full settings (providers, models, keybindings), git and PR actions, terminals, provider auth and usage, folder browsing for adding projects, pin reordering (the order-key helper lives in client-runtime), and opening a thread in a client.

Written by claude-opus-5-5 in Claude Code, running in T3 Code.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The PR introduces multiple production MCP capabilities, including approval execution, inbox aggregation, Git diff exposure, lifecycle toggles, and irreversible thread deletion. It also broadens Claude's default read-only tool allowlist, making the change cross-cutting and consequential rather than a contained additive update.

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

[maria-rcks]

Note

Written by claude-opus-5-5 on behalf of Maria

Moved to #15464 so it can be stacked properly: same branch and head (035a10d), now pushed to pingdotgg instead of the fork. Review threads here are resolved or answered.