Fix store auth scope parsing for space-separated input

[RyanDJLee]

Summary

Fixes shopify store auth failing with "Shopify granted fewer scopes than were requested" when scope input arrives space-separated instead of comma-separated.

• parseStoreAuthScopes split on commas only, but space-separated input (e.g. "read_products read_inventory") was treated as a single unrecognized scope
• The server-side parser (Access::ScopeSet.parse_scopes) handles both delimiters via /[ ,]/ — the CLI parser now matches that behavior

Root cause

A partner's CLI invocation delivered space-separated scopes to parseStoreAuthScopes. The exact shell-level cause is unknown — possibly typed without commas, or a script/wrapper issue. The CLI's .split(',') produced ["read_products read_inventory"] (one element). The server parsed both formats correctly and returned scope: "read_products,read_inventory". The CLI then failed validation because the single requested scope "read_products read_inventory" wasn't in the granted set {"read_products", "read_inventory"}.

Confirmed via partner verbose logs showing with scopes read_products read_inventory (no comma in scopes.join(',') output, proving a single-element array).

Slack thread: https://shopify.slack.com/archives/C07UJ7UNMTK/p1776085829940879

Changes

• scopes.ts: .split(',') → .split(/[ ,]+/) to handle both comma and space delimiters, matching the server-side regex
• Removed dead .trim() — splitting on /[ ,]+/ cannot produce elements with leading/trailing whitespace
• scopes.test.ts: new tests covering space-separated input, mixed delimiters, and space-separated granted scopes through resolveGrantedScopes

Test plan

• Existing comma-separated test still passes (no regressions)
• New test parseStoreAuthScopes splits space-separated scopes fails before fix, passes after
• All 70 tests across 9 auth test files pass
• Manual: shopify store auth --scopes read_products,read_inventory on Windows PowerShell

[RyanDJLee]

• Fix store auth scope parsing for space-separated input #7258 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[Copilot]

Pull request overview

Updates the CLI’s store auth scope parsing to handle Windows PowerShell’s space-separated argument transformation, preventing false “granted fewer scopes” failures after OAuth.

Changes:

• Update parseStoreAuthScopes to split scopes on both whitespace and commas.
• Add unit tests for space-separated and mixed-delimiter scope inputs.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
packages/cli/src/cli/services/store/auth/scopes.ts	Broadens scope parsing to accept space- and comma-delimited input.
packages/cli/src/cli/services/store/auth/scopes.test.ts	Adds coverage for new parsing behavior and related grant-resolution scenarios.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[dmerand]

One thing I’d still like covered before merge: this was a shell/input-boundary bug, but the new tests stay at the scopes.ts helper level.

The original failure path was broader: authenticateStoreWithApp(...) parsed space-separated requested scopes, built the PKCE auth request, and later compared requested vs granted scopes and threw "Shopify granted fewer scopes than were requested."

Could we either:

1. add a service-level regression in packages/cli/src/cli/services/store/auth/index.test.ts with input like scopes: 'read_products read_inventory' and a token response like scope: 'read_products,read_inventory', asserting the flow succeeds (and ideally that the auth URL/session scopes normalize correctly), or
2. check off the manual Windows PowerShell repro in the test plan?

I think either would give us a much stronger cross-OS confidence story than helper tests alone.

[github-actions]

Differences in type declarations

We detected differences in the type declarations generated by Typescript for this branch compared to the baseline ('main' branch). Please, review them to ensure they are backward-compatible. Here are some important things to keep in mind:

• Some seemingly private modules might be re-exported through public modules.
• If the branch is behind main you might see odd diffs, rebase main into this branch.

New type declarations

We found no new type declarations in this PR

Existing type declarations

packages/cli-kit/dist/public/node/node-package-manager.d.ts

@@ -68,6 +68,10 @@ export declare function packageManagerFromUserAgent(env?: NodeJS.ProcessEnv): Pa
  * @returns The dependency manager
  */
 export declare function getPackageManager(fromDirectory: string): Promise<PackageManager>;
+export declare function packageManagerBinaryCommandForDirectory(directory: string, binary: string, ...args: string[]): Promise<{
+    command: string;
+    args: string[];
+}>;
 interface InstallNPMDependenciesRecursivelyOptions {
     /**
      * The dependency manager to use to install the dependencies.

[dmerand]

/snapit

[github-actions]

🫰✨ Thanks @dmerand! Your snapshot has been published to npm.

Test the snapshot by installing your package globally:

npm i -g --@shopify:registry=https://registry.npmjs.org @shopify/cli@0.0.0-snapshot-20260413182601

Caution

After installing, validate the version by running shopify version in your terminal.
If the versions don't match, you might have multiple global instances installed.
Use which shopify to find out which one you are running and uninstall it.