Claude for Excel Extension - "Couldn't start sign-in" Error - Pro Subscription

[bahodurusmonov]

PROBLEM:
Cannot sign into Claude for Excel extension.
Error: "Couldn't start sign-in. Please try again."

IMPORTANT DETAILS:
✓ Subscription: PRO (Active)
✓ Device: Windows 11 + Excel 2021
✓ Browser: Chrome/Edge/Firefox
✓ claude.ai: Works perfectly
✓ Excel extension: Fails completely

TROUBLESHOOTING COMPLETED:
✓ Cleared cache, cookies, socket files
✓ Disabled other extensions
✓ Tried multiple browsers and devices
✓ Signed out completely from claude.ai
✓ Tried Incognito/Private mode
✓ Uninstalled and reinstalled extension
✓ Restarted computer multiple times
✓ Verified same email on both accounts
✓ No organizational restrictions

ATTEMPTS TO RESOLVE:
✓ Fin AI bot: No resolution
✓ Help Center troubleshooting: No solution
✓ Support ticket submitted: Awaiting response (ID: 215474566329072)
✓ All documented solutions: Failed

QUESTION:
Has anyone experienced this issue?
Is there a known workaround or solution?
Could this be a server-side issue?

Any help appreciated!

[santicalderon]

This looks like an OAuth flow issue specific to the Office Add-in runtime, not a general SDK problem. The "couldn't start sign-in" error typically occurs when the embedded WebView (Edge WebView2 on Windows 11) can't complete the redirect callback from claude.ai.

Key technical detail: Office Add-ins use a sandboxed WebView that may block third-party cookies or require specific redirect URI registration. The Anthropic OAuth flow for add-ins likely uses a custom URI scheme (e.g., claude-office://) or a callback URL that must be whitelisted on the Anthropic side. If the redirect URI doesn't match exactly (including trailing slashes, protocol), the token exchange fails silently and the WebView shows a generic sign-in error.

Check these:

• Open DevTools in the WebView (if you can) by running Excel with --debug-webview flag. Look for redirect_uri_mismatch or access_denied in network logs.
• Ensure your system's default browser is Chrome/Edge and that claude.ai is allowed to open external protocols (Windows Settings > Apps > Default Apps > Choose default applications by protocol).
• Clear credentials specifically for the add-in identity (not just browser): cmdkey /list and remove any related Anthropic entries. Or use Credential Manager > Windows Credentials.

If useful, kernel has an honest analysis of Anthropic's authentication patterns at [URL]. It covers OAuth redirect handling in non-browser contexts, which is directly relevant to this add-in failure.

Also verify with Anthropic support whether the Excel add-in requires a separate application registration or if the Pro subscription covers add-in usage — there may be a hidden quota or scope limit not visible on the plan page.

_{I help maintain kernel — happy to share more if useful.}

[zinovevvv]

Root cause identified via JS bundle analysis

I was able to reproduce this on macOS + Word and traced the exact failure point.

The add-in uses the OAuth 2.0 Device Authorization Grant flow. On sign-in, it POSTs to:

https://claude.ai/v1/oauth/device_authorization

That endpoint is currently behind a Cloudflare managed challenge — it returns an HTML bot-protection page instead of the expected JSON with device_code / verification_uri.

You can reproduce with a plain curl:

curl -s https://claude.ai/v1/oauth/device_authorization   -X POST -H "Content-Type: application/json"   -d '{"client_id":"claude-office","scope":"openid"}'

Response: Cloudflare "Just a moment..." HTML page — not JSON.

The Office add-in WebView cannot pass a Cloudflare JS challenge (no real browser fingerprint/cookies), so the request fails silently and the add-in shows "Couldn't start sign-in."

Fix needed on Anthropic's side: exclude /v1/oauth/device_authorization from Cloudflare's managed challenge. The Device Authorization flow is specifically designed for non-browser clients — blocking it with a browser-only challenge defeats its purpose.

Affects Word, Excel, PowerPoint add-ins on both Mac and Windows. VPN is not a factor — the Cloudflare block happens regardless of IP.

[OC-Drecht]

I had Claude summarize my troubleshooting:

Additional diagnostic data — root cause appears to be a Cloudflare managed challenge on the device-authorization endpoint
Reproducing the same "Couldn't start sign-in. Please try again." failure on Claude for Excel (Windows desktop, current build, WebView2 runtime 149.0.4022.80). Did a full network-layer workup; sharing it since it points at a specific cause.
The add-in's sign-in calls POST https://claude.ai/v1/oauth/device_authorization and receives an HTTP 403 with Cf-Mitigated: challenge — i.e. Cloudflare is serving a managed bot-challenge interstitial ("Just a moment…" / "Enable JavaScript and cookies to continue") instead of letting the device-authorization request through. The browser console additionally reports CORS errors against this endpoint, but those are downstream of the 403 (the challenge response carries no ACAO header); the 403 is the primary event.
Key response headers from a direct request to the endpoint:
HTTP/1.1 403 Forbidden
Cf-Mitigated: challenge
Server: cloudflare
Content-Type: text/html; charset=UTF-8
CF-RAY: a10cd983fddc0d15-SLC
set-cookie: __cf_bm=...; SameSite=None; Secure; Domain=claude.ai
Two captured ray IDs (Salt Lake City edge): a10cd983fddc0d15-SLC and a10cdf7a59fd96f5-SLC.
What this explains:

Intermittent "fails then works on retry": the first attempt is challenged and sets a __cf_bm clearance cookie; a quick retry sometimes rides that cookie through. It's inconsistent because WebView2 doesn't reliably retain/replay the cookie, and __cf_bm is short-lived (~30 min).
Cross-network reports: this is not IP-reputation-specific to one site. Tested egress from two separate ISPs and both received the same managed challenge, consistent with the widespread reports here and in the Marketplace reviews.
Why a full browser works but the pane doesn't: a real browser executes the challenge JS and passes transparently; the add-in's WebView2 client passes it inconsistently and stalls on "Couldn't start sign-in."

Ruled out as causes: client firewall (packet/flow traces show the requests permitted and completing, no drops), egress IP reputation (both ISP egresses challenged identically), Office add-in cache (%LOCALAPPDATA%\Microsoft\Office\16.0\Wef cleared), Edge/WebView2 third-party-cookie policy (none set), and WebView2 runtime version (current).
Suggested fix: the Cloudflare managed-challenge rule fronting /v1/oauth/device_authorization appears too aggressive for the add-in's own WebView2 client. Allowlisting the add-in's device-authorization flow (or lowering the challenge action to a transparent JS challenge the WebView2 control can reliably solve) would resolve this. The two ray IDs above should let the team pull the exact challenge decisions from Cloudflare logs.

[msubhieng75-max]