Environment

Summary

POST /account/login submitted to the local theme dev server (127.0.0.1:9292) fails at the CLI proxy with a 502 Bad Gateway, before the request reaches Shopify. This blocks any local automated flow (Playwright, WebdriverIO, curl) that needs a real customer session — the login form itself is unusable.

Looks like a possible regression of the (closed) #3963 which stated "It should work now no matter the version".

Error output

```
Failed to proxy request to /account/login with status 502 (Bad Gateway).
URL: https://.myshopify.com/account/login?_fd=0&pb=0

TypeError: fetch failed
at Object.processResponse (node:internal/deps/undici/undici:12793:20)
at node:internal/deps/undici/undici:13181:23
at process.processTicksAndRejections (node:internal/process/task_queues:104:5)
at node:internal/deps/undici/undici:17409:7
at process.processTicksAndRejections (node:internal/process/task_queues:104:5)
at async Object.handler (file:///.../@shopify/cli/dist/chunk-Q7BOSHWX.js:7:6357)
at async Server. (file:///.../@shopify/cli/dist/chunk-Q7BOSHWX.js:7:9903)
```

Repro

1. `shopify theme dev --store --theme --store-password `
2. From any HTTP client: `POST http://127.0.0.1:9292/account/login\` with the standard storefront login form fields.
3. The CLI logs the 502 above; the client sees a 502 response.

What we've tried

• Both Playwright's `page.request.post` and real form submission via a browser navigation. Both fail identically — the failure is at the proxy, not the client.
• Downgrading to `@shopify/[email protected]`: this specific 502 does not occur, but the CLI then crashes with the (also known-broken) "Theme ID mismatch" bug during theme sync, so login can't complete for other reasons.
• Bypass attempt: POST direct to the primary storefront domain and transplant the resulting `_shopify_essential` cookie onto `127.0.0.1`. Theme dev issues a new `_shopify_essential` on every proxied response and overwrites the injected value, so the logged-in session never reaches Shopify.

Impact

Any team running functional/end-to-end tests against `theme dev` that need a real customer session cannot do so today. The workaround suggested in similar older threads — pushing to a real dev theme and hitting the preview URL — is unworkable at CI scale for stores that hit the theme cap.

Ask

Whether the proxy's `fetch failed` path is a known/tracked regression, or if there's a supported configuration we're missing to keep POST → cross-domain-redirect flows working through 4.6.0.