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

[Sensei85]

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.

[waltergalvao]

Yes please - I miss the UI so badly

[djgilcrease]

NOTE: This comment was left by gpt-6.1-sol high on behalf of Dj Gilcrease.

For the MCP management UI portion of this request, I published an external MCP Manager plugin with server definitions, environment/project scopes, provider/account-instance switches, and project-owned OAuth sign-in, reconnect/account switching and disconnect. The plugin proposal update has screenshots and install details.

It requires the prototype plugin host fork and does not run in stock T3 Code. It does not implement this thread's scoped MCP Apps approval grants or fix repeated confirmation dialogs. It does not expose active app/tool grants, change tool annotations, or bypass existing approvals. That permission model remains a host/provider concern.

The plugin experiment is relevant because optional management features can evolve in external repositories while the shared host keeps authorization and native client integration. People could solve and distribute their own feature needs through that contract, subject to its actual capabilities. The central plugin discussion is where I am collecting feedback on those boundaries.

Account-switch clarification: OAuth connection credentials are not remembered MCP App permissions. In released v0.3.0, a completed account switch/reconnect rotates the private route credential and clears that definition's transport sessions; disconnect removes the local OAuth connection. I verified rejection of old credentials/sessions with an unchanged project session as the control, using a local OAuth/MCP fixture against the released bundle. Normal token refresh preserves the connection. This was not a rendered-widget or remembered-consent test: the plugin has no app-consent cache, and the reviewed host still confirms every non-read-only widget call. Account labels are user-entered, not verified identities. Any future remembered permission needs an authenticated connection/identity binding and explicit invalidation; a URL or label alone is insufficient.

[Sadrak2017]

What would invalidate a remembered grant after an MCP account switch? Reusing the same server URL should not carry consent to a different identity. This is a governance question we also consider while developing Sinaps Studio at SinapsData: approvals need a clear target, not just a display name. I'd test disconnect, account switch and reconnect against the same widget, with an unchanged session as a control. Would those changes invalidate its existing grants?

[djgilcrease]

NOTE: This reply was left by gpt-6.1-sol high on behalf of Dj Gilcrease.

A remembered app permission should not survive a change of account just because the server URL stays the same. MCP Manager v0.3.0 does not implement remembered MCP App permissions, so I cannot claim it invalidates such grants today. Its OAuth connection credentials and the app's consent to run a tool are separate things. The reviewed host still asks for confirmation on every non-read-only widget tool call.

I checked the released plugin bundle against a local OAuth/MCP fixture with two projects using the same server URL:

• Successful account switch: the private route URL stays the same, but its bearer credential changes. The old credential gets HTTP 403; presenting an old session with the new credential gets 404. A fresh session reaches the new account.
• Disconnect, then reconnect: disconnect rejects the old connection. Reconnecting, even to the same account, generates another credential and rejects the previous session.
• Unchanged control: the other project's original connection/session continues working throughout. Ordinary access-token refresh also preserves the existing connection/session.

Those checks passed against the v0.3.0 artifact, alongside all 13 existing plugin tests. They validate connection invalidation, not the same rendered widget or a remembered-consent cache. See the pinned implementation for credential rotation, disconnect, and credential/session checks. Existing provider sessions need to reconnect/restart to receive the new route credential; this is not a promise that an open widget reconnects automatically. Starting or cancelling a new sign-in alone does not replace the completed connection.

For the proposed remembered permissions, I would require a grant to bind to the environment, server definition, authenticated connection generation, app instance/session and selected tool/scope, with expiry and explicit revocation. A trusted issuer/account identity should be included when available; the current account label is user-entered and is not identity proof. Disconnect, completed account switch/reconnect, or a relevant authentication/configuration change should invalidate the old generation, with the host checking it again when a tool executes. A normal refresh within the same authenticated connection should not count as an account switch. These are proposed requirements, not shipped permission behavior.

I have clarified our MCP Manager post and the management-UI comment above to keep that boundary explicit. The remaining design decision for this request is how the host represents and enforces that identity-bound app consent.