Summary
shopify theme dev works on the very first page load, but as soon as any local file is saved (which triggers the CLI's automatic upload + hot reload), every subsequent navigator request is multiplied into 6 internal CLI requests to the same URL, all returning HTTP 200, ~1 second apart, then the CLI crashes with:
Theme ID mismatch: expected <dev_theme_id> but got <live_theme_id>.
The mismatch always reports the live theme (role: main) being served instead of the development theme created by theme dev.
Environment
|
|
| CLI version |
@shopify/cli@3.94.3 |
| Node |
v25.5.0 |
| OS |
Windows 11 (PowerShell 7.4) |
| Shop |
Standard Shopify plan, public store |
| Apps that hook the request lifecycle |
WeTracked Connect (App Proxy /apps/wt-connect-pixel), ElevateAB (storefront A/B testing) |
Steps to reproduce
shopify theme dev --store=<store>.myshopify.com- Open
http://127.0.0.1:9292/ in a browser → first request loads correctly.
- Save any file in the theme (e.g. add a space to
layout/theme.liquid).
- The browser hot-reloads. The CLI logs immediately show 6 GET requests to the same URL, ~1 s apart, then crash:
• 01:43:40 Request » GET 200 / 553ms
• 01:43:41 Request » GET 200 / 354ms
• 01:43:42 Request » GET 200 / 265ms
• 01:43:44 Request » GET 200 / 499ms
• 01:43:45 Request » GET 200 / 658ms
• 01:43:46 Request » GET 200 / 272ms
╭─ error ──
│ Theme ID mismatch: expected 195225911683 but got 187828208003.
│ Request ID: 40fe9f80-0d40-4569-8771-f8723a4105c7-1778179426
The "6 retries on a single nav request" pattern is consistent across reproductions: 1 navigator request → 6 internal CLI fetches of the same URL, all 200 OK, then the mismatch crash. This happens on every URL, not specific to alternate templates.
What I have tried (none fix the issue)
- Updated CLI to latest (
3.94.3).
--live-reload=off, --live-reload=full-page.--theme=<id> explicit on theme dev.- Downgrading CLI to
3.80.x.
shopify auth logout + clearing %USERPROFILE%\AppData\Local\shopify-cli-nodejs + re-login.- Deleting and recreating the development theme (got a fresh ID, same bug).
- Using a fresh navigator profile (private window, all cookies cleared).
- Disabling the Web Pixel for WeTracked at the shop level.
- Intercepting WeTracked App Proxy fetches (
/apps/wt-connect-pixel/*) at the theme level via a theme.role != 'main' JS hook in <head> (so they never reach the network).
- Disabling the ElevateAB redirect snippet on non-main themes.
After a fresh login, the dev server works for one page load, then the bug returns on the very next request following a file save.
Request IDs (for upstream investigation)
f4c637bf-63ac-431a-b776-d9d4594f38be-177818039940fe9f80-0d40-4569-8771-f8723a4105c7-1778179426228d3bf1-3df9-4ff5-a985-3f8a1a4dea23-1778165507
Likely cause
The upload step on hot reload appears to invalidate the _shopify_essential cookie (or the upstream session that maps preview_theme_id to the dev theme). Subsequent retry attempts by the CLI never re-establish the dev-theme context — they get the live theme back from upstream instead. The 1 nav request → 6 CLI fetches multiplier suggests an internal retry loop on the mismatch detection that does not converge.
A confounding factor is that this shop has WeTracked installed (App Proxy responses on /apps/wt-connect-pixel/* set cookies). However, blocking those App Proxy responses entirely at the theme level (via fetch/XHR/sendBeacon hooks gated on theme.role != 'main') does not fix the bug. The mismatch still occurs after the first hot-reload upload, even when no wt-connect-pixel request reaches the network.
Related issues
Workaround currently in use
Switched from theme dev to a custom PowerShell FileSystemWatcher + theme push --only=<file> script with debouncing. This bypasses the proxy entirely and is stable, at the cost of losing hot-reload (manual F5 needed).
Summary
shopify theme devworks on the very first page load, but as soon as any local file is saved (which triggers the CLI's automatic upload + hot reload), every subsequent navigator request is multiplied into 6 internal CLI requests to the same URL, all returning HTTP 200, ~1 second apart, then the CLI crashes with:The mismatch always reports the live theme (
role: main) being served instead of the development theme created bytheme dev.Environment
@shopify/cli@3.94.3/apps/wt-connect-pixel), ElevateAB (storefront A/B testing)Steps to reproduce
shopify theme dev --store=<store>.myshopify.comhttp://127.0.0.1:9292/in a browser → first request loads correctly.layout/theme.liquid).The "6 retries on a single nav request" pattern is consistent across reproductions: 1 navigator request → 6 internal CLI fetches of the same URL, all 200 OK, then the mismatch crash. This happens on every URL, not specific to alternate templates.
What I have tried (none fix the issue)
3.94.3).--live-reload=off,--live-reload=full-page.--theme=<id>explicit ontheme dev.3.80.x.shopify auth logout+ clearing%USERPROFILE%\AppData\Local\shopify-cli-nodejs+ re-login./apps/wt-connect-pixel/*) at the theme level via atheme.role != 'main'JS hook in<head>(so they never reach the network).After a fresh login, the dev server works for one page load, then the bug returns on the very next request following a file save.
Request IDs (for upstream investigation)
f4c637bf-63ac-431a-b776-d9d4594f38be-177818039940fe9f80-0d40-4569-8771-f8723a4105c7-1778179426228d3bf1-3df9-4ff5-a985-3f8a1a4dea23-1778165507Likely cause
The upload step on hot reload appears to invalidate the
_shopify_essentialcookie (or the upstream session that mapspreview_theme_idto the dev theme). Subsequent retry attempts by the CLI never re-establish the dev-theme context — they get the live theme back from upstream instead. The1 nav request → 6 CLI fetchesmultiplier suggests an internal retry loop on the mismatch detection that does not converge.A confounding factor is that this shop has WeTracked installed (App Proxy responses on
/apps/wt-connect-pixel/*set cookies). However, blocking those App Proxy responses entirely at the theme level (via fetch/XHR/sendBeacon hooks gated ontheme.role != 'main') does not fix the bug. The mismatch still occurs after the first hot-reload upload, even when nowt-connect-pixelrequest reaches the network.Related issues
Response body should not be disturbed or locked— observed on the same shop, separately)Workaround currently in use
Switched from
theme devto a custom PowerShellFileSystemWatcher+theme push --only=<file>script with debouncing. This bypasses the proxy entirely and is stable, at the cost of losing hot-reload (manual F5 needed).