SharePoint Copilot Apps: MOS3 ingests an empty plugin function table for every SyncSolutionToTeams (tenant-wide)

[dnys1]

Target SharePoint environment

SharePoint Online

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

💥 SharePoint Framework

Developer environment

None

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

• SharePoint Framework: 1.24.0-beta.3 (SharePoint Copilot Apps / CopilotComponent preview)
• Node.js: v22.22.0
• OS: macOS (Apple Silicon)
• Browser: Google Chrome 151 — the bug is service-side; reproduced in Microsoft 365 Copilot (BizChat) web at m365.cloud.microsoft
• Tenant: 2ef6e6c3-faf4-4a81-ab25-aab96942b9de (Microsoft 365 Developer Program tenant — no admin-center support entitlement, hence filing here)

Describe the bug / error

Since ~2026-08-30 22:00 PT, every SPFx CopilotComponent solution synced to Teams via SyncSolutionToTeams produces a declarative agent whose plugin attaches at the correct version but exposes zero functions. In the BizChat Agent-debug Raw info panel:

"enabledPlugins": [{ "id": "T_<title>.<action>", "version": "<current>", "source": "MOS3" }],
"matchedFunctionCandidates": [],
"functionsSelectedForInvocation": [],
"functionExecutions": []

The model narrates as if invoking but never can. Nothing tenant-visible errors: the SPO catalog reports IsValidAppPackage: true, the solution is deployed tenant-wide, the sync returns 200 {"value":1}, and there is no matching service-health advisory. The packaged mcp_tool_description.tools is verified correct locally in every build.

An agent whose functions were ingested before that time keeps working in the same tenant and surface — so match-time serving is healthy; it is specifically ingestion of new/updated function tables that writes empty.

Isolation matrix (one tenant, 2026-08-30/31)

App (MOS title)	Identity	Plugin content	Tools	webApi perms	Ingest time (PT)	Functions
Original (T_7d82a606-ee19-1000-b8cb-d69dade710df)	unchanged	previously worked for days	6	2	re-syncs 08-30 22:00–23:30	empty
Fresh identity #2 (T_7b1ea0ed-5445-aa91-5c4f-a044aa111e98)	all-new solution/app/component GUIDs	same as failing release	6	2	08-31 00:15 first sync	empty
Fresh identity #3 (T_793ba4db-85bd-fc59-c413-8ea16812075c)	all-new GUIDs	byte-identical to last known-working release	6	2	08-31 00:45 first sync	empty
#3 org-app record deleted + re-synced (T_2c79308c-10cb-0c22-4837-a9888c26de1c)	fresh org-app record	known-working bytes	6	2	08-31 07:52	empty
Minimal probe (T_af1e5d25-eafd-8806-549d-30de75fa60db)	all-new GUIDs, new name	one trivial tool	1	0	08-31 08:05	empty
Control: unrelated SPFx Copilot app (T_ce70bbc3-55b0-248c-1941-30dde051e5bc)	untouched	untouched	—	—	pre-window	works

Identity rotation, content revert, tool count, permission requests, and org-app record recreation were each eliminated. The only predictor of failure is ingest time.

Additional provisioning symptoms in the same window

A first sync of a new solution returned 200 {"value":1} but a re-sync returned 500 "This app couldn’t be added to Teams because it’s blocked in the Teams admin center" — while Teams admin center showed the app Published and Unblocked with no availability assignment (Available to: --, assignments API erroring in the admin UI, app absent from Graph appCatalogs/teamsApps, user install → 403). The record completed provisioning asynchronously ~3–7 h later; its function table remained empty. Reproduced twice.

Traceable request IDs (Agent debug → Raw info)

When (PT)	requestId
2026-08-31 ~00:20	0646fa4e58e135cb9902ed04916a4460
2026-08-31 ~07:50	d029a77e9e3b6f31a3fbb3b6e4614465
2026-08-31 ~11:15	45f69c748ea5653b3dfb8f9cf65d7fde

Ask

1. Confirm the MOS3-side state of the plugin function tables for the titles above, and why ingestion writes them empty for this tenant since 2026-08-30 ~22:00 PT.
2. Advise a supported trigger for re-ingestion once fixed.
3. Consider surfacing ingestion failures to tenants — today the only signal is empty matchedFunctionCandidates in a per-message debug panel, which reads as if whatever you last shipped broke, and cost a five-app bisection to rule ourselves out.

Steps to reproduce

1. Build any SPFx solution containing a CopilotComponent with one or more tools (reproduced with six tools and with a minimal single-tool app).
2. m365 spo app add … --appCatalogScope tenant → m365 spo app deploy … --skipFeatureDeployment → SyncSolutionToTeams(id=<catalog item>) → returns 200 {"value":1}.
3. Acquire the agent in BizChat (agent store, or Graph POST /users/{upn}/teamwork/installedApps).
4. Send any message that should select a tool (e.g. one of the agent’s own conversation starters); open Agent debug → Raw info.

Expected behavior

matchedFunctionCandidates lists the plugin’s functions, the model invokes one, and the CopilotComponent renders inline (this exact flow worked in this tenant for weeks, and still works for the pre-window control agent).

Actual: the plugin attaches at the correct version with an empty function table; the model narrates but can never invoke; no error is surfaced anywhere tenant-visible.

[Ashlesha-MSFT]

Hello Dillon Nys (@dnys1)
Thank you for bringing this issue to our attention. We will look into it and get back to you shortly.

[Ashlesha-MSFT]

Dillon Nys (@dnys1)

I tested this with a newly built single-tool SPFx CopilotComponent in another tenant. The solution deployed and synced successfully, and the tool was ingested, selected, and executed; the component card rendered correctly. Therefore, I could not reproduce the issue.

This supports the report’s conclusion that the failure may be tenant-specific or was transient during the stated ingestion window. I do not have access to the Agent Debug/Raw info feature, so I cannot provide the MOS3 function arrays.
Could you clarify how you enabled or accessed Agent debug → Raw info in Microsoft 365 Copilot? I tested at m365.cloud.microsoft, but I do not see that option in the agent or response menus. Is it controlled by a feature flag, developer mode, tenant setting, or URL parameter? Could you also share a screenshot showing where the option appears, with any sensitive information redacted?

[dnys1]

Ashlesha-MSFT thank you for testing — a clean run in another tenant is consistent with a tenant- and time-scoped service incident, and I can now close the loop from this side.

How to reach Agent debug → Raw info. It is Microsoft 365 Copilot developer mode: type -developer on into the chat input at m365.cloud.microsoft (-developer off to disable). Every response from a declarative agent then carries an Agent debug info card with Raw info and Documentation links; Raw info dumps enabledPlugins, matchedFunctionCandidates, functionsSelectedForInvocation, functionExecutions (with requestUri, tool arguments, responseContent) plus conversationId / requestId. It is documented under "Debugging declarative agents with developer mode" in the Copilot extensibility docs. Screenshot (nothing beyond the title IDs already in the report):

Resolution (2026-09-01, ~23:45 PT). The pipeline recovered on its own during 09-01 and everything reported empty now serves. Two behaviors explain every reading in the report:

1. Syncs made inside the window stalled rather than failed. Apps whose org-app record survived surfaced their window-era function tables roughly 38 hours later with no action on our side: the minimal probe T_af1e5d25-… by ~22:00 PT and T_2c79308c-… by ~23:08 PT, each still tagged with the window-era manifest version after later bumps.
2. Function tables are ingested asynchronously from the app definition and trail it by anywhere from two minutes to over an hour. enabledPlugins[].version moves within a minute of SyncSolutionToTeams; matchedFunctionCandidates stays [] until the table lands. The app I care about (T_9857bb5d-…, six tools, two web API permission requests) was re-synced at 22:32 PT, read empty at 23:12 (requestId 12c32aab48a376c63dd404b1fcb5b6f7) and 23:22, and matched all six functions at 23:44 — GallerySonar executed with 200 and the component rendered (conversation 642af2b0-89a8-495f-b4b0-5f752b7700eb, requestId 15f7f63c-e814-4392-8655-2c19f3857216). Three minutes later a turn in the same conversation matched nothing again (requestId 71c3e471-943a-4254-974f-0e46b7bd917b) — see the open item below.

Content was never the variable: byte-identical content read empty for 39 hours and then populated with no change on our side, and a content-identical re-sync of the minimal probe served the old table (its functionExecutions[].function.plugin.version stayed at the old version while enabledPlugins[].version showed the new one) for about 65 minutes before the new table appeared under the new version (requestId 36b4a3fc-d383-44b0-9815-215f2bbaf52c). Identity, tool count, permission requests, capabilities and instruction length never affected the outcome. One residual oddity, still open as I post this: for T_9857bb5d-… the populated table was served for exactly one request (the 23:44 one above) and every request since has matched nothing, across three further syncs of that org-app record (1.0.1 → 1.0.2 at 00:01 → 1.0.3 at 01:21, definitions published within a minute each time; sample requestIds bc07775d-55e4-4d3a-9517-68c6d9639f8a, cd7c2201-fbd4-4180-bed7-d7d47d8d91b6, c92f7997-b0f5-4720-970f-0a8e4e6094df, 5f1d6cd3-6d10-465e-b463-3e2ab0e37576). Same content synced onto a different, healthy record (the minimal probe, 1.0.6 at 01:16 PT) served all of its functions two minutes later (requestId cb7239b7-17ca-42b0-925d-e8a579d54440). So this looks like one org-app record whose function table is stuck — it was created by delete + re-sync at 22:05 PT while provisioning was still in its no-availability state, and my best guess is that an ingest from that window landed after the good one and won. I have moved the app to a fresh identity (new Teams app id) and will add the outcome here.

Two documentation gaps this would have avoided. (1) The SharePoint Copilot Apps docs do not say that the function table is ingested asynchronously after SyncSolutionToTeams and can take an hour to appear, or that enabledPlugins[].version moving is not confirmation — without that, an hour of matchedFunctionCandidates: [] reads as a broken package. (2) There is no tenant-visible ingestion state at all; even a pending/complete flag on the Teams admin center app record would have turned two days of bisection into a wait.

Two questions still stand:

1. Is there a supported way for a tenant admin to trigger or observe MOS3 function-table ingestion for an app, other than re-syncing and waiting?
2. Is the multi-hour provisioning saga after SyncSolutionToTeams (record Published/Unblocked but not yet available or installable) expected, or was it part of the incident?

Happy to close this from my side once you confirm nothing further is needed for the docs team.

[jansenbe]

Dillon Nys (@dnys1) : we're actively working on ensuring that once a declarative agent was installed it's tools will be automatically detected. At the moment it's possible you need to wait for 24h-48h before all the DA manifest components are picked up.

[dnys1]

Bert Jansen (@jansenbe) thank you — that matches what we saw once things recovered: tables landing anywhere from minutes to many hours after SyncSolutionToTeams, with nothing lost in the end. Knowing the current expectation is 24–48 h is the missing piece; a sentence to that effect in the SharePoint Copilot Apps docs would spare the next person the bisection. Nothing further needed from my side — happy for this to be closed whenever it suits you.