Bug Report – Copilot Studio Agent Sharing Fails Silently

(0) Share

Report

Posted on by JA-16071133-0

Summary

When sharing a specific Copilot Studio agent with a team member, the UI reports success ("Todas as alterações de permissão foram salvas com êxito" / "All permission changes were saved successfully"), but the added user does not persist in the sharing list. A newly created test agent shares correctly under the same tenant/environment/account, indicating the issue is isolated to this specific agent, not a tenant-wide permission or policy issue.

Environment

Product: Microsoft Copilot Studio
Environment URL: copilotstudio.microsoft.com/environments/Default-2cf6bbb4-bd79-461a-abc5-9786af163a66/bots/ce23d5aa-de76-f111-ab0e-70a8a5ae8b0c/overview
Browser: Microsoft Edge
Affected agent: Assistente Gente e Cultura (HR agent), deployed to Microsoft Teams via Copilot Studio
Control test: A newly created test agent in the same environment shares successfully with the same target user

Steps to Reproduce

Open the affected agent in Copilot Studio.
Open the "⋯" menu on the agent card and select "Compartilhar" (Share).
In the Share panel, add a user (e.g., a colleague) and set permission level to "Visualizador" (Viewer).
Click "Compartilhar" (Share).
UI shows "Salvando..." (Saving...) followed by a success banner: "Todas as alterações de permissão foram salvas com êxito."
Close and reopen the Share panel (or refresh) — the added user is no longer listed. Only the original owner remains.

Expected Behavior

The added user should appear in the sharing list with the assigned permission level and should be able to access the agent afterward.

Actual Behavior

The success message is shown, but the permission change does not persist. The user is silently dropped from the list.

Console Errors Observed During the "Compartilhar" Action

While reproducing the issue with DevTools open, the following errors were logged in the Console at the moment the share/save call was made:

GET https://powervamg.us-il104.gateway.prod.island.powerapps.com/chat... 
404 (Not Found)

SyntaxError: Failed to execute 'json' on 'Response': Unexpected end of JSON input
    at e.<anonymous> (main.e0e32bf0.js:2:2418564)
    at Generator.next (<anonymous>)
    at m (main.e0e32bf0.js:2:2412054)
    at a (main.e0e32bf0.js:2:2412257)
    at main.e0e32bf0.js:2:2412316
    at new Promise (<anonymous>)
    at e.<anonymous> (main.e0e32bf0.js:2:2412197)
    at e.<anonymous> (main.e0e32bf0.js:2:2418634)
    at e.<anonymous> (main.e0e32bf0.js:2:2418211)
    at Generator.next (<anonymous>)

This sequence (GET to the gateway returning 404, immediately followed by a JSON parse failure on an empty response body) repeats twice during the save operation. This suggests the client is attempting to fetch/refresh agent or connection data as part of the share flow, receiving an empty 404 response, and then failing to parse it — while the UI still reports the save as successful (likely because the actual permission-write call succeeds, but a dependent follow-up call used to refresh/confirm the list fails and the UI doesn't handle that failure, silently reverting the displayed list).island.powerapps.com
Additionally, an unrelated console warning was observed: , and Content Security Policy report-only violations on for the same gateway URL — included here for completeness in case it's relevant to the same root cause.Found a 'popover' attribute with an invalid valueconnect-src 'self'

Additional Notes

Screen recording of the full reproduction is available and can be attached to this ticket.
Issue is agent-specific: a newly created test agent in the same environment, by the same user, does not exhibit this behavior.
Suspect the affected agent has a broken or misconfigured connection/reference that the sharing flow depends on for its confirmation step.

Impact

Blocking rollout of an internal HR assistant agent to the team — unable to grant teammates access via Copilot Studio's native sharing.

msedge_KozZroGUHA...

Categories:

Publish & channel management

I have the same question (0)

All responses (4)

Answers (0)

Sort by

Suggested answer

Ashlesha-MSFT Microsoft Employee on at

Like
a
(0)

Report
Copy link

Link copied!
@JA-16071133-0 I was able to reproduce a variant of this issue on my end.

Repro confirmed: After adding a user with Viewer permission and clicking Share, the user persisted in the list — however the assigned permission was silently changed to Editor upon reloading the Share panel.

This suggests the bug has two variants:

Your case: User is silently dropped from the list entirely

My repro: User persists but permission level is silently overwritten/upgraded

Both point to the same root cause — the permission write is not being saved correctly and the UI does not reflect the actual persisted state.

I'm filing this with the engineering team now. Could you confirm — in your case, does the user disappear completely, or do they reappear with a different permission level?

Thanks for the detailed report — very helpful!

Was this reply helpful? Yes No
JA-16071133-0 2 on at

Like
a
(0)

Report
Copy link

Link copied!
Hi! To answer your question: in my case the user disappears completely from the list, they don't reappear with a different permission level.

I tested both scenarios to make sure:

Sharing as Viewer: user disappears from the list after reloading the panel.

Sharing as Editor: same result — disappears from the list.

So regardless of the permission level chosen, the end result is the same: the agent doesn't end up actually shared with the user — they can't access the agent afterward, and reopening the Share panel only shows the original owner.

So it does seem to be the same root cause you identified (the permission write isn't persisting correctly and the UI doesn't reflect the real state), just manifesting as a full removal in my case instead of a permission upgrade. Makes sense that these are variants of the same bug.

Let me know if you need any more info or another test from my side.

Was this reply helpful? Yes No
JA-22070751-0 2 on at

Like
a
(0)

Report
Copy link

Link copied!

Hi I'm getting the same issue, only the original owner can now access my agent. Issue started yesterday following an attempt to share agent, following this it completely removed permissions from all other users apart from original.

We have two separate agents, one created 6 months ago, and one created only a few days ago. The issue with permissions seems to only be affecting the older agent.

Was this reply helpful? Yes No
Suggested answer

AP-27071108-0 2 on at

Like
a
(0)

Report
Copy link

Link copied!

I had the same problem with Agent Shared with the entire organization. You cannot add editors anymore if that agent is shared with your org. You have to modify that setting to "No permissions, unless specified". That solved the problem for me.

Was this reply helpful? Yes No