You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
Adding non-form params (labels, assignees) does not bypass the form.
Non-form write tools (create_branch, create_or_update_file) work normally,
so auth and permissions are fine.
Last issue successfully created via the connector: 2026-10-01.
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_request are effectively blocked. Reconfiguring the connector
URL with ?features=mcp_apps_disable_form_deferral is 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.
I saw #3435 on mcp_apps_disable_form_deferral dropping parameters on create_pull_request and issue_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-only blocked or UI-confirmed?
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?