Feature request: Dedicated MCP management UI and scoped permissions for interactive MCP Apps #32132

Interactive MCP Apps can need recurring state-changing calls to save user progress or coordinate an ongoing interaction. In T3 Code's web/desktop widget path, each such call opens a confirmation dialog. Approving one call does not authorize the next, so an otherwise routine interaction can become a sequence of modals. If the app has a response timeout, approval delays can also surface as connection or save errors.

Reproduction

1. Connect an MCP server that exposes an interactive app with accurately annotated, non-read-only state updates.
2. Open the app in a thread and begin an interaction that periodically saves state.
3. Confirm a tool request, then continue interacting.
4. Observe another confirmation for the next state update, including updates initiated by the app rather than a new agent turn.

Observed confirmation shape: Allow <server> to run <tool>?, followed by the tool arguments and Cancel/Confirm actions. The issue also occurs when the agent can reach the MCP server successfully.

Expected behavior

Keep approval as the default, while allowing the user to explicitly grant a bounded, revocable permission for selected app tools during an interaction. State-changing tools should remain honestly annotated; declaring them read-only to obtain usable interaction is not a suitable workaround.

Suggested approval choices:

• Allow this request once.
• Allow the selected tool for this app session, with the server and scope clearly displayed.
• Deny, and stop repeatedly prompting for the same denied background operation.

The grant should be scoped to the relevant server, app instance/session and tool, with explicit expiry and revocation. It should not silently authorize unrelated agent tool calls, other apps, or future sessions. The host should communicate pending approval, denial and disconnection distinctly so apps can handle them without aggressive retries.

Dedicated MCP UI

A dedicated MCP settings area would make discovery and troubleshooting much clearer:

• Show configured servers, connection state, exposed tools and interactive app support.
• Provide connect/reconnect/disconnect controls and actionable, redacted errors.
• Display tool annotations and distinguish agent-tool permissions from interactive-app permissions.
• Show active app grants, their scope/expiry, and controls to revoke them.
• Make the same permission concepts available across desktop, browser and mobile clients.

Source context

In the upstream snapshot reviewed, McpAppFrame.tsx checks info.value.readOnly and calls requestConfirmDialog for each non-read-only invocation. That callback does not consult a remembered grant or the thread's permission mode. The reviewed upstream snapshot is not a claim about every shipped version.

Widget tool-call approval path

Current workaround

Users can move the interaction to a separate browser app, but that loses the seamless in-thread experience MCP Apps are intended to provide. Scoped app permissions and a dedicated MCP UI would let these interactions remain usable within T3 Code without globally disabling safeguards.

Related report

Related: #29266 also reports extra confirmations for interactive MCP widgets. This request focuses on the general permission model for recurring app calls and dedicated MCP management UI, independently of that report's tool-name compatibility problem.