productivity:ms365: OAuth fails with AADSTS900971 (No reply address provided) after sign-in

[dhruv-raithatha]

Summary

Connecting the productivity:ms365 plugin via Claude Code's /mcp command consistently fails Microsoft sign-in with AADSTS900971: No reply address provided. The error appears after credentials are accepted, not at the initial /authorize step — which is diagnostic of a server-side app-registration misconfiguration rather than a malformed request.

Plugin: productivity:ms365 (hosted MCP at microsoft365.mcp.claude.com)

Reproduction

1. Run /mcp in Claude Code and start the OAuth flow for productivity:ms365.
2. Open the authorize URL returned by the plugin in a fresh browser session (private/incognito window, no prior MS session).
3. Sign in with a valid Microsoft work account.
4. Microsoft displays:

   Sorry, but we're having trouble signing you in.

   AADSTS900971: No reply address provided.

5. The browser never reaches the http://localhost:<port>/callback redirect.

Evidence the request is well-formed

The /authorize URL emitted by the plugin contains a well-formed redirect_uri query parameter:

redirect_uri=http%3A%2F%2Flocalhost%3A50902%2Fcallback

Other observed parameters in the request:

Param	Value
client_id	08ad6f98-a4f8-4635-bb8d-f1a3044760f0
response_type	code
code_challenge_method	S256 (PKCE — public-client flow)
scope	api://07c030f6-5743-41b7-ba00-0a6e85f37c17/.default offline_access openid email
prompt	consent

Why this points server-side, not request-side

• The flow advances through /common/oauth2/v2.0/authorize → /common/SAS/ProcessAuth → error. If redirect_uri were truly missing from the request, AAD would error at /authorize rather than after credential entry.
• Reproduces in a clean incognito window with no prior SSO state — rules out stale-cookie / SSO-chain causes.
• Reproduces across multiple retries with fresh authorize URLs.

Likely root cause

The Azure AD app registration 08ad6f98-a4f8-4635-bb8d-f1a3044760f0 appears to have its http://localhost/... reply URL listed under the wrong platform type (probably Web), while the OAuth request is being made as a public client (PKCE, no secret). AAD won't match a Web-platform reply URL against a public-client request, and reports the failure as "no reply address provided."

Suggested fix

On the app registration 08ad6f98-a4f8-4635-bb8d-f1a3044760f0, under Authentication:

• Add a platform of type Mobile and desktop applications and register http://localhost (AAD wildcards the port for http://localhost under that platform type for public clients), or
• Mark the existing platform as a public client / allow public-client flows, depending on the intended trust model.

AADSTS900971 is documented as raised when the app registration has no reply URL configured for the inferred client type, even when one is present in the request.

Related

• legal:ms365 plugin/mcp authentication error #24 — a separate but adjacent bug in legal:ms365 (duplicate prompt parameter). Different symptom, different error, but suggests the M365 plugin family's OAuth URL construction / app-reg setup may benefit from a once-over.