canvas-authoring MCP: pushing to one canvas app corrupts a different app's live coauthoring session + causes server-side component renames

[ashergill-sunc]

Summary

Working across two different canvas apps in the same Power Platform environment via the canvas-authoring MCP server's connect(environment_id, app_id, login_hint) / sync_canvas(directoryPath) / compile_canvas(directoryPath) tools produced two distinct corruption incidents in one working session, both against real production apps with live users.

Setup:

• App A: a standard canvas app with several dozen screens
• App B: a component library app that App A consumes several components from (App A embeds instances of components defined in App B)

Incident 1 — App A's live session collapsed into App B's content

Sequence:

1. connect() to App A (app_id = A), did edits, compile_canvas pushed successfully, verified via sync_canvas (25 screens present as expected).
2. Later in the same running session, connect() to App B (different app_id), did a compile_canvas push there (adding a new component to the library).
3. Immediately after, re-synced App A (same app_id = A as step 1) and found its live coauthoring session had collapsed to a single blank default screen plus a set of component instances matching App B's library — as if App B's push had landed in App A's session, or the two apps were sharing one underlying live buffer.

This was reproduced twice in the same working session (recovered from local backup via a fresh compile_canvas push to App A between occurrences).

Incident 2 — ordinary push renamed unrelated components server-side

A later compile_canvas push to App B (rebuilding one specific component) caused other, untouched components already in the library to get renamed/duplicated server-side without being requested — e.g. ComponentX → ComponentX_2, several others got _1 suffixes appended to both filename and internal ComponentDefinitions key.

What we found while investigating

• [canvas-apps][Bug] sync_canvas/compile_canvas never detects active coauthoring session — persistent "No active coauthoring canvas designer session detected" #219 reports the tool's internal SessionId staying identical across reconnects — suggesting session state may not be cleanly re-derived per connect() call, which is consistent with what we saw in Incident 1.
• [canvas-apps][Bug] sync_canvas does not include component libraries, blocking all edits on apps that reference them #86 confirms component-library handling (specifically sync_canvas not fetching library definitions for a consuming app) is a known-rough area, consistent with Incident 2.
• Neither issue describes these exact symptoms (cross-app session bleed, or unrequested server-side component renaming), so filing separately.

Impact

Both apps in question have real end users. The corruption was only recoverable because we happened to have an independent local backup of App A's source to push back from. Anyone relying solely on this MCP server's live session as their working copy while touching two apps in one session would have lost work with no recovery path other than Power Apps' built-in Version History (which itself hit a "app is locked" error during our recovery attempt, likely for the same underlying reason).

Environment

• Canvas-authoring MCP server (ships with/used via Claude Code)
• Both apps in the same Power Platform environment, same signed-in maker identity
• Happy to share exact environment/app IDs and repro timing privately if a maintainer wants to investigate directly — omitted here since these are a live client's production identifiers.

Suggested mitigation for other users until this is understood

• Treat this tool as unsafe for touching more than one canvas app (including component libraries consumed by another app) within a single working session — use a fresh session per app.
• Capture an independent .msapp snapshot (e.g. via pac canvas download) before any compile_canvas push, since the live session cannot currently be trusted as the sole copy of the work.