clerk-js@6.10.1: signUp.sso() POSTs to /v1/client/sign_ups (collection URL) instead of /v1/client/sign_ups/{id} after signUp.create({strategy:'ticket'}) → 405

[jeevanpillay]

Preliminary Checks

• I have reviewed the documentation: https://clerk.com/docs
• I have searched for existing issues: https://github.com/clerk/javascript/issues
• I have not already reached out to Clerk support via email or Discord
• This issue is not a question, general help request, or anything other than a bug report directly related to Clerk.

Reproduction

https://github.com/jeevanpillay/clerk-bug-repros — see /bug1 route and README.md for end-to-end steps.

Publishable key

pk_test_Y2hhcm1lZC1zaGFyay01Mi5jbGVyay5hY2NvdW50cy5kZXYk

Description

After signUp.create({ strategy: 'ticket', ticket, legalAccepted: true }) resolves successfully, calling signUp.sso({ strategy, redirectCallbackUrl, redirectUrl, legalAccepted: true }) on the same Future-API resource issues POST /v1/client/sign_ups?...&_method=PATCH (the collection URL) instead of PATCH /v1/client/sign_ups/{id} (the resource URL). FAPI returns 405 Method Not Allowed.

The Future API surface returns no error to the caller: the promise resolves with { error: undefined }, no IdP redirect happens, and any UI state tied to "set loading=false on error" never fires — the OAuth button is left in a disabled/spinning state indefinitely.

Same family of bug as the documented signIn.create({ strategy: 'ticket' }) Future-API-proxy / underlying-client state mismatch — but on the signUp side, surfacing at .sso() rather than at .create().

Steps to reproduce:

1. Clone https://github.com/jeevanpillay/clerk-bug-repros and follow Setup in the README (point at any dev Clerk tenant).
2. pnpm mint-invitation <email> — prints Bug 1 URL.
3. Visit http://localhost:3000/bug1?__clerk_ticket=<jwt>.
4. Open DevTools → Network. Filter sign_ups.
5. Click Reproduce Bug 1.

Expected behavior:

signUp.sso() issues PATCH /v1/client/sign_ups/{id} (resource URL), threading the in-flight signUp's id into the path. Followed by a 302 to the IdP.

Actual behavior:

POST /v1/client/sign_ups?__clerk_api_version=2025-11-10&_clerk_js_version=6.10.1                    → 200
POST /v1/client/sign_ups?__clerk_api_version=2025-11-10&_clerk_js_version=6.10.1&_method=PATCH      → 405

The second POST hits the collection URL with _method=PATCH in the query string. Clerk's FAPI only accepts PATCH on /v1/client/sign_ups/{id}, so it 405s. Client-side: signUp.sso() returns no error, no redirect happens.

Also reproduced via:

• signUp.ticket({ ticket, legalAccepted: true }) then signUp.sso({...}) — same 405.
• signUp.sso({ strategy, ticket, ... }) alone with no prior .create — same 405.

Hypothesis: signUp.sso() is not threading the in-flight Future-API resource's id into the URL construction. The Future-API proxy still references an empty signUp state at URL-build time, even though clerk.client.signUp has the resource ID populated.

Workaround applied in the affected production app: drop to legacy clerk.client.signUp.authenticateWithRedirect({ ..., continueSignUp: true, legalAccepted: true }), which correctly sends PATCH /v1/client/sign_ups/{id} and completes the IdP redirect. Caveat: that legacy codepath surfaces a separate bfcache-related state-corruption bug — filed separately.

Environment

  System:
    OS: macOS 26.3
    CPU: (14) arm64 Apple M3 Max
    Memory: 1.20 GB / 36.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.22.0
    npm: 10.9.4
    pnpm: 10.28.2
  Browsers:
    Brave Browser: 148.1.90.122
    Chrome: 148.0.7778.97
    Safari: 26.3
  npmPackages:
    @clerk/nextjs: 7.3.3 => 7.3.3
    next: 16.1.6 => 16.1.6
    react: 19.2.5 => 19.2.5
    react-dom: 19.2.5 => 19.2.5

clerk-js version forced to 6.10.1 at runtime via NEXT_PUBLIC_CLERK_JS_VERSION=6.10.1. window.Clerk.version === "6.10.1" confirmed in browser. Also originally reproduced at 6.8.0 (the tenant's default CDN-pinned version). Identical behavior at both versions — changelog gap between 6.8.0 → 6.10.1 reviewed, no relevant changes.

Tested across Chromium 148 + WebKit (Safari 26.3) — browser-agnostic; this is an SDK URL-construction bug.