Why Your Shopify Development Theme Keeps Disappearing

What actually happened to your theme

You spent Thursday building a new product page. You started the Shopify CLI, got a preview link, sent it to the client, and closed your laptop. Monday the client replies: "the link isn't working." You check the store and the theme is gone. No deletion in the activity log, no email, nothing.

Nothing broke. A development theme is a temporary, hidden theme the Shopify CLI creates so it has somewhere to render your local files. Shopify is explicit about the lifespan: development themes are deleted after seven days of inactivity, and they don't count toward your store's theme limit.

There's a second, faster way to lose one. Running shopify auth logout deletes your development theme immediately — day one, day six, doesn't matter. So does anything else that ends that CLI session's authentication, which is why this bites hardest on shared agency machines and any setup where auth gets recycled.

Why it's easy to miss

The failure is silent and delayed. Everything works at the moment you test it, and the link only dies once you've stopped paying attention. The gap between cause and symptom is usually a weekend — exactly long enough to have forgotten what you did.

The standard advice, and what it actually costs

Search this problem and you'll land on the same answer everywhere, including Shopify's own CLI documentation: push your development theme to an unpublished theme on the store. It works. The link stops expiring. And for agency work it quietly costs you two things worth more than the inconvenience it solves.

Cost one: your source becomes the client's to take

An unpublished theme shows up in Online Store › Themes in the merchant's admin, alongside the live theme. From there the store owner can duplicate it or download the theme files as a zip. That is a complete, working copy of your build — every section, every snippet, all your CSS — sitting in their account.

Most clients are honest and this never becomes a story. But you've moved the deliverable before the milestone. If a relationship sours mid-project, or a merchant decides to finish the build with someone cheaper, the leverage is already gone. Development themes are hidden from that list, which is the difference that matters here.

Cost two: it consumes a theme slot

Basic, Shopify and Advanced plans cap a store at 20 themes. Draft themes count. Development themes don't. Push a review theme every revision round and a busy store hits the ceiling fast — and the themes you're now forced to delete to make room are usually the merchant's own seasonal backups, which is a conversation nobody enjoys.

Keep it a development theme, make the session durable

Re-read the rule and the fix follows from it: the theme dies from inactivity, and it dies on logout. So don't change the kind of theme. Remove the two things that cause those events.

Theme Access passwords over interactive login

A Theme Access password is a per-store credential the CLI can use without opening a browser. Two things make it worth the setup: it survives the logout that would otherwise delete your theme, and it doesn't require a staff account on the client's store for every developer who touches the build.

[environments.default]
store = "your-store.myshopify.com"
password = "shptka_..."   # Theme Access password
theme = "123456789"

With that in place the CLI authenticates from config rather than a browser session, so there's no interactive login to expire and no logout event to take the theme with it.

Making a dev theme preview genuinely client-ready

A durable dev theme solves the expiry. It doesn't automatically make a good review experience, and this is where most DIY setups still fall over.

The three things clients actually trip on

1. Template context evaporates on navigation. You send a link to a new product template. The client clicks through to another product and lands on the old template, because the ?view= parameter didn't come along. They report the redesign as broken.
2. Shopify's own share-preview links are time-limited. They expire on Shopify's schedule, not your project's, which puts you back to reissuing links every round.
3. "Which pages am I reviewing?" A bare storefront link gives no indication of what changed. Clients either review nothing or review everything and comment on the parts you didn't touch.

Map templates to real URLs

The fix for the first two is to preview each template on the actual page it applies to, rather than relying on a query parameter surviving a click. Map product.bundle to a real bundle product's URL, page.lookbook to the real lookbook page, and hand over links that behave like the finished site — real products, real collections, real navigation.

# Preview one template on the page it actually applies to
https://your-store.myshopify.com/products/variety-pack?preview_theme_id=123456789&view=bundle

The fix for the third is a single link that lists what to look at — a short index of the templates in scope, each opening the right page on the dev theme. One URL for the whole project, stable across every revision round, instead of a fresh set of links each time.

When a draft theme really is the right call

Keeping review work on development themes doesn't mean never creating a draft theme. It means creating one deliberately, when the reason is real:

• You're about to go live. A draft theme is the staging step before publishing. It should exist for hours or days, not for the length of the project.
• The merchant needs to own it. Project's paid and closed, and the client should have the theme in their account. That's a handover, and it's supposed to put the code in their hands.
• Someone needs the theme editor. A merchant configuring sections themselves needs a theme that's visible in their admin.
• You're tracking what's already on the store. Live and draft themes that exist independently of your build are worth pulling into git so you can see what changed and when.

The distinction is ownership, not mechanics. A draft theme is a handover. Use it when handing over is what you mean.

It’s already gone. Now what?

Once Shopify has deleted a development theme there's no undelete. What you're recovering is the files, and that depends entirely on where they lived.

That last row is the expensive one. Theme editor changes live on the theme, not on your machine. If a client spent an afternoon configuring sections on a development theme and it expired before anything pulled those changes into your files, that work is gone with the theme.

How ThemeSync handles this

This is the problem ThemeSync was built around, so the workflow above is essentially what it automates:

• The dev server runs in the cloud, not on your laptop. The session stays up between working days, so the inactivity clock doesn't start ticking because you went home. Themes persist instead of auto-expiring.
• Non-interactive auth per store. Theme Access passwords are stored encrypted per store and written to the CLI config at run time, so there's no browser login to expire and no logout event to delete your theme.
• Your source stays in your repo. The theme renders on the client's real store with their real products, while the files live in your git branch — not as a downloadable theme in their admin.
• Template mapping produces real preview URLs. Each template is pinned to the actual product, collection or page it applies to, so navigation doesn't drop template context.
• One review link per theme. Clients get a portal listing the templates in scope, and it keeps working across revision rounds.
• Feedback lands on the page. Clients pin comments to the element they mean, and those come back to you attached to a page and viewport rather than described in an email.
• Draft and live themes stay available when you want them. Publishing, duplicating and tracking existing store themes in git are all still there — as deliberate actions, not as a workaround for expiry.

You can assemble all of this yourself with the Shopify CLI, a server that stays up and some discipline. The point of the tool is not having to hold it together on a Friday afternoon.

Takeaways

• Development themes are deleted after seven days of inactivity and immediately on logout. Documented behaviour, not a bug.
• The clock measures inactivity. A session that stays up doesn't expire — which makes this an infrastructure problem, not a theme problem.
• Pushing to a draft theme fixes expiry by listing a downloadable copy of your source in the client's admin and spending one of their 20 theme slots.
• Development themes are hidden from the store's theme list and don't count toward the limit. That's the property worth keeping.
• Use a Theme Access password so no logout event can take the theme with it.
• Map templates to real store URLs so preview links survive a click, and give clients one stable link rather than a new one each round.
• Create a draft theme when you mean to hand over — going live, or the merchant taking ownership.
• Back every theme with a git branch. Then expiry costs you a restart instead of a week.