SPFx Copilot components: tool arguments are put into the PortableComponent.aspx URL; long or non-Latin arguments make the brokered sign-in fail (401 / "non-JSON response") and the card stays blank #11064

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Developer environment

macOS

What browser(s) / client(s) have you tested

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 Safari
• mobile (iOS/iPadOS)
• mobile (Android)
• not applicable
• other (enter in the "Additional environment details" area below)

Additional environment details

• Microsoft Edge 155.0.4283.45 (macOS 27.0.1)
• Client: Microsoft 365 Copilot on the web (copilot.cloud.microsoft), declarative agent with an SPFx Copilot UX component (componentType: CopilotComponent, copilotType: Ux), tool discovery dynamic
• SPFx 1.24.0-rc.0 (@microsoft/sp-copilot-component 1.24.0-rc.0), Node.js v22.22.0
• Boot script in the widget frame: https://res.public.onecdn.static.microsoft/files/sp-client/spfx-mcp-boot_none_123671a42a8fc716bea5.js
• Correlation IDs of failed loads: 8f6145a2-9089-0000-2bd6-45a5f3f760e3 (2026-10-16), e9b145a2-20eb-0000-2bd6-4660386ea2fb (2026-10-17)

Describe the bug / error

What happens

From time to time a Copilot UX component does not load: the card's panel stays white. The component's own code never runs (its bundle is never requested). The console of the SharePoint frame shows the SharePoint service worker failing while navigating to the component page:

ApiError: Unacceptable or no response.
    at sf.onFailure (spserviceworker.js:646)
ApiError: Failed to parse unexpected non-JSON response.
    at aN._parseUnexpectedNonJson (spserviceworker.js:619)
ApiError: ParseResponse: Failed to parse unexpected non-JSON response.
    at aN.processResponseError (spserviceworker.js:32)
GET https://<tenant>.sharepoint.com/_layouts/15/Authenticate.aspx?Source=%2F_layouts%2F15%2FPortableComponent.aspx%3FcomponentId%3D…%26properties%3D%7B…%7D%26usePwBrokeredAuth%3Dtrue…&sw=auth  401 (Unauthorized)
Failed to load resource: PortableComponent.aspx?…componentType=CopilotComponent…  401 (Unauthorized)

Reloading Copilot or retrying usually works. Other cards in the same session (same component, shorter arguments) load fine.

How the component page is built (from the shipped spfx-mcp-boot script)

Copilot renders the component in https://<hash>.widget-renderer.usercontent.microsoft/mcp-widget.html. Its boot script sets the src of an inner #sp-iframe to PortableComponent.aspx and puts all tool arguments into the query string:

const c = new URL(pageUrl);
c.searchParams.set("componentId", d);
c.searchParams.set("componentType", l);
u && c.searchParams.set("properties", JSON.stringify(u)); // ← every tool argument, in the URL
// web: c.searchParams.set("usePwBrokeredAuth", "true")    (native hosts get deepNaaTopOrigin instead)
// then culture, correlationId, hostOrigin

Why this hits some cards and not others

URLSearchParams percent-encodes UTF-8. An ASCII character is 1 URL character; a letter in Greek, Cyrillic, Hebrew or Arabic becomes 6; Thai, Devanagari, Amharic, CJK and most other scripts become 9 (e.g. ก → %E0%B8%81). The same tool call therefore produces very different URL lengths depending on the language and on how much text the tool passes. For a typical story card (headline + about 100 words + an image description), computed with the boot script's own encoding:

When the brokered sign-in needs a round trip through Authenticate.aspx (&sw=auth), the whole component URL is nested once more inside Source= and grows again. For non-Latin text that request goes past the 8 KB request-line limit common to web servers and gateways. All failures we captured were cards with non-Latin (Thai) arguments; cards in Latin-script languages never failed. This supports the theory but does not prove it: the responses were 401 and non-JSON, not 414 (URI Too Long).

Who else is affected

This is not specific to one language or one component. Any SPFx Copilot component whose tool arguments are long can hit it: free text, lists or structured data, about 100 words in any non-Latin script, or long text in any script. Every Copilot UX component passes its arguments through this URL. Because it only shows up when the brokered sign-in takes its extra round trip, it looks random and is hard to trace back to the arguments.

Side effect: the full tool arguments (generated text that may contain business content) end up in a SharePoint URL. There they are subject to request logging and URL length limits. That seems unintended for content the frames already exchange via postMessage (ui/notifications/tool-input).

Not yet ruled out: a stale SharePoint service worker, as suggested in #11006. The errors originate in spserviceworker.js.

Steps to reproduce

1. Create an SPFx 1.24.0-rc.0 Copilot UX component whose tool has a free-text argument (e.g. text, up to ~1,200 characters) and a declarative agent that calls it. Deploy both to a tenant.
2. In Microsoft 365 Copilot on the web (Edge), get the agent to send about 100 words in a non-Latin script, e.g. Thai or Greek. In our case the agent writes the card text in the user's language, so we just asked in Thai.
3. Repeat over a longer session or after some idle time, so that SharePoint's brokered sign-in renews and navigates via Authenticate.aspx.
4. Now and then the card stays blank. The SharePoint frame's console shows the spserviceworker.js errors and the 401 on Authenticate.aspx / PortableComponent.aspx above. For comparison, the same request in English loads.

Expected behavior

The component loads regardless of the language and length of its tool arguments. The arguments should not have to travel in the page URL, and through Authenticate.aspx?Source= on top of that. The host already forwards them to the component via postMessage (ui/notifications/tool-input), which has no length limit and keeps generated content out of URLs and server logs. If the URL is kept, a documented maximum argument size per tool call would let component authors stay within it.