github / github/app

Windows: inline MCP App view overlaps transcript text and composer

Open
#3,766 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

triage
Dominant language
No language data
Stars
2.1k
Forks
157
PR merge metrics
No merged PRs in 30d

Description

Short summary

An MCP App reporting inline display mode is painted over preceding assistant text and the message composer instead of staying within its allocated area in the conversation. The blank portion of the embedded surface also obscures native UI.

Affected version or release

1.1.18

Installation context

Windows desktop installation; local repository session with a custom stdio MCP server exposing an MCP App HTML resource (text/html;profile=mcp-app). Repository, session, local path, and user identifiers are omitted for privacy.

What happened?

The inline view overlaps the continuation of preceding native assistant text. It also covers the composer in some screenshots, leaving only the composer's edges visible. A large blank area below the buttons remains opaque and covers native UI, so this is not just text overflowing a button or table.

The missing answer continuation and conclusion exist in the transcript and were emitted before the render tool call. The tool returned the expected actions-only payload for footer mode. Evidence buttons render and can work; the problem is placement/clipping of the embedded surface.

A full-report presentation initially appeared unaffected, but subsequent short and tall synthetic full-report controls, containing no investigation data or evidence actions, reproduced the overlap too. This is not limited to footer buttons or short cards.

Image
Steps to reproduce

These reproduce the problem in the affected setup; a standalone public reproducer is not yet available.

  1. In a Windows local project session, configure a stdio MCP server with a model-visible render tool pointing to an HTML MCP App resource through _meta.ui.resourceUri.
  2. Initialize the widget using protocol version 2026-01-26 and appCapabilities.availableDisplayModes: ["inline"]. Use normal-flow CSS, with no fixed/absolute/sticky placement or negative positioning offsets.
  3. Emit ordinary assistant Markdown with several paragraphs and a final paragraph/conclusion, followed by the render call for a compact six-button footer. Button navigation is not needed to observe layout.
  4. Render the widget and send ui/notifications/size-changed with viewport width and the rounded-up content border-box height. Keep it in inline mode.
  5. Observe the lower transcript and composer: the embedded surface covers native content rather than sitting wholly below it.
  6. As a comparison, render short and tall synthetic Markdown reports in the same resource instead of a footer. Both also reproduced overlap.
Expected behavior

The inline MCP App should reserve sufficient space in the conversation and be clipped to the appropriate transcript/container bounds. Its position should track the associated transcript item while scrolling. Preceding and following native text must remain visible; the surface must never paint over the composer or other native UI.

Additional context

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the overlap in the Windows desktop conversation using the described stdio MCP server, inline display mode, and ui/notifications/size-changed. Compare the compact footer with the short and tall synthetic reports, then trace the inline MCP App surface's placement and clipping. Done means the surface reserves its space, follows its transcript item while scrolling, and never covers native text, the composer, or other UI.

Written by the indexing model from the issue text.

Assessment

Tech stack
html
Domain
desktop, frontend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.