I have reproduced the issue on the latest CLI version.
Yes, I am on the latest version
I have searched existing posts and this report is not a duplicate.
Yes, this isn’t a duplicate
In which of these areas are you experiencing a problem?
App
Expected behavior
shopify app dev --store example-store.myshopify.com connects to example-store.myshopify.com. Cached dev store values (.shopify/project.json, [build].dev_store_url in shopify.app.toml) resolve to the store with that exact domain. Archived stores are never selected.
Actual behavior
In an org (on the next-gen dev platform) with two dev stores where one .myshopify.com domain is a substring of the other — example-store.myshopify.com and turbo-example-store.myshopify.com — the CLI connects to turbo-example-store.myshopify.com even when --store example-store.myshopify.com is passed explicitly. It then persists the wrong domain back into .shopify/project.json and [build].dev_store_url, so the misresolution self-reinforces on every subsequent run. In my case the wrongly-selected store is even archived — archived stores are still returned by the search.
The only way to reach the intended store is --reset + interactive selection (the store picker is unaffected), but the very next plain shopify app dev resolves the now-cached exact domain through the same buggy lookup and reverts to the wrong store.
Root cause (verified against the CLI source, still present on main): AppManagementClient.storeByDomain in packages/app/src/cli/utilities/developer-platform-client/app-management-client.ts passes the domain to Business Platform accessibleShops as the free-text search: argument and returns stores[0] without checking for an exact domain match. search: is substring matching, so searching example-store.myshopify.com returns both stores, and the backend ranks turbo-example-store first. Suggested fix: stores.find((s) => s.shopDomain === normalizedDomain) ?? stores[0], and ideally exclude archived stores. The Partners client is not affected (its FindStoreByDomain query matches exactly); this only affects orgs migrated to the next-gen dev platform.
Reproduction steps
- In an org on the next-gen dev platform, have two dev stores where one domain is a substring of the other, e.g. example-store.myshopify.com and turbo-example-store.myshopify.com (the superstring store can even be archived).
- In an app project, run shopify app dev --store example-store.myshopify.com.
- The info banner reports Dev store: turbo-example-store.myshopify.com, and .shopify/project.json / [build].dev_store_url now contain the wrong domain.
(Which store wins depends on backend search ranking; in my org the superstring store consistently ranks first.)
Verbose output
2026-07-06T05:03:44.628Z: Sending "BusinessPlatform" GraphQL request:
query FetchDevStoreByDomain($domain: String) {
organization {
id
name
accessibleShops(
filters: {field: STORE_TYPE, operator: EQUALS, value: "app_development"}
search: $domain
) {
edges { node { id externalId name storeType primaryDomain shortName url __typename } __typename }
__typename
}
currentUser { organizationPermissions __typename }
__typename
}
}
With variables:
{
"domain": "example-store.myshopify.com"
}
to https://destinations.shopifysvc.com/organizations/api/unstable/organization/<org_id>/graphql
2026-07-06T05:03:44.849Z: Request completed in 221 ms
2026-07-06T05:03:44.850Z: Reading the content of file at .shopify/project.json...
2026-07-06T05:03:44.851Z: Writing some content to file at .shopify/project.json...
╭─ info ───────────────────────────────────────────────────────────────────────╮
│ Using shopify.app.test.toml for default values: │
│ • Org: <my org> │
│ • App: <my app> │
│ • Dev store: turbo-example-store.myshopify.com │
│ You can pass `--reset` to your command to reset your app configuration. │
╰──────────────────────────────────────────────────────────────────────────────╯
Operating system
macOS 26.5.2 (darwin-arm64), Node 22
CLI version
Reproduced on 3.88.1 and 4.3.0; the stores[0] logic is still present on main.