Insiders Feedback: issue_write with method create returns “form shown” but no form is visible to the user in Claude chat #3538

Activity

1. github-actions

   added

   request ai review

   and removed

   request ai review

   on Oct 20, 2026
2. DavidPivert commented on Oct 20, 2026

   

   DavidPivert

   on Oct 20, 2026

   More actions

   Same here, in another Claude client: the Claude desktop app (Code tab, Claude Code agent), 2026-10-20.

   • Read widgets render fine: the get_me profile card displayed correctly in the conversation.
   • issue_write with method create returned "An interactive form has been shown to the user… The issue has NOT been created yet", but no form was visible on the user's side, so there was nothing to submit. list_issues confirmed the issue was not created.
   • Workaround: created it with gh issue create instead.

   An opt-out (see #3455) or a fallback to a direct create when the client can't render the form would avoid this dead end.
3. ndamulelonemakh commented on Nov 4, 2026

   

   ndamulelonemakh

   on Nov 4, 2026

   More actions

   I have been battling with this issue for weeks as well.
4. SamMorrowDrums

   added

   bugSomething isn't workingSomething isn't working

   insidersFeatures for the Insiders mode of the GitHub MCP ServerFeatures for the Insiders mode of the GitHub MCP Server

   user-experience

   on Nov 4, 2026
5. nickytonline commented on Nov 4, 2026

   

   nickytonline

   on Nov 4, 2026

   Last edited by nickytonline

   More actions

   copying my comment over here as it's Claude.ai specific. Originally posted at #2823 (comment)

   I'm running into this issue as well:

   Version: hosted remote server, as deployed on 2026-10-20
   Feature: MCP Apps form deferral (create_pull_request)
   Client: claude.ai web. VS Code Insiders works for comparison (form stays up, PR is created on Submit).

   Adding iframe-level evidence on where it breaks, and some data on the inconsistency.

   Failing case: what the form iframe sees (DevTools console on claude.ai)

   iframe -> host  ui/initialize
   host -> iframe  (result)
   iframe -> host  ui/notifications/initialized
   host -> iframe  ui/notifications/tool-input-partial
   host -> iframe  ui/notifications/host-context-changed
   host -> iframe  ui/notifications/tool-input-partial
   iframe -> host  ui/notifications/size-changed
   

   There is no final ui/notifications/tool-input, no tool result, and the iframe never sends tools/call (no ui_get for branches or reviewers). The form is visible for about 0.75s with every field blank, then the widget is removed and the call shows as Failed. The only console noise is Unrecognized Content-Security-Policy directive 'webrtc' (an ignored directive) and [MCP Apps] oncalltool handler replaced. There is no CSP block.

   Working case: same params, tool executed directly

   A JS hook on the parent window recorded this. The PR existed at 09:52:17Z, the iframe was added at 09:52:19Z, and the widget then showed "Pull request created successfully". Messages from the iframe, in ms after it was added:

   +0    iframe-added (sandbox="allow-scripts allow-same-origin allow-forms")
   +110  ui/notifications/sandbox-proxy-ready
   +155  ui/initialize
   +160  ui/notifications/initialized
   +173  tools/call ui_get {method: "branches",  owner, repo}
   +173  tools/call ui_get {method: "reviewers", owner, repo}
   +178  ui/notifications/size-changed
   

   So the form hydrates and loads branches and reviewers when it receives owner and repo. In the failing case it never gets them.

   Reading of the code (hypothesis, I have not seen the host's code)

   NewToolResultAwaitingFormSubmission returns IsError: true on purpose, and its comment says the host still renders the UI because rendering is keyed off _meta.ui. claude.ai appears to treat the error result as terminal: it unmounts the app and never delivers the final tool-input.

   Inconsistency

   Every call used the same six params (owner, repo, title, head, base, body), so per shouldDeferToForm the difference is clientSupportsUI (or the flag). In one conversation the first 3 calls deferred to the form and the next 6 executed directly. A new conversation then deferred again. I can't tell why UI capability varied within one conversation. This fits the comment above that clients without UI support run straight through.

   Questions

   1. Is keeping the app mounted on IsError: true a documented host requirement?
   2. For stateless HTTP, how is UI capability stored and restored per request (HasUISupport in ctx)? Could it be lost between requests?

   Related: #3455. I haven't tested the ?features=mcp_apps_disable_form_deferral workaround reported above.

   ---

   AI disclosure: I investigated this with Claude (Anthropic). Claude used the Claude in Chrome browser extension to read the form iframe's message traffic in claude.ai, and read this repo's public source (pkg/github/ui_capability.go, pkg/utils/result.go, pkg/github/feature_flags.go on main, 2026-10-20) to explain the form-versus-direct behavior. This comment was drafted with Claude's help from that investigation.