Insiders Feedback: Carl Laliberté #3435
Description
Version: Insiders
Feature: MCP Apps write deferral (issue_write, create_pull_request, update_pull_request)
Feedback:
mcp_apps_disable_form_deferral is a mask, not the fix. It stops handing write calls to forms while keeping result views. The default path still drops parameters and blocks writes when a host advertises io.modelcontextprotocol/ui.
Observed:
- Claude (claude.ai / Desktop), issue Insiders Feedback: MCP Apps: issue_write form widget collapses immediately in Claude clients — parameters never hydrate, submit impossible #2823, still open: issue_write with owner/repo/title/body or issue_number flashes a blank create form, collapses, parameters never hydrate, submit unreachable. The deferral text is shown as an error. 4/4, payload-independent. get_me still renders.
- Same class as Skip MCP Apps UI form when issue_write update includes a state change #2163: the form cannot represent state, so the update was swallowed until a special-case bypass.
- Add explicit show_ui parameter to UI-enabled write tools #2601 show_ui defaults true and is stripped for non-UI clients. An opt-out does not hydrate the form.
- Grok iOS renders get_me. Footer is plain text, not an action.
Required behavior, one tool, two transports:
- Call parameters are the form's initial state. Dropping them is a bug.
- No UI capability, automated host, or show_ui=false: execute directly with the same parameters.
- UI host: hydrate, then submit. If hydration fails, return an explicit error. Never a success with no write, never a silent wait.
- Result views stay available after the write. Do not require mcp_apps_disable_form_deferral for that.
- Read-only must not register write-form resources (MCP App UI resources for write tools are registered in --read-only mode #2519).
Hosts that must pass the same case: VS Code, Claude, Grok, headless. Parameters in = parameters written, or a hard error.
Activity
LIdzkowski-pns commentedon Oct 8, 2026
Same issue here, reproducible on claude.ai web, default remote endpoint
(
https://api.githubcopilot.com/mcp, not/insiders) since ~2026-10-01.issue_write(create) returns "An interactive form has been shown to the user…",the form renders with empty required fields and disappears after ~1 s. No issue is created.
labels,assignees) does not bypass the form.create_branch,create_or_update_file) work normally,so auth and permissions are fine.
This looks consistent with #3348 (form deferral now unconditional on the hosted server
for hosts advertising MCP Apps support). For teams using claude.ai, writes via
issue_write/create_pull_requestare effectively blocked. Reconfiguring the connectorURL with
?features=mcp_apps_disable_form_deferralis a heavy lift for organizations(remove/re-add connector, OAuth, every member reconnects).
Request: fall back to direct execution when the form fails to hydrate, or gate deferral
on a working form round-trip. Happy to test a fix.
aedikala1 commentedon Oct 19, 2026
I saw #3435 on
mcp_apps_disable_form_deferraldropping parameters oncreate_pull_requestandissue_write, along with #3281 on confirmation prompts firing on non-destructive writes.I'm prototyping an MCP wrapper (AURA) that gates unattended write calls behind deterministic pre-commit bounds (such as capping net row-count change in a local shadow store) instead of interactive UI prompts.
For headless or CI workflows using
github-mcp-server, do you see bounded write policies living inside the MCP server itself, or does the server have to treat every write as either--read-onlyblocked or UI-confirmed?