Bug: WAM ApiContractViolation (2156265475) on Windows — workiq ask completely unusable after successful tenant enablement
Description
After successfully running Enable-WorkIQToolsForTenant.ps1 (all 11 MCP service principals created, admin consent granted and confirmed in Entra portal), workiq ask fails immediately on Windows with a WAM authentication error. The CLI is completely unusable on Windows despite a fully configured tenant.
Two issues are present:
-
WAM broker fails with ApiContractViolation on every invocation. The error occurs instantly before any browser prompt or login dialog appears. Environment variable MSAL_NET_DISABLE_WAM=true and MSAL_NET_DISABLE_WAM=1 have no effect — WAM is still invoked and fails identically. This affects all terminal types tested (PowerShell, Windows Terminal, plain cmd.exe, npx @microsoft/workiq@latest).
-
No fallback to browser auth on Windows. On Linux/macOS, MSAL falls back to browser-based interactive login when WAM is unavailable. On Windows, there is no fallback — the error is terminal with no recovery path available to the user.
Suspected root cause: The WAM broker redirect URI ms-appx-web://microsoft.aad.brokerplugin/ba081686-5d24-4bc6-a0d6-d034ecffed87 is not registered in the Work IQ CLI app registration. This is a Microsoft-owned multi-tenant app — end users and tenant admins cannot add this redirect URI themselves.
Steps to Reproduce
- Run
Enable-WorkIQToolsForTenant.ps1 as Global Admin — confirm all 11 service principals created successfully
- Confirm admin consent granted in Entra portal → Enterprise Applications → Work IQ CLI → Permissions (all 21 permissions show "Granted")
- Run
npm install -g @microsoft/workiq
- Run
workiq accept-eula
- Run
workiq ask -q "What are my upcoming meetings this week?"
- Observe: immediate WAM error, no browser prompt appears
Attempts to work around:
# Attempt 1 - env var (no effect)
$env:MSAL_NET_DISABLE_WAM = "true"
workiq ask -q "What are my upcoming meetings this week?"
# Result: same WAM error
# Attempt 2 - env var variant (no effect)
$env:MSAL_NET_DISABLE_WAM = "1"
workiq ask -q "What are my upcoming meetings this week?"
# Result: same WAM error
# Attempt 3 - npx latest (no effect)
$env:MSAL_NET_DISABLE_WAM = "true"
npx -y @microsoft/workiq@latest ask -q "What are my upcoming meetings this week?"
# Result: same WAM error
# Attempt 4 - plain cmd.exe (no effect)
workiq ask -q "What are my upcoming meetings this week?"
# Result: same WAM error
Error Output (exact, reproduced across all attempts)
Error: WAM Error
Error Code: 2156265475
Error Message: ApiContractViolation
WAM Error Message: (pii)
Internal Error Code: 557973634
See troubleshooting: https://aka.ms/msal-net-wam
Expected Behavior
- WAM redirect URI
ms-appx-web://microsoft.aad.brokerplugin/ba081686-5d24-4bc6-a0d6-d034ecffed87 should be registered in the Microsoft-owned app registration so WAM can authenticate on Windows
- If WAM fails, the CLI should fall back to browser-based interactive login (as it does on macOS/Linux)
MSAL_NET_DISABLE_WAM environment variable should be respected and documented as a supported workaround
Environment
| Property |
Value |
| WorkIQ version |
0.4.1.19742 |
| OS |
Windows 10.0.26200.8328 |
| Terminals tested |
PowerShell, Windows Terminal, cmd.exe |
| Node.js |
run node --version |
| M365 Copilot licence |
✅ Assigned |
| Admin consent |
✅ Granted via Enable-WorkIQToolsForTenant.ps1 |
| Entra permissions confirmed |
✅ 21 permissions, all show "Granted by administrator" |
| Service principals provisioned |
Work IQ Tools, Mail, Calendar, Teams, OneDrive, SharePoint, AdminTools, Word, M365Copilot, MeServer, Work IQ CLI (11 total) |
Bug: WAM ApiContractViolation (2156265475) on Windows — workiq ask completely unusable after successful tenant enablement
Description
After successfully running
Enable-WorkIQToolsForTenant.ps1(all 11 MCP service principals created, admin consent granted and confirmed in Entra portal),workiq askfails immediately on Windows with a WAM authentication error. The CLI is completely unusable on Windows despite a fully configured tenant.Two issues are present:
WAM broker fails with ApiContractViolation on every invocation. The error occurs instantly before any browser prompt or login dialog appears. Environment variable
MSAL_NET_DISABLE_WAM=trueandMSAL_NET_DISABLE_WAM=1have no effect — WAM is still invoked and fails identically. This affects all terminal types tested (PowerShell, Windows Terminal, plaincmd.exe,npx @microsoft/workiq@latest).No fallback to browser auth on Windows. On Linux/macOS, MSAL falls back to browser-based interactive login when WAM is unavailable. On Windows, there is no fallback — the error is terminal with no recovery path available to the user.
Suspected root cause: The WAM broker redirect URI
ms-appx-web://microsoft.aad.brokerplugin/ba081686-5d24-4bc6-a0d6-d034ecffed87is not registered in the Work IQ CLI app registration. This is a Microsoft-owned multi-tenant app — end users and tenant admins cannot add this redirect URI themselves.Steps to Reproduce
Enable-WorkIQToolsForTenant.ps1as Global Admin — confirm all 11 service principals created successfullynpm install -g @microsoft/workiqworkiq accept-eulaworkiq ask -q "What are my upcoming meetings this week?"Attempts to work around:
Error Output (exact, reproduced across all attempts)
Error: WAM Error
Error Code: 2156265475
Error Message: ApiContractViolation
WAM Error Message: (pii)
Internal Error Code: 557973634
See troubleshooting: https://aka.ms/msal-net-wam
Expected Behavior
ms-appx-web://microsoft.aad.brokerplugin/ba081686-5d24-4bc6-a0d6-d034ecffed87should be registered in the Microsoft-owned app registration so WAM can authenticate on WindowsMSAL_NET_DISABLE_WAMenvironment variable should be respected and documented as a supported workaroundEnvironment
0.4.1.19742cmd.exenode --versionEnable-WorkIQToolsForTenant.ps1