Fix autoupgrade incorrectly treating pnpm shopify (from CLI repo) as global

[alfonso-noriega]

WHY are these changes introduced?

When running pnpm shopify from the CLI repo itself, autoupgrade incorrectly fires as if the CLI were globally installed. This causes contributors to see unexpected upgrade attempts during local development.

Root cause: currentProcessIsGlobal() in is-global.ts searches upward from the working directory for a shopify.app.toml or hydrogen.config.{js,ts} to identify a local project. The CLI repo has neither, so getProjectDir() returns undefined — and the previous code immediately returned true (global) without checking whether the binary itself is inside the repo.

WHAT is this pull request doing?

Adds a getWorkspaceRoot() helper that walks up from cwd() looking for a pnpm-workspace.yaml. When no app/hydrogen project is found, currentProcessIsGlobal() now falls back to checking whether argv[1] (the binary) lives inside that workspace root before concluding the process is global.

If the binary is within the workspace, the process is correctly identified as local and autoupgrade is skipped.

How to test your changes?

1. From the root of the CLI repo, run any command: pnpm shopify version
2. Enable autoupgrade first if needed: pnpm shopify upgrade → opt in
3. Confirm no upgrade attempt is made after the command completes

You can also force the autoupgrade check with:

SHOPIFY_CLI_FORCE_AUTO_UPGRADE=1 pnpm shopify version

Before this fix: upgrade runs (treats the process as global).
After this fix: upgrade is skipped (correctly identified as local).

Checklist

• I've considered possible cross-platform impacts (Mac, Linux, Windows)
• I've considered possible documentation changes
• I've considered analytics changes to measure impact
• The change is user-facing, so I've added a changelog entry with pnpm changeset add

[alfonso-noriega]

• Fix autoupgrade incorrectly treating pnpm shopify (from CLI repo) as global #7313 👈 (View in Graphite)
• main

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

[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/is-global.d.ts

@@ -30,6 +30,14 @@ export declare function installGlobalCLIPrompt(): Promise<InstallGlobalCLIPrompt
  * @returns The package manager used by the global CLI.
  */
 export declare function inferPackageManagerForGlobalCLI(argv?: string[], env?: NodeJS.ProcessEnv): PackageManager;
+/**
+ * Returns the workspace (monorepo) root for the given path by searching upward
+ * for a pnpm-workspace.yaml file.
+ *
+ * @param directory - The path to search upward from.
+ * @returns The workspace root directory, or undefined if not in a workspace.
+ */
+export declare function getWorkspaceRoot(directory: string): string | undefined;
 /**
  * Returns the project directory for the given path.
  *

[gonzaloriestra]

What about just adding another guard clause before to check if isDevelopment()? In that case, just skip the auto-upgrade before checking if it's global or not.

This code seems a bit complex and our dev environment is a bit of a special case...

[alfonso-noriega]

What about just adding another guard clause before to check if isDevelopment()? In that case, just skip the auto-upgrade before checking if it's global or not.

This code seems a bit complex and our dev environment is a bit of a special case...

​we are currently checking isDevelopment && !isGlobal to decide that we are running the local sources of the CLI. The problem with just checking isDevelopment() is that we may run global from the CLI folder.

This fix is actually addressing a problem with isGlobal assuming that if we are not in a project dir then we are running a global instance.

But yes, we could actually just check isDevelopment and there would be a small amount of times that we fail to run upgrade for CLI contributors only

[gonzaloriestra]

isDevelopment() simply checks if SHOPIFY_CLI_ENV === development,so if you just run a global CLI in the CLI folder, it should be false.