HI @Vektori1,
This looks more like a Teams app provisioning/catalog synchronization issue than a Copilot Studio publishing failure.
The fact that:
- the agent publishes successfully,
- the Teams installation link opens,
- the correct agent name/icon are displayed,
- and the failure happens specifically when clicking Add
is a useful distinction. The agent itself appears to be published, but the Teams installation transaction is failing.
Microsoft's current Copilot Studio documentation confirms that the installation link is the supported way to share an agent with users, and that users must have access to the agent before they can install it. It also requires the tenant to allow Power Platform apps to be added to Teams.
I would troubleshoot it in this order.
1. Check the Teams app in Teams Admin Center
Ask the Teams administrator to go to:
Teams admin center → Teams apps → Manage apps
Search for the agent and check:
- App status — Allowed
- Whether the app is blocked by an app permission policy
- Whether the user is covered by a policy that restricts Power Platform apps
- Whether the app is available to the affected user
- Whether there are multiple/stale entries for the same agent
Microsoft specifically states that organizations must allow Power Platform apps to be added to Teams for users to install Copilot Studio agents directly or find them under Built with Power Platform.
2. Try the documented Teams-side refresh
There is actually a Microsoft-documented workaround for cases where Teams continues using an older published configuration.
In Teams admin center:
Manage apps
↓
Find the agent
↓
Disable
↓
Wait briefly
↓
Enable again
Then in Copilot Studio:
Channels
↓
Microsoft Teams / Microsoft 365
↓
Turn the channel off
↓
Save
↓
Turn the channel back on
↓
Publish again
Microsoft documents this sequence for a SystemError caused by Teams retaining a previously published version of the agent.
There is also a recent Microsoft Q&A report describing a very similar Teams Add → error after republishing scenario, where the Teams app package/manifest was out of sync with the newly published agent.
3. I would not immediately remove/recreate everything
Removing and re-adding the Teams channel is supported, but I would use it as the next step rather than the first one.
Microsoft documents that you can:
Remove channel → Disconnect → Add channel again → Publish
and explicitly says that reconnecting the Teams channel is supported. If the agent is still installed when you reconnect it, Teams can show Update now instead of Add.
So I wouldn't expect channel recreation by itself to create an intentional duplicate app. However, if the tenant already has an app/catalog entry that is stale, I'd clean that up through the Teams admin side rather than repeatedly creating/removing channels.
4. Check the user's actual access
You mentioned the agent is shared with one individual user.
That's important because Microsoft's documentation states that only users who can access the agent can use the installation link.
For a clean test, temporarily verify that:
Agent access
↓
Affected user explicitly shared
↓
User signs into Teams with same account
↓
Installation link opened in Teams web
If the same user can see the correct installation dialog but Add still fails, that makes an access/permission problem less likely and strengthens the Teams app provisioning hypothesis.
What I would do in this case
Given the symptoms, my sequence would be:
Copilot Studio
↓
Confirm published agent
↓
Confirm user has access
↓
Teams Admin Center → Manage apps
↓
Check Allowed / policies / stale entry
↓
Disable app
↓
Re-enable app
↓
Turn Teams channel off/on in Copilot Studio
↓
Republish
↓
Retry installation link
I would not assume that the teams.microsoft.com/l/app/... link itself is broken. The fact that it resolves the correct agent metadata suggests that Teams can locate the app; the failure is occurring later in the installation/provisioning transaction.
If the same error remains after the Admin Center refresh, I'd capture the failed Add request from Teams and raise it with Microsoft, providing the Agent ID/App ID, Environment ID, tenant ID, timestamp, Teams client (web/desktop), and the Teams Admin Center app status.
So yes, disabling/re-enabling the app in Teams Admin Center is a reasonable supported troubleshooting step, and I'd try that before completely recreating the channel. Microsoft has documented essentially this refresh pattern for stale Teams agent configuration.
