[Bug]: Jira MCP Apps render blank inline cards despite successful tool results #16992

Problem

In the 2026-10-07 desktop nightly, Jira MCP Apps embeds appear as empty rounded white rectangles in a thread. In light mode the rectangles blend into the background but still reserve space. Collapsing the reasoning trace leaves four app embeds: two working Confluence document cards and two blank Jira cards.

This is separate from the Confluence dark-mode text contrast report (#16991).

Read-only findings

Initial read-only inspection of persisted turn items and captured HTML establishes:

• Exactly four tool outputs carry t3McpApp: two getConfluencePage calls and two getJiraIssue calls from the Atlassian MCP integration.
• All four tool items completed successfully. Neither Jira result has isError: true; both contain structured issue data (issues and context, with one issue node).
• All four captured HTML attachments exist. The two Jira documents are identical, approximately 2.7 KB HTML shells containing an empty app root and an external module script plus stylesheet. The two Confluence documents are identical, approximately 753 KB captured documents with their JavaScript inline.
• A nearby preview_evaluate call failed with Preview automation evaluate timed out after 15000ms. Its stored output is a text error and contains no t3McpApp reference. One Jira capture precedes that timeout; the other follows it immediately, explaining why a blank app appears beneath the error.
• A read-only HTTP request to the Jira shell's public module asset currently returns 200, JavaScript content, and Access-Control-Allow-Origin: *. The declared resource CSP permits its origin. This does not prove the asset loaded or executed successfully in the affected client.

The blank rows therefore belong to successfully captured Jira MCP resources, rather than an embed created by the evaluate failure. The initial resource read/capture succeeded. Subsequent synthetic browser verification isolates an uncaught cookie-access exception during Jira app rendering (details below). Temporal proximity alone does not establish a connection to browser automation.

Source inspection

Latest main at inspection: 3143335fc3a568cbbb5174764961889272135cb9.

• session-logic.ts creates standalone MCP app rows from completed tool items carrying a matching reference. These survive collapsing the work trace.
• McpAppSnapshot.ts captures HTML and injects CSP; it does not snapshot external JS/CSS dependencies or establish that the app renders.
• McpAppFrame.tsx retains an app-height container (initially 320 px) and loads a sandboxed opaque-origin iframe. Its visible failure state covers asset URL acquisition; it does not cover module execution failure, missing app initialization, or an empty rendered root.
• host.ts waits for ui/notifications/initialized before replaying the tool result, with no initialization-failure state exposed to the frame. An app that never initializes can remain empty indefinitely.

These explain why a client-side app failure can leave reserved blank space. The synthetic reproduction below narrows the failure to Jira cookie access in an opaque-origin sandbox. The actual nightly client was subsequently inspected in Zen; see the live confirmation below.

Authorized synthetic browser verification

Used a separate T3 collaborative browser tab, without accessing the private thread or manipulating the user's browser. The test recreated the Jira HTML shell using its public module/CSS assets, sandbox="allow-scripts allow-forms", a permitting resource CSP, a minimal MCP initialize response matching the inspected host, and entirely synthetic issue data (DEMO-1). It was an isolated app reproduction, not a full T3 client integration test.

Observed sequence:

1. Both the JavaScript module and stylesheet loaded successfully (HTTP 200).
2. The app sent ui/initialize and completed ui/notifications/initialized.
3. After receiving synthetic ui/notifications/tool-result, an uncaught SecurityError occurred:

Failed to read the 'cookie' property from 'Document':
The document is sandboxed and lacks the 'allow-same-origin' flag.

The public bundle stack passes through cookie get, getAnonymousIdFromStorage, getAnonymousIdFromCookieAndUpdateLocalStorage, and getAnonymousId, then analytics construction and a React effect. The first throwing location is bundle line 123, column 65004. The app root subsequently contains zero child elements and no text.

4. As a diagnostic control, an empty cookie getter/setter was substituted only inside the synthetic frame before the bundle ran. Without changing the sandbox, module, synthetic result, or host response, the card rendered Synthetic example issue, Synthetic project, DEMO-1, and Open. The app reported a height of 76 px.
5. Removing that diagnostic substitution and repeating the result replay restored the cookie exception and empty root.

An IndexedDB access-denied promise rejection also occurs, including in the control where the card renders. It is therefore not the blocking exception isolated by this test. localStorage setup warnings similarly do not prevent initialization.

This establishes a reproducible incompatibility between this Jira bundle's unguarded analytics cookie access and the host's intentional opaque-origin sandbox. It strongly explains the two blank Jira embeds, independently of the nearby preview automation timeout. The subsequent Zen inspection confirms the same cookie-access failure in the actual nightly client.

The diagnostic cookie substitution is not a proposed production fix. Broadening the iframe's origin privileges is not necessary to demonstrate the cause. Any eventual fix should preserve sandbox isolation and ensure widget telemetry/storage failures cannot erase the result; the host should also expose app runtime failures rather than leaving blank space.

Confirmed in the actual Zen nightly client

After explicit authorization, inspected the affected thread in the logged-in hosted nightly (0.0.46-nightly.20261007.2787) using Zen's native UI and Developer Tools. No scripts or diagnostic substitutions were applied to the live thread.

• Both Jira iframe accessibility trees have no child content; both Confluence frames have document-card content.
• The Jira bundle logs receiving ui/notifications/tool-input and ui/notifications/tool-result. Result replay therefore reached the app after initialization.
• The console contains two uncaught exceptions from the Jira bundle:

DOMException: Document.cookie getter: Forbidden in a sandboxed
 document without the 'allow-same-origin' flag.

The source-mapped stack in both cases is:

js-cookie/dist/js.cookie.mjs:80
analytics-web-client/.../cookie/cookieWrapper.js:30
getAnonymousIdFromStorage (integration/user.js:41)
getAnonymousIdFromCookieAndUpdateLocalStorage (integration/user.js:94)
getAnonymousId (integration/user.js:32)
analyticsWebClient.js:585
web/src/analytics/analytics-client.tsx:58
web/src/analytics/index.tsx:26
web/src/jira/jira-widget.tsx:117
React

This matches the synthetic reproduction and confirms the failure is after successful initialization/result delivery, rather than the nearby preview_evaluate timeout or failure to fetch the app's module. An initialization-only deadline would not catch this case. No private screenshots, URLs, identifiers, or tool data are included here. Zen was returned to the thread view with Developer Tools closed.

Expected behavior

Successful Jira tool results should render their app cards. If an app cannot load, initialize, or render, the thread should expose an understandable failure and access to the tool result instead of indefinite blank space.

Scope and related issues

Observed in the desktop report and confirmed in hosted web through Zen. Mobile behavior was not verified. #7212 concerns the floating collaborative browser panel, not inline MCP app cards. #16991 concerns Confluence theme contrast. Searches for MCP blank/empty/embed/render and Jira reports found no matching issue.

No private screenshots, thread IDs, customer identifiers, private URLs, or raw tool payloads are included. Live state was accessed read-only. After explicit authorization, a separate synthetic preview tab and read-only inspection of the actual nightly thread in Zen were used. No private screenshots were taken or published, and no code changes were made.