Starting in December 2025, the project deploy start and project retrieve start commands will require that the target org use source tracking, unless you specify the metadata you want to deploy or retrieve. If you deploy or retrieve to an org that doesn’t use source tracking, then you must specify the metadata you want to deploy or retrieve.

Orgs that don’t use source tracking include production orgs, Partial Copy sandboxes, Full sandboxes, and scratch orgs that were created with the --no-track-source flag.

Let’s drill down a bit. The following examples all use project deploy start, but the same applies to project retrieve start.

Current Behavior

Let’s say you create a scratch org with the --no-track-source flag, which means that it doesn’t use source tracking, and you give it the alias my-scratch. The following command currently appears to succeed:

sf project deploy start --target-org my-scratch

As of release 2.104.6 (Sept 3), the command will return a warning about the upcoming change in behavior but the deploy will still appear to succeed. However, the command doesn’t actually deploy anything and the internal state of your metadata could be incorrect.

This same behavior applies to other orgs that don’t use source tracking, such as production orgs.

Behavior Starting December 2025

When you run this command on a non-source-tracking org, you will get an error:

sf project deploy start --target-org my-scratch

You can still deploy to a non-source-tracking org, but you must use one of these flags to specify the exact metadata you want to deploy: --metadata, --source-dir, or --manifest. For example:

sf project deploy start --source-dir force-app --target-org my-prod-org

Why Are We Making This Change?

The correct behavior when deploying to (or retrieving from) an org that doesn’t use source tracking, and not explicitly specifying the metadata, is to fail. We introduced the incorrect behavior in a previous release, so now we are fixing the issue but giving you plenty of time to adjust to the change.