Yeah, I think it’s the only way for now, but not the best for me. I work with Vite and SCSS/TS. I have to build it almost every time I want to see a preview.
As an update, there is now a new CLI release as of 5 hours ago. I was running 3.94.3 and have now upgraded.
I deleted any cache, node_modules etc. upgraded to the latest version 4.0.0 and have not had any issues as of using it. I will come back here if I do face any further issues but for now upgrading to the latest release has solved any 429 and 403 errors I was previously facing.
Upgrading did not do it for me, still getting hit with 403 for AJAX Cart API consistently and 401 when using Section Rendering API.
App development using the command:
shopify app dev
--theme-app-extension-port=<custom-port>
--tunnel-url=<custom-tunnel>
I’m getting 403’s (using 4.0.0) when hitting any cart endpoints now too - the “–password” workaround that previously worked with the 429s does not do the trick. So this is completely blocking me right now.
Edit: 401 on /cart.js, 403 on /cart/add.js or /cart/change.js
For anyone seeing 403 errors, can you check if those shops are making calls to the cart/clear.js endpoint often?
@Paige-Shopify definitely not the case here. AFAIK not hitting that endpoint at all. Even when not touching the cart endpoints for half a day… the moment I do, I get a 401 or 403. When I tested just now using a standard theme’s remove item from cart… hitting /cart/change.js… I also get for example 401 on /apps/widget/setting and 403 on /shopify_pay/accelerated_checkout showing in the CLI console. Not doing anything exotic or excessive here. Just normal cart actions, not at any high intervals.
Unlike the previous issues, I don’t get completely blocked and unable to access the store. But I effectively cannot work on any cart-related features. Which is a big problem.
If I can be of assistance with e.g. logs… let me know where to send them please.
I was previously getting 429 and 403 errors but now I’m getting 401 errors on customer login and other auth-related routes when running my theme locally (e.g. http://127.0.0.1:9292/account/login). Production works.
-
Shopify CLI version:
4.0.0 -
Network header:
www-authenticate: Bearer realm="…", error="invalid_token", error_description="The access token provided is expired, revoked, malformed, or invalid for other reasons."
This indicates the Shopify CLI dev proxy is forwarding an invalid/expired bearer token to Shopify, and Shopify (served via Cloudflare) is rejecting the request. Cloudflare is the edge that returns the response, but the root cause is the invalid token being sent from the dev proxy/tooling, not Cloudflare itself.
What’s weird is that this only started happening in the last few days, and I’ve changed nothing on my end during that time. so I can only assume some changes have been made elsewhere. I really need someone to investigate this.
Please have some patient and avoid tagging so many Shopify staff members. It hasn’t even been 24 hours since your last post.
401s are unrelated to 403s and 429s. We expect they should be a transient issue which could be fixed by restarting your session. We have an idea to investigate to fix this bug which we need time to prioritize
403s vs 429s
We did ship the fix for 429’s and expected improvement. The 403’s may have started due to an entirely separate incident that happened this week. Good news is - A fix is incoming for 403s.
We have an investigation on going into more long term and resilient improvements. We will have an update next week.
Alright not related to 429’s but after a whole week and a half of running into issues with auth endpoints on 127.0.0.1:9292… I have finally managed to eliminate 401 errors on customer login and other auth-related routes and I can now continue doing my job.
What I’ve found:
Shopify versions 4.0.0+ throw 401 errors on any auth-related action such as login, create account etc.
The error:
www-authenticate: Bearer realm="…", error="invalid_token", error_description="The access token provided is expired, revoked, malformed, or invalid for other reasons."
The fix:
Rollback to version 3.87.4 and it should start working fine again.
See this thread where a similar issue is talked about, this time, regarding cart actions (not resolved yet either since Jan 27th)
Hello everyone,
We’d like to share an update on rate limiting in the CLI.
CLI version 4.4.0 introduces new signatures for local theme development. When you run shopify theme dev, the CLI now attaches specific headers to the requests it sends to your storefront. This gives storefront a clear signal that the traffic is legitimate CLI activity, so it’s less likely to be flagged as bot-like and rate limited.
This works when you use the default auth method (email/password). It does not yet apply when authenticating with the --password flag (a Theme Access app password). Support for that is still to come. If the signature can’t be retrieved for any reason, theme dev continues to work as normal.
Thanks for your patience while we worked through this.
We will be looking for specific feedback around these changes. If you encounter an error around the signature being created, or you are still getting rate limited, cloudflare managed checks, 429’s, please post with a request ID so we can investigate.
Thanks!
Hi there, am on CLI 4.7.0 and now getting 429’s; this is the latest version. Please advise.
Hey Mark, we’ll need a lot more information than that. Do you have request IDs? What command are you running? Do you see it on every request? etc. Help us help you.
Hey Gray-Shopify, thank you for replying.
On VPN, on the Cart AJAX API.
What I’m doing: browsing the live store in Microsoft Edge on Windows. Add to bag / change qty / remove a line. The failing calls are:
POST /cart/changeGET /cart.jsonGET /cart.json?vsly=t(Visually)
Every request? Once it starts, yes. Cart writes and idle cart reads all 429. It is not one burst then recovery.
Request IDs: Shopify x-request-id is often missing because Cloudflare returns the 429. When headers are present:
POST /cart/change → 429
Date: Wed, 02 Sep 2026 14:54:06 GMT
Cf-Ray: a34d5918fa5b4133-LHR
Cf-Mitigated: challenge
Server: cloudflare
Content-Type: text/html; charset=UTF-8
No x-request-id
Earlier same session:
POST /cart/change → 429
Date: Wed, 02 Sep 2026 14:48:17 GMT
Cf-Ray: 834d44dc9b32771f-LHR
Server: cloudflare
On later 429s Edge shows Response headers (0) + “Provisional headers are shown” — the connection is dropped before Shopify can stamp an ID.
Does that help you to help me please? Thank you!
Thanks for the information! Cart-related throttling is unrelated to this thread. Please check out Aggressive bot detection with 429 errors AJAX Cart API
And that’s great information!