Hydrogen 2026.4.5 Fixes Two Bugs That Log Your Customers Out. One Sat Open For 194 Days.

One Hydrogen merchant tracked what shoppers did after a Customer Account login failure. Of the affected shoppers on that storefront, 40% left. The other 60% tried Sign in again.

Those numbers describe one merchant's storefront, not a Shopify benchmark or an industry-wide abandonment rate. They do, however, show the customer impact behind an authentication error: shoppers were trying to access their accounts, and the storefront stopped them.

The failure happened when Hydrogen's OAuth state no longer matched the state returned during the login callback. The shopper could already be authenticated with Shopify, yet the storefront would end the flow with Bad request: Unauthorized instead of recovering.

Hydrogen 2026.4.5 fixes two Customer Account failure paths: stale OAuth state during login, and session loss during access-token refresh.

The patch does not change Hydrogen's public authentication API. It changes how Hydrogen responds when authentication goes wrong.

If your storefront uses Shopify Customer Accounts, check whether its login flow can encounter the same conditions: a browser-context change, concurrent login attempts, custom account routes, or a temporary token-endpoint failure.

Why Hydrogen login could fail when OAuth state went stale

Hydrogen's Customer Account login uses OAuth. When sign-in begins, Hydrogen creates a state value and stores information about the transaction in the shopper's session.

When Shopify returns the shopper to the storefront, Hydrogen checks whether the state in the callback matches the stored transaction.

The problem begins when the callback reaches a browser context that no longer has the original session state.

The merchant who opened issue #3403 documented two reproducible paths.

The first starts inside an app WebView, with Instagram given as the common example:

1. A shopper opens the storefront inside the Instagram WebView.
2. They click Sign in.
3. Shopify's Customer Account login opens.
4. The shopper chooses Open in browser and finishes authentication in Safari or Chrome.
5. The OAuth callback returns to a browser with a different cookie jar.

The OAuth state was created in the WebView's session. The system browser does not have that same session, so Hydrogen cannot find the expected state. Authentication ends with Bad request: Unauthorized.

The shopper may already be authenticated with Shopify. The storefront simply cannot match the callback to the transaction that began in the WebView.

The second path does not require a WebView.

A shopper can open the Sign in link in two tabs. Each login attempt generates state in the session. If the second attempt replaces that state, then the callback from the first tab returns with an older value.

Hydrogen then receives a valid callback that it cannot validate against the current transaction.

Both browser behaviors produce the same underlying condition: the OAuth callback reaches Hydrogen with state that no longer matches what the storefront has stored.

Customizations do not make a storefront vulnerable to the bug by default, but they add more places where the standard recovery path can be interrupted. Routes with custom redirects, locale handling, analytics, middleware, return URLs, or additional session logic deserve particular attention.

How Hydrogen 2026.4.5 recovers a stale login

PR #3856 changes what happens when OAuth state is missing or stale.

Instead of ending the login immediately, Hydrogen can start one fresh OAuth transaction.

This recovery is useful because the shopper may already be authenticated with Shopify. In that case, the new transaction can complete without requiring another email address or one-time code.

The retry is deliberately limited to one attempt. Hydrogen carries a recovery marker through the OAuth state, allowing it to recognize that recovery has already been attempted. If the browser still cannot retain the required session, the next callback stops instead of creating an endless redirect loop.

The patch also preserves existing customer and buyer session data when the invalid callback occurs.

For storefronts that use Hydrogen's standard account routes, the package contains the recovery behavior. Customized login routes require an additional check: the recovery request must reach customerAccount.login() directly.

Upgrading the dependency is therefore only part of the fix for customized storefronts. Teams that copied Hydrogen's login route into their codebase should compare it with the current implementation, especially if the route has changed since it was copied.

The same audit should cover the storefront's Shopify Customer Account implementation, including any account components or custom logic built around the login route.

PR #3856 also changes OAuth state generation to use 256 bits of cryptographically secure randomness. This is an implementation change included in the patch. It should not be described as a security vulnerability, exploit, CVE, or security advisory.

Why a temporary token refresh failure could log a customer out

The second fix in Hydrogen 2026.4.5 applies after the customer has signed in.

Customer Account access tokens expire. When that happens, Hydrogen uses the stored refresh token to request a new access token.

Before the patch, a failed refresh could clear the customer session even when the refresh token itself was still usable.

Issue #3892 reproduces the behavior against Hydrogen 2026.4.4. The reproduction expires the current access token, forces the Customer Account token endpoint to return a 500, and then visits an authenticated account route.

Before the fix, the customer ends up logged out.

From the shopper's perspective, this does not look like a token-refresh problem:

I was signed in. I opened my account. Now I have to sign in again.

A failed refresh request does not automatically mean the refresh token is invalid. The endpoint may return a temporary 500, the request may fail at the network layer, or Shopify may respond with 429 because of rate limiting. OAuth can also return errors related to application configuration rather than the customer's credentials.

Clearing the session in all those cases turns a temporary infrastructure problem into a persistent customer problem. Even after the endpoint recovers, the shopper must authenticate again because the storefront has already discarded the credentials it could have retried.

PR #3916 narrows that behavior.

Hydrogen now clears the customer session when:

• The refresh token is missing from the session.
• The OAuth response contains invalid_grant.

For network failures, 5xx, 429, and other OAuth errors, Hydrogen keeps the stored tokens so a later request can try again.

The current request may still treat the customer as unauthenticated. The important difference is that Hydrogen no longer destroys credentials that may work once the underlying failure clears.

Why invalid_grant matters more than the HTTP status

It may seem reasonable to classify a 400 response as permanent and a 500 response as temporary. OAuth token refresh requires a more precise distinction.

The implementation notes for PR #3916 describe terminal refresh-token conditions that can return HTTP 400 with invalid_grant, including unknown, revoked, or expired tokens.

Retrying the same refresh token will not resolve those conditions. The token must be discarded, and the customer must authenticate again.

Other OAuth errors mean something different:

• invalid_client and unauthorized_client indicate application configuration problems, not proof that the customer's refresh token is dead.
• 429 indicates rate limiting.
• Network errors and 5xx responses may disappear on a later request.

Hydrogen therefore looks at the OAuth error instead of deciding whether to clear the session from HTTP status alone.

Hydrogen does not retry every authentication failure. It now distinguishes a failed refresh request from a refresh token that can no longer be used.

The Hydrogen OAuth issue remained open for 194 days

The merchant report for the OAuth state problem, issue #3403, was opened on January 23, 2026. It documented both the WebView-to-browser and stale multi-tab reproductions, along with the merchant's 40% abandonment observation.

A community pull request, #3600, was opened on March 18, 2026. It was closed unmerged as inactive on May 27, 2026.

Shopify's PR #3856 implemented one-attempt recovery with additional session handling and loop protection. That fix was merged on August 4, 2026.

From January 23 through August 4, inclusive, the issue spans 194 calendar days.

The second issue moved faster. Issue #3892, covering session loss during transient token-refresh failures, was opened on July 31, 2026 against 2026.4.4. PR #3916 was merged on August 5, 2026.

Both fixes belong to the 2026.4.5 patch line. They are fixes, not a breaking Customer Account migration or a new authentication API.

What to test after upgrading to Hydrogen 2026.4.5

If your storefront does not use Shopify Customer Accounts, these two fixes are unlikely to affect the customer journey directly.

If it does, focus on three areas.

1. Upgrade and test the failure paths

Upgrade to Hydrogen 2026.4.5 through your normal dependency and regression-testing process.

Teams moving from an earlier release line should review the broader Hydrogen 2026.4 changes separately. Those release-level migration concerns are distinct from the two patches covered here.

For Customer Accounts, test more than a clean desktop sign-in:

• Complete a normal login.
• Begin login in an in-app browser, then continue in Safari or Chrome.
• Start two login attempts and complete the older callback last.
• Visit an authenticated account route after access-token expiry.
• Simulate a temporary refresh failure such as 500 or 429.
• Confirm that an invalid refresh token still requires sign-in again.

These cases cover the behavior that actually changed in 2026.4.5.

2. Audit custom login routes

If your team replaced or wrapped Hydrogen's standard login route, compare it with the current implementation after upgrading.

The recovery introduced in PR #3856 depends on the recovery request reaching customerAccount.login() directly. Pay particular attention to routes that add:

• Custom redirects
• Locale handling
• Analytics
• Return URLs
• Middleware
• Additional session logic

A package upgrade cannot correct behavior that a custom route no longer inherits from Hydrogen.

If the storefront still carries older account code, include any remaining legacy Customer Account migration work in the same audit. Mixing old and current authentication flows makes session behavior harder to understand and test.

3. Track authentication as a customer-journey event

Issue #3403 is useful because the merchant did more than record the exception. They tracked what shoppers did after it.

That is how they learned that 40% of affected shoppers on their storefront left while the other 60% attempted Sign in again.

Apply the same approach to your own Customer Account flow. Useful events may include:

• Failed login callbacks
• OAuth recovery attempts
• Unexpected session loss
• Repeated Sign in actions
• The customer's next meaningful action after an authentication failure

Do not send OAuth codes, access tokens, refresh tokens, state values, or customer PII to the analytics system.

An exception tells you that authentication failed. Customer-journey instrumentation tells you whether the failure interrupted someone who was trying to continue through the storefront.

What Hydrogen 2026.4.5 changes in production

Hydrogen 2026.4.5 introduces no new Customer Account API. It gives production storefronts safer behavior in two failure scenarios: one bounded recovery for stale OAuth state and session preservation after a transient token-refresh failure.

Teams still need to test custom routes, expired-token behavior, and in-app browser transitions. Those checks belong alongside dependency updates and observability in the maintenance cycle for a production Hydrogen storefront.

At Weaverse, we do not remove the need to maintain the Hydrogen runtime beneath a storefront. Our role is to reduce the operational work above that layer, allowing developers to retain control without rebuilding every content and merchandising workflow from scratch.

Sources

• Shopify Hydrogen GitHub: Hydrogen 2026.4.5 release
• Shopify Hydrogen GitHub: OAuth recovery PR #3856
• Shopify Hydrogen GitHub: Merchant report issue #3403
• Shopify Hydrogen GitHub: Token refresh PR #3916
• Shopify Hydrogen GitHub: Token refresh issue #3892
• Shopify Hydrogen GitHub: Community PR #3600
• GitHub: Public reproduction repository