I run a custom Remix app (@shopify/shopify-app-remix) that serves customer-specific pages via App Proxy (authenticate.public.appProxy()), gated on the logged_in_customer_id query param Shopify appends to proxied requests.
Symptom: A subset of logged-in customers report: they log in successfully using standard email/password login, but the very next action — visiting an App Proxy route, or even Shopify’s own native checkout — redirects them back to login. We cannot reproduce this internally; the same customer accounts work fine in our own testing.
We’ve since added a fallback identity mechanism (a signed token passed via URL, verified server-side) for our own App Proxy routes to work around this — but this obviously cannot help native Shopify checkout, since that flow isn’t routed through our app at all and relies entirely on Shopify’s own customer session cookie.
The fact that checkout also fails to recognize these users as logged in (not just our App Proxy routes) suggests the underlying customer session cookie itself may be getting dropped client-side, not just the logged_in_customer_id param failing to populate on our specific requests.
Questions:
Is there a known root cause for logged_in_customer_id intermittently not populating on App Proxy requests, beyond the “New Customer Accounts” issue referenced in older threads? Does it matter whether the store uses Classic vs. New customer accounts?
Is there a way to detect, server-side, whether the customer’s session cookie is actually still valid vs. genuinely expired, given App Proxy strips the Cookie header from proxied requests? Any officially supported alternative to relying solely on logged_in_customer_id?
Are there known triggers (specific browsers, in-app browsers/webviews, ITP-style cookie policies) Shopify has identified for premature session loss affecting both App Proxy identification and checkout login state simultaneously?
Any guidance — official docs, known issues, or workarounds — would help us narrow down whether this is fixable on our end or a platform-side reliability issue worth filing a bug report for.
The password detail in your post is doing more work than you think. New customer accounts is passwordless, customers get a one time six digit code by email and the help docs say straight out that a password isn’t required to sign in. Only legacy accounts take an email and a password. So if your affected customers are genuinely typing a password, you are on legacy, and all three threads you linked are about the New customer accounts flow. Different auth stack, probably not your bug.
On question 2 there is something better than guessing and it is already in the package you are using. authenticate.public.appProxy() hands you a liquid helper. Return the response with Content-Type application/liquid and Shopify renders that body in the context of the shop using the shop’s theme, after your app has answered. So a {{ customer.id }} in there reflects the session Shopify sees on that request rather than what got forwarded to you. Log the two values side by side. Blank logged_in_customer_id with a populated customer id means the param delivery is the broken part. Both blank means the session really is gone, and checkout bouncing them is the same event rather than a second mystery. The customer object on proxy pages has been empty as a bug before, so fire one known good logged in request first and prove the probe works before you trust a blank from it.
The checkout half is the more interesting half anyway. Nothing in checkout routes through your app, so if checkout also thinks they are logged out then app proxy is not the layer failing. Cheap thing to add to your logging is the Referer host on every request where the param comes back blank. Cookies are scoped per host, so a Markets country redirect, or someone bouncing between www and the apex, or a customer still sitting on the myshopify domain, all produce this exact shape. Logged in on one host, stranger on the next, and intermittent from where you sit because it depends which link they clicked.
One note on the fallback token. Legacy customer accounts were deprecated on 26 February 2026 and Shopify said the final sunset date gets announced later this year. So anything you build around legacy sessions has a clock running on it.
When the blank ones land, do they cluster on a particular host or referrer, or are they spread evenly across your traffic?
The host-scoping answer above is right about the cause. I would go one step further on the fix, because chasing the cookie will not fully close this.
logged_in_customer_id is a convenience, not an authentication signal. Shopify appends it when it happens to know who the buyer is at proxy time, and there are several ordinary ways for it to not know: a Markets country redirect, an apex-to-www hop, a Safari or in-app browser dropping the cookie, or the buyer arriving from an email link in a webview. Your app then sees a blank and cannot distinguish “logged out” from “logged in but the parameter did not survive the trip”.
The durable fix is to stop deriving identity from the request and start carrying it yourself. Issue your own short-lived signed token when you do know who the buyer is, keep it in the app context on the storefront, and send it with the proxy call. The proxy signature still proves the request came from Shopify for that shop; your token proves which customer. When the parameter is present you can cross-check the two and log mismatches, which is also how you find out how often this is really happening.
Two things worth doing while you are in there. Treat a missing value as unknown rather than as logged out, so you degrade to a read-only or guest view instead of bouncing someone to login. And log the referring host on proxy hits, because if the reply above is right you will see the failures cluster on one host immediately.
On the legacy accounts point: that deprecation makes this more urgent rather than less, since anything you build on the old cookie behaviour has a deadline on it.
I build Listify, a registry app that runs its shopper hub through an app proxy, and moving identity onto a signed token of our own is the change that made this class of bug stop appearing in support.