MCP Apps: approve app tool calls inline instead of one modal per call

[chaninlaw]

Related: #29266 (MCP widget confirmations and permission options), #27067 (inline approvals are hard to spot)

Problem

When several MCP App instances render in one turn, T3 Code asks for approval once per tool call, one modal at a time. With 5 task cards on screen, I have to click Confirm 5 times before the cards finish loading.

What happens today:

1. The agent calls an app tool 5 times (for example, show 5 tasks), so 5 MCP App frames render in the timeline.
2. On load, each frame calls a server tool that has no readOnlyHint.
3. Each call goes through requestConfirmDialog in McpAppFrame.tsx. confirmDialog.ts keeps one active dialog and queues the rest in FIFO order.
4. You get 5 full-screen modals, one after another. Each one shows only one call's raw JSON args, like {"task_id": "DEMO-101"}.

Why this hurts:

• Approval fatigue. The prompts are identical except for one ID, so people stop reading them. That defeats the point of asking.
• No overview. You can't tell how many requests are queued, or which card each one belongs to.
• No batch action. Chat approvals already offer "Always allow this session". App calls have no equivalent.
• The whole UI is blocked. The modal covers the timeline, including the card that's asking.

The cost grows with the number of instances: a list of 10 tasks means 10 clicks.

Reproduction (no real data): a fake stdio MCP server called clickup with:

• show_task: readOnlyHint: true, _meta.ui.resourceUri: ui://clickup/task-card
• get_task_details: _meta.ui.visibility: ["app"], no annotations. The card calls it on load.

Prompt Claude Haiku with "Use show_task for DEMO-101 … DEMO-105, in parallel", then open the thread.

I first ran into this with the real ClickUp MCP App. I haven't confirmed whether its tools leave out readOnlyHint. Server authors should annotate read-only tools, but even then the host needs to handle many legitimate write calls without a modal for each one.

Proposal: one-line inline approval on the app frame

Move MCP App approvals out of the global modal and onto the frame that's asking. This is the same idea as timeline approvals (TimelinePendingApprovalRow): the request appears where the work is happening, and nothing else gets blocked.

I built a working prototype to check that this fits the existing UI:

Each waiting frame gets one line above it:

🛡 Waiting for approval · clickup wants to run get_task_details ⓘ Decline Approve all 4 More

• Details on demand. Hovering ⓘ shows the full arguments in a popover.

  

• Batch. When several frames wait on the same server + tool, the first line's primary action becomes Approve all N. "Approve this one" moves to More.

• Thread-scoped trust. More includes "Always allow in this thread", which is scoped to <server>.<tool> in that thread only.

  

• Doesn't block. You can keep scrolling and typing while frames wait, and each frame resolves on its own.

• Stays visible if the card is collapsed. If MCP App cards become collapsible (Allow collapsing or hiding inline MCP app cards while keeping the connector enabled #30907, Per-server "collapse by default" for MCP Apps (Atlassian's Jira cards take over Claude threads) #31591), the approval line stays outside the collapsed area.

• Lifecycle. If a frame unmounts, its pending request is declined, the same as when the last dialog host goes away today. Fullscreen isn't allowed while that frame has a pending request.

Paired with an "approvals waiting" banner (addresses #27067)

#27067 points out that inline approval rows are easy to miss once they're off-screen. Inline approval alone would repeat that problem, so the proposal pairs it with a docked banner above the composer:

🛡 5 approvals waiting Show

• It counts all pending approvals in the thread, both provider approvals (TimelinePendingApprovalRow) and MCP App approvals. That way there is one place to look, whatever kind of request is waiting.

• Show scrolls to the first waiting row.

  

• It's an ordinary ComposerBannerStack item (variant="warning", ShieldIcon, ghost Button size="xs"), the same shape as the model-fallback and fresh-session banners.

• The banner and the rows complement each other. Each request stays on its row, where its context is, and the banner keeps you from missing it.

Consistency with the existing UI

The bar only combines patterns T3 already uses:

Part	Reused from
🛡 Waiting for approval in text-warning, then a muted ·	TimelinePendingApprovalRow
Decline (muted) / Approve (default) / More menu (side="top" align="end")	ComposerPendingApprovalActions with presentation="inline"
Truncated label, plus a ⓘ openOnHover PopoverPopup tooltipStyle side="top"	NoticeText in ComposerBannerStack
Args as font-mono text-xs <code> with max height and scroll	TimelinePendingApprovalRow label
text-xs, flex flex-wrap gap-x-2 gap-y-1, which wraps on narrow widths	all of the above
"N approvals waiting" banner above the composer	ComposerBannerStack items (modelFallbackBannerItem, freshSessionBannerItem)

The only intentional difference is "Approve all N" as the primary action when requests are grouped. That's the click reduction this proposal is about.

Security

• The line is host UI outside the sandboxed iframe, so the app can't draw over it or click it.
• What needs approval doesn't change: tools without readOnlyHint still ask.
• The full arguments are always one hover away.
• Trust is never server-wide or cross-thread. It lives in client memory, so a reload asks again.

Mobile

Mobile has the same problem. McpAppWebView.tsx shows one native Dialog.alert per call.
On Android it's likely worse: a comment there notes that Android dismisses earlier alerts
when a new one opens, and dismissed requests are declined. With 5 cards, the first 4 could
be declined before the user sees them (from reading the code, not yet tested on a device).

The same model should carry over: a one-line approval above the app WebView, plus the
"approvals waiting" banner. I'd ship web/desktop first and follow with mobile in the same
direction, unless you'd rather land both together.

Prototype and open questions

I have a working web prototype: a small approval store, a one-line bar component, McpAppFrame.tsx swapping requestConfirmDialog for the store, and one ComposerBannerStack item in ChatView.tsx. Happy to open a PR if the direction looks right.

Open questions:

1. Banner scope. The prototype shows the banner whenever anything is waiting, like the old docked card. Should it hide while the waiting row is already on screen? And should Show also cover rows the virtualized timeline hasn't mounted yet?
2. Where trust lives. I'd start with client memory (simplest) and only move it to the server per thread if people ask for it.
3. Fullscreen. Pin the line inside the fullscreen frame instead of returning to inline?

---

Reproduction, prototype, and draft prepared with Claude Opus 5.5 via Claude Code inside T3 Code. Real agent turns used Claude Haiku 5.5.

[mkaradeniz]

Another case for this proposal: one long-lived app frame that asks repeatedly, not many frames that ask once.

What happened. On 29 October, an inline Mobile Dev MCP App (Android emulator screen stream) asked for approval of mobile_android_stream_session again and again. The tool has readOnlyHint: false, so every call goes through requestConfirmDialog. The app reconnects with backoff (0.5 s to 10 s) after a failed stream, and every reconnect is a new tool call with a new modal. The prompts continued while the agent worked on other things. The thread was in Full access mode, which does not apply to app tool calls. We ended up moving the work to a new thread without the panel.

What the proposal already covers. "Always allow in this thread" for <server>.<tool> would stop the repeated prompts after the first approval. Batch approval alone would not, because the calls come one after another, not at the same time.

What it does not cover yet: Decline. In host.ts, a declined call reaches the app as a JSON-RPC error with code -32000 and the message "Declined by the user.". That is the same code as "Too many requests in flight." and any other tool failure. An app that reconnects on errors cannot tell a refusal from a network failure without matching the message text. Mobile Dev (from reading its bundle, not tested) stops its reconnect loop only for one internal error type, so a decline probably counts as a normal failure and leads to the next prompt.

Suggested additions:

1. Send user refusals with a dedicated error code or a structured field, so apps can stop retrying. Document it for app authors.
2. Optionally, after a decline, auto-decline further calls of the same <server>.<tool> from that frame until the user acts in the frame. This keeps a retry loop from producing new prompts even when the app ignores the refusal.

Tests could cover: approve once, then the app reconnects without a new prompt; decline, then background retries produce no new prompt; a grant for one tool does not apply to other tools or threads.

---

This comment was researched, drafted, and posted by an AI agent (Claude Opus 5.5 via Claude Code in T3 Code) on behalf of the account owner.