Teams interop: all meeting chat operations return 403 Forbidden for ACS users since ~Aug 24 2026 (calls work; Teams web anonymous can chat in same meeting)
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 20/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Active
- Tech stack
- azure
- Domain
- cloud
Research direction
No repository file or test is identified; start by reproducing the failure with the listed ACS package versions, CallWithChatComposite, and the documented POST endpoint. Compare ACS behavior with an anonymous Teams web participant, then use the Azure support case and linked cross-post to determine whether a repository change is possible; done requires a confirmed resolution or maintainer guidance on ownership.
Written by the indexing model from the issue text.
Description
Describe the bug; what happened?
Since approximately Aug 24, 2026, every ACS (anonymous interop) user joining Microsoft Teams meetings in our tenant receives 403 Forbidden on ALL meeting chat operations — ChatThreadClient.sendMessage and sendTypingNotification both fail with:
CommunicationError: {
"Code": "Forbidden",
"Message": "The initiator doesn't have the permission to perform the requested operation."
}
— and the user receives no incoming thread messages. Calling, roster, screen share, and reactions all work normally. The CallWithChatComposite shows "You are no longer in this chat thread" immediately after joining. No changes were made on our side (no deploys, no tenant/policy changes).
Key discriminator: in the SAME meeting, an anonymous participant joining via the Teams web client (display name only, unverified — no email OTP) can send meeting chat messages normally. The failure exists only on the ACS interop path.
What are the steps to reproduce the issue?
- Create a Teams meeting (either via Graph app-created
onlineMeetingsor by a human organizer in the Teams desktop app with default options — both reproduce). - Mint an ACS identity + token (
voip,chatscopes) and join the meeting withcreateAzureCommunicationCallWithChatAdapter+CallWithChatComposite(minimal quickstart, no custom code). - Wait for call state
Connected(fully admitted). - Send a chat message.
Result: POST /chat/threads/19%3Ameeting_...%40thread.v2/messages returns 403 (on both api-version=2024-06-05-preview and 2025-03-15).
What behavior did you expect?
ACS interop users can send/receive meeting chat while in the call, per the documented Teams external-user capabilities.
If applicable, provide screenshots:
Sample failing request: Ms-Cv: IGMF4wkAI0+MIaxuFQ0kJw.0, 2026-08-31 16:04:38 UTC, resource in Canada region. Happy to share more Ms-Cv values and a live repro meeting privately.
In what environment did you see the issue?
@azure/communication-react: 1.32.0@azure/communication-calling: 1.42.1@azure/communication-chat: 1.6.0-beta.7- OS & Device: Windows 11 PC (also reproduced tenant-wide across devices/users in production)
- Browser: Google Chrome (latest); production users on multiple browsers
Is there any additional information?
Tenant configuration verified as Global Admin, all permissive:
MeetingChatEnabledType = Enabledon ALLCsTeamsMeetingPolicyinstances- ACS federation configured:
EnableAcsUsers = True, resource immutable ID present inAllowedAcsResources EnableAcsFederationAccess = Trueon all external access policiesBlockedAnonymousJoinClientTypesemptyEnableExternalAccessRestrictionsForChatParticipants/EnableMutualFederationForChatParticipantsboth False- per-meeting
allowMeetingChat = enabled
A test policy with AnonymousUserAuthenticationMethod = None assigned to the organizer did not help (a fresh meeting created after assignment still fails). This is NOT the known join-timing issue — the failure persists for the entire meeting while Connected.
A Severity-A Azure support case is open in parallel. Also posted on Microsoft Q&A: https://learn.microsoft.com/en-us/answers/questions/5990218/
Cross-posted with full details on the UI library repo: https://github.com/Azure/communication-ui-library/issues/6074 (filed there first; posting here as this appears to be a service-side issue in the ACS↔Teams interop chat gateway rather than an SDK/UI defect).
- Dominant language
- No language data
- Stars
- 339
- Forks
- 113
- Avg merge
- 36m
- Merged PRs (30d)
- 1
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Azure/Communication
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Azure/Communication#599 · 4 comments · 1 reaction ·
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
Azure/Communication#598 ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
Azure/Communication#543 ·
-
Needs: triage :mag:
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Azure/Communication#447 ·
-
Needs: triage :mag:
Difficulty 4/5 3-5 days Newbie friendliness 25/100
Azure/Communication#440 · 4 comments ·
All issues in Azure/Communication
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
documentation needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
hashicorp/terraform-provider-aws#50256 · 1 comment ·
Maintainers usually reply within 1 day
-
api: storage priority: p2 type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
googleapis/google-cloud-cpp#16529 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
anomalyco/models.dev#8658 ·
Maintainers usually reply within 1 day