Fix autoupgrade incorrectly skipping in development mode

[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: The previous guard was `!isGlobal && isDevelopment()`, which only skipped the upgrade when both conditions were true. But `currentProcessIsGlobal()` misidentified a pnpm run from the CLI repo as global (since there's no `shopify.app.toml` to detect a local project), so the guard never triggered.

WHAT is this pull request doing?

Simplifies the guard to just `isDevelopment()`. `isDevelopment()` checks `SHOPIFY_CLI_ENV === development`, which is only set by the CLI repo's pnpm dev scripts — not by a globally-installed binary, even if run from the CLI folder. So contributors are protected and regular users are unaffected.

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 (SHOPIFY_CLI_ENV=development is set but `!isGlobal` was false, so the guard was skipped).
After this fix: upgrade is skipped (isDevelopment() returns true).

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 skipping in development mode #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.

[craigmichaelmartin]

Is there no test for this which needs updated?