[BUG] Desktop Browser pane: auth handshake redirect chain back to http://localhost loops (ERR_TOO_MANY_REDIRECTS) — Clerk dev instances unusable on localhost

Preflight Checklist

• [x] I have searched existing issues. The closest are #91547 and #99047 (the pane denies Local Network Access) and #98551 (non-localhost names that resolve to loopback). None of them describes an auth handshake redirect loop on plain http://localhost.
• [x] This is a single bug report
• [x] I am using the latest version of the desktop app available to me

What's Wrong?

In the Claude Code desktop app's built-in browser (Browser pane), a Next.js app that uses a Clerk development instance cannot be opened on http://localhost:3000. Every top-level navigation fails with ERR_TOO_MANY_REDIRECTS, and the navigate tool reports navigation to http://localhost:3000 was denied or failed.

Clerk development instances do a "dev browser" handshake on the first page load. The flow is:

1. localhost redirects to https://<instance>.clerk.accounts.dev/v1/client/handshake.
2. Clerk redirects back to localhost with a token in the URL.
3. The app's middleware sets the token as a cookie on localhost.

In the pane this loop never completes. The token cookie is never stored on localhost, so every request starts the handshake again until Chromium stops it. Afterwards document.cookie on localhost holds no Clerk cookies.

The same URL works:

• in desktop Chrome 153, with the same app, server and Clerk instance;
• with curl -L, which follows the whole chain;
• in the same pane when the app is served from a public preview host (*.vercel.app) with the same Clerk development instance.

So the failure is specific to the pane plus a cross-site redirect chain that ends on localhost.

The same thing has happened on every attempt since about 2026-09-21. Before that, the same project's QA flows signed in through Clerk on localhost in the pane routinely.

Things that do work in the pane on localhost:

• top-level navigations that skip the auth middleware (e.g. /favicon.ico);
• same-origin fetch() from that page, which returns 200 with x-clerk-auth-reason: dev-browser-missing, because Clerk doesn't run the handshake for non-document requests.

Possibly related: in the pane, navigator.permissions.query({name: 'local-network-access'}) returns "denied". Chrome says Local Network Access does not apply to main-frame navigations, so I am not sure that is the cause. It is the same permission #91547 and #99047 run into.

What Should Happen?

A cross-site redirect chain that returns to http://localhost should behave as it does in Chrome: the Set-Cookie on the final localhost response is stored, and the next request carries it. Local development with hosted-auth providers that use redirect handshakes (Clerk dev instances; probably also Auth0, WorkOS and Supabase local setups) should work in the pane.

Error Messages/Logs

From ~/Library/Logs/Claude/main.log:

[warn] [PreviewContext] Load failed with no retry target {
  serverId: 'preview-local_…',
  tabId: 'seed',
  errorCode: -310,
  errorDescription: 'ERR_TOO_MANY_REDIRECTS'
}
[error] [Preview] navigatePreview failed {

Also seen once in the same session:

[warn] [PreviewContext] onBeforeRequest mainFrame from untracked webContents — blocking {
[warn] [PreviewContext] Load failed with no retry target { … errorDescription: 'ERR_BLOCKED_BY_CLIENT' }

Steps to Reproduce

1. Create a Next.js app with @clerk/nextjs and clerkMiddleware(), using a Clerk development instance (pk_test_…).
2. Run it on http://localhost:3000, and open it in the desktop app's Browser pane (via preview_start, or by navigating the pane to the URL).
3. Observe ERR_TOO_MANY_REDIRECTS in main.log, and the navigate tool reporting "denied or failed".
4. Open the same URL in desktop Chrome: it loads.
5. Deploy the same app to a public preview host and open it in the pane: it loads, and Clerk sign-in works.

Claude Model

Not model-specific.

Is this a regression?

Yes. It worked in earlier desktop versions; first seen about 2026-09-21.

Claude Code Version

Desktop app; the pane's user agent reports Claude/2.19675.0 Chrome/152.0.7977.130.

Platform

Anthropic API

Operating System

macOS 15.7.9

Terminal/Shell

Claude Code desktop app (Code tab), built-in browser

Additional Information

Versions: next 16.2.3, @clerk/nextjs 7.3.3.

Workaround: drive local auth flows in a separate CDP-attached Chrome, or validate on a deployed preview host.