This check guards against an attacker who tries to make a fake transfer and then changes strategy at the same time, which would be an attempt to get around WAF rules and Captcha rules that exclude transfers. We already guard against this on the backend on both sign in and sign up, but in the SDK we were only checking it on sign up. So I took this opportunity to also add the check on sign in.

⚠️ Potential issue | 🟡 Minor

Potential null reference when accessing signUp properties during transfer.

Line 186 uses optional chaining on client? but not on the subsequent property chain. If client exists but signUp, verifications, or externalAccount is null/undefined, this will throw a TypeError.

     if (params.transfer && this.shouldBypassCaptchaForAttempt(params)) {
-      const strategy = SignIn.clerk.client?.signUp.verifications.externalAccount.strategy;
+      const strategy = SignIn.clerk.client?.signUp?.verifications?.externalAccount?.strategy;
       if (strategy) {

In `@packages/clerk-js/src/core/resources/SignIn.ts` around lines 185 - 192, The
code accesses nested properties on SignIn.clerk.client without guarding
signUp/verifications/externalAccount; change the retrieval of strategy in the
SignIn transfer branch to use safe checks (e.g. optional chaining or explicit
null checks) so you do const strategy =
SignIn.clerk.client?.signUp?.verifications?.externalAccount?.strategy and only
assign (finalParams as TransferParams).strategy = strategy as
TransferParams['strategy'] if strategy is not undefined/null; update the logic
inside the transfer block (related to shouldBypassCaptchaForAttempt and
finalParams assignment) to avoid any potential TypeError from missing
intermediate objects.

If it's a sign in and a transfer and there's no signup or verification or externalaccount, that would be an error.

@dmoerner, thank you for the clarification. You're right—in this transfer flow context, if those nested properties are missing, that would indicate a legitimate error state that should surface rather than be silently handled. The current implementation with optional chaining only on client is appropriate here.

⚠️ Potential issue | 🟡 Minor

Same null reference risk in the transfer branch.

Line 625 accesses signUp.verifications.externalAccount.strategy without optional chaining. This could throw if the signUp state is incomplete during a transfer scenario.

     if (
       params.transfer &&
       captchaOauthBypass.some(
         // eslint-disable-next-line `@typescript-eslint/no-non-null-assertion`
-        strategy => strategy === SignIn.clerk.client!.signUp.verifications.externalAccount.strategy,
+        strategy => strategy === SignIn.clerk.client?.signUp?.verifications?.externalAccount?.strategy,
       )
     ) {

In `@packages/clerk-js/src/core/resources/SignIn.ts` around lines 621 - 629, The
transfer branch accesses
SignIn.clerk.client!.signUp.verifications.externalAccount.strategy directly
which can throw if signUp/verifications/externalAccount is undefined; update the
condition inside the captchaOauthBypass check to use optional chaining (e.g.,
SignIn.clerk.client?.signUp?.verifications?.externalAccount?.strategy) and
compare safely (guarding null/undefined) so the predicate returns false when the
nested property is missing, ensuring the transfer path doesn't cause a runtime
error.

As in the other case, a transfer with a sign up that's incomplete in the sense of missing an external account is an error.

@dmoerner, understood. If the external account is expected to exist during transfer scenarios, the assertion is appropriate to catch that error early. Thanks for the clarification.