Cookie multiplying eventually kills server with header too large code 431

[Aavora-MT]

Describe the bug
After upgrading from v0.5.0 and also v0.6.0 to v0.7.0 an error occurs that creates a new cookie on each page navigation. The cookies have the same starting prefix but then end with a unique hash.

e.g. wos-auth-verifier-5eec94bb, wos-auth-verifier-904414d8, wos-auth-verifier-ad9fd491

After browsing round enough pages (approx a dozen or so, it varies from time to time) the server starts returning 431 error codes with the message the request header fields are too large.

To Reproduce
Install the v0.7.0 package, sign in to your application and start navigating between application pages, after a while when the cookies reach a tipping point the server will reject the requests.

Expected behavior
A new cookie should not be added on each page request

Screenshots

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser Chrome
• authkit-tanstack-start version 0.7.0
• TanStack Start version 1.167

Additional context
It's unclear if this is going to be fixed by the PR that is already open for #72 so I thought best to raise it as a separate bug.

[brandonfancher]

Cursor 2.5 FTW! It tracked down this bug in no time! Here's the dl...courtesy of AI:

Confirmation

Reproducible on @workos/authkit-tanstack-react-start@0.8.2. This looks like an integration antipattern made worse by per-flow PKCE cookies in @workos/authkit-session 0.5.x.

Root cause

getSignInUrl() and getSignUpUrl() don't just return URLs — each call starts a new OAuth flow and sets a wos-auth-verifier-<hash> cookie (~10 min TTL).

Before 0.5.x, repeated calls mostly overwrote one cookie. Now each call adds a new one. Enough refreshes/navigations → cookie header bloat → HTTP 431.

Likely trigger

The Convex TanStack Start AuthKit guide recommends prefetching auth URLs in loaders:

loader: async () => {
  const { user } = await getAuth();
  const signInUrl = await getSignInUrl();  // ❌ new cookie every load
  const signUpUrl = await getSignUpUrl();  // ❌ new cookie every load
  return { user, signInUrl, signUpUrl };
},

That's the pattern I followed. The Next.js section on the same page avoids this by using dedicated redirect routes instead.

Safe vs unsafe

Call	In loaders?	On user click?
getAuth()	✅	✅
getSignInUrl() / getSignUpUrl()	❌	✅

Fix

Don't prefetch auth URLs in loaders. Start OAuth only on user action:

• Client handlers: call getSignInUrl() / getSignUpUrl() from a button onPress, then window.location.assign(url)
• Redirect routes: /api/auth/sign-in and /api/auth/sign-up GET handlers that redirect — link to them from the UI, don't call them from loaders

Suggested follow-ups

1. Update the Convex TanStack Start example to stop prefetching auth URLs in loaders
2. Add a WorkOS doc warning that these helpers must not run in beforeLoad/loaders

[gjtorikian]

@Aavora-MT if you're able to verify that that ☝️ fixes the issue for you we can get it documented + try to add warnings.

[Aavora-MT]

@Aavora-MT if you're able to verify that that ☝️ fixes the issue for you we can get it documented + try to add warnings.

Sure I will test the fix this afternoon and feed back

[Aavora-MT]

I've just attempted to replicate after upgrading package from 0.6.0 to 0.8.2 and not changed the getSignInUrl implementation yet but it's now working and not re-creating the cookie. Even with the getSignInUrl being called in a beforeLoad

export const Route = createFileRoute("/_authenticated")({
  beforeLoad: async ({ location }) => {
    const auth = await getAuth();
    if (!auth.user) {
      const href = await getSignInUrl({
        data: { returnPathname: location.pathname },
      });

      throw redirect({ href });
    }
    return { auth };
  },
  component: AuthenticatedLayout,
});

[brandonfancher]

For me, even in 0.8.2, it was definitely the fact I was calling getSignInUrl() in the route's beforeLoad. But I didn't have it within a if (!auth.user) check. I was running it even with a signed-in user. And it caused the cookie pile-up.

[gjtorikian]

@brandonfancher I believe it, and thanks for the Cursor output. We got a few options here:

1. Have authkitMiddleware scan incoming cookies for wos-auth-verifier-* entries and emit delete Set-Cookie headers for all of them on every non-callback request. Stale verifiers get "garbage collected" on the next request instead of waiting for TTL.
2. Document the pattern (e.g. make it explicit that getSignInUrl() should NOT be called in route loaders for display)
3. Rewrite getSignInUrl to return URLs without setting cookies. The cookie is set only when the user navigates; the example app's /api/auth/sign-in route already does this manually

I feel like 1 is dangerous, and 2, users of this project might not see; but I'm not sure if 3 has unseen consequences...

[Aavora-MT]

I've re-tested today on 0.8.3 and still not able to recreate this.