[Bug] WAM ApiContractViolation (2156265475) on Windows — workiq ask completely unusable after successful tenant enablement

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:

1. 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).

2. 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

1. Run Enable-WorkIQToolsForTenant.ps1 as Global Admin — confirm all 11 service principals created successfully
2. Confirm admin consent granted in Entra portal → Enterprise Applications → Work IQ CLI → Permissions (all 21 permissions show "Granted")
3. Run npm install -g @microsoft/workiq
4. Run workiq accept-eula
5. Run workiq ask -q "What are my upcoming meetings this week?"
6. 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

Start by reproducing the failure with Enable-WorkIQToolsForTenant.ps1 and the documented workiq ask commands on Windows, checking the exact WAM error and MSAL_NET_DISABLE_WAM behavior. Trace the Windows authentication entry point and compare it with the browser-login behavior on macOS/Linux. Done means WAM authenticates, or a browser fallback works when WAM is unavailable, with the workaround documented if supported.