Shopify CLI / Tools

Shopify CLI 4.0
Adopting SemVer, auto-update, and removal of deprecated flags/commands

The CLI's versioning scheme moves to SemVer, and the CLI now upgrades itself automatically.--force and legacy commands are removed, so CI/CD now --allow-updates/--allow-deletes for its workflow.

On this page
  1. Understand in 30 seconds: What changes in Shopify CLI 4.0?
  2. Change ①: Adopting Semantic Versioning
  3. Change ②: Auto-upgrade
  4. Change ③ --force Removals and new flags
  5. List of removed legacy commands/flags
  6. How to rewrite your CI/CD pipeline
  7. 5 key points for engineers
  8. 3 use cases you can apply at work
  9. A one-line summary for proposals

1Understand in 30 seconds: What changes in Shopify CLI 4.0?

Shopify CLI 4.0 is a major release that overhauls three things at once: versioning rules, the update method, and the removal of dangerous flags.
The key points are SemVer adoption, auto-update, and--force removal (→ --allow-updates / --allow-deletes) )—three changes in total.
x.y.z

① SemVer adoption

New features = minor, bug fixes = patch, breaking changes = major. The version number tells you whether the next update will break things.

② Auto-upgrade

The CLI updates itself through the package manager used to install it. CI, project-local installs, and major versions are excluded.

--force removal

Deprecated because it couldn't distinguish high-risk operations (including deletions) from low-risk ones.--allow-updates / --allow-deletes to choose the level of granularity.

2Change ①: Adopting Semantic Versioning

MAJOR : 4.x.x Breaking changes Changes to command structure/behavior Not included in auto-update MINOR : x.4.x New feature additions Backward compatible Auto-update ◯ PATCH : x.x.4 Bug fixes only Backward compatible Auto-update ◯
With the move to SemVer,"Verify carefully only when the major version bumps"becomes an easy operational rule to adopt. Until 5.0 ships, you can accept minor/patch updates on the assumption that they won't break the command structure.

3Change ②: Auto-upgrade

Developer's local machine npm / pnpm / yarn / homebrew Installed via one of these Shopify CLI 4.0 Checks the version at startup If a newer version exists, using the same PM updates itself Conditions where it is skipped ① CI environment ② Project-local install ③ Major version update
On by default

A new version gets installed automatically

Respecting the package manager used to install it, the CLI updates itself through that same mechanism.

Can be disabled

When you want to turn it OFF

shopify config autoupgrade off lets you stop it. CI / project-local / major updates are excluded from the start.

By design, auto-update does not run in CI = the CLI version used inside CI jobs stays pinned to "the version specified in the install steps". As a result, only local developers move to the new version while CI stays on the old one, and this divergence can occur, so you need to explicitly run version updates in CI as well.

4Change ③ --force Removal and a new flag

ItemUp to 3.xShopify CLI 4.0
Unattended deploy --force One shot (no granularity) Removed
Adding/updating extensions --force is included (low risk) --allow-updates
Deleting extensions --force is included (high risk) --allow-deletes
How easily accidents happen No distinction → unintended deletions could occur Nothing is deleted unless you explicitly state "allow deletion"
The new flag was already pre-announced in the March 2026 changelog. 4.0 marks the end of that "grace period" and --force removes the feature itself. If you hard-code --force in CI/CD, update it right away --allow-updates(plus, if needed, --allow-deletes) is what you need to rewrite it to.

5List of removed legacy commands / flags

RemovedReplacementTarget
shopify app deploy --force
shopify app release --force
--allow-updates / --allow-deletes app
shopify webhook trigger shopify app webhook trigger app
shopify theme serve shopify theme dev theme
shopify app generate schema shopify app function schema app / function
shopify app webhook trigger --shared-secret --client-secret app
shopify app generate extension --type --template app
These were removed all at once after a deprecation period. The safest approach is to do a bulk search-and-replace of any old syntax still lingering in internal docs, README command examples, Makefiles, shell scripts, and GitHub Actions workflows.

6How to update your CI/CD pipeline

1

Old --force — remove all of them

Across the entire repository, --force grep for it. Remove it unconditionally from deploy/release commands.

2

Add / update only → --allow-updates

This is enough for flows that only add new extensions or only update existing extension code.

3

Only in environments where deletion is allowed --allow-deletes

Add this only if you want to let CI tidy up extensions. It's safer not to apply it to production branches.

75 key points for engineers

major.minor.patch

1. The SemVer number lets you gauge risk

like 5.0 Only when a major update is releaseddo you need to watch for breaking changes to command structure or behavior. minor/patch updates can generally be accepted as-is.

CI

2. auto-upgrade doesn't run in CI

The CLI version in CI is pinned. You can end up in a state where only local developers upgrade ahead, so you need to manage the CI-side version separately.

3. Specify "add/update" and "delete" as clearly separate

In CI/CD, as a rule, use only --allow-updates , and--allow-deletes should be limited to maintenance jobs or staging to prevent accidents.

4. Old commands lurk in multiple places

theme serve / webhook trigger / generate schema / --type / --shared-secret tends to remain in internal wikis, Makefiles, and GitHub Actions YAML. Flush them out with a bulk grep.

5. shopify config autoupgrade off lets you turn off auto-updates

In environments with strict version alignment (e.g., agency work where you want to lock the Shopify CLI version across multiple clients), the practical solution is to turn auto-upgrade OFF even on developer machines and distribute that via dotfiles.

83 use cases you can apply at work

- --force + --allow- updates CI ready
USE CASE 1

A "zero-accident" audit of your CI/CD pipeline

Challenge
In a custom app's GitHub Actions, shopify app deploy --force is hardcoded, and in the past a branch-cleanup mistake caused extensions to be deleted all at once.
Solution
At the same time as updating to 4.0,--force--allow-updates as the replacement. Move any logic that permits deletion into a separate, manually-approved job, and there alone attach --allow-deletes .
Impact
Structurally prevents "accidental deletions." On the Pull Request, reviewers can explicitly tell apart "this only adds" from "this also deletes."
Technical note
The recommended pattern is to separate the production-deployment workflow from the refactoring workflow.
3.x → 4.0 README Makefile .github/workflows
USE CASE 2

Packaging a custom app's "3.x → 4.0 migration" as a billable engagement

Challenge
The client's Shopify app development repository still contains removed commands (e.g.theme serve/webhook trigger/generate schema --type , etc.), so bumping to 4.0 may break CI.
Action
1) Bulk-grep for the old commands/flags → 2) Rewrite them per the replacement mapping → 3) Install 4.0 locally and run a smoke test → 4) Open a PR and merge.
Impact
You can ride the free update to pitch "CLI 4.0 migration" as a standalone service offering, and at the same time you gain resilience for the next major (5.0).
Technical note
Since the replacements are limited to the 6 typesshown in this article, the estimation scope is easy to define.
Local auto ◯ CI pinned
USE CASE 3

"CLI version governance" for agencies and teams running multiple projects in parallel

Challenge
On a team juggling multiple projects, if developers' local CLIs upgrade on their own, you end up with project A on 4.2 and project B on 4.5, and reproducibility breaks down.
Action
Approach A: Have each developer run shopify config autoupgrade off , and pin the version per project via its package.json . Approach B: CI is excluded from auto-updates to begin with, so explicitly install a fixed version in CI.
Impact
Structurally eliminates "works locally but fails in CI / behaves differently from another project." Reproducible debugging becomes possible.
Technical note
Choose an approach based on each project's characteristics, with a clear understanding of auto-upgrade's skip conditions (CI / project-local / major).

9A one-line summary you can use in proposals

"Shopify CLI 4.0 is a cleanup-focused major release that bundles SemVer adoption / auto-update /--force deprecation .
Rewrite CI/CD to use --allow-updates / --allow-deletes , and once you clear out the 6 old commands, the migration is complete.
Going forward, you can switch to a 'carefully validate only when the major version number increases'way of operating."