Expected result
After editing only the CSS resource of a single Aura component via the Salesforce Setup UI (Developer Console), sf project retrieve preview reports ~370 unrelated metadata components as changed (ApexClasses, CustomObjects, CustomFields, Layouts, PermissionSets, Flows, ListViews, RecordTypes, etc.) that were not actually modified. Editing the component's markup (.cmp/HTML) alone does not trigger this — only editing the CSS resource does.
Steps to reproduce:
sf project reset tracking --target-org (confirm clean baseline: sf project retrieve preview returns 0 files)
In the target org, edit only the markup (.cmp) of an Aura bundle via Developer Console, save.
Run sf project retrieve preview --target-org → correctly shows only 1 file (the edited bundle).
Now edit the CSS resource of the same (or another) Aura bundle via Developer Console, save.
Run sf project retrieve preview --target-org again.
Expected: Only the edited CSS file (and its parent bundle) should appear as changed.
Actual: ~370 files across unrelated metadata types are listed as "Will Retrieve", including components that have no relationship to the edited Aura bundle (e.g., unrelated CustomObjects, Flows, PermissionSets).
Evidence that this is a local tracking issue, not a real server-side change:
Querying SourceMember via Tooling API directly confirms the org itself only registered new revisions for the 3 members actually touched (AuraDefinitionBundle, AuraDefinition:xxx.css, AuraDefinition:xxx.cmp). All ~369 other "changed" entries retain their old, unchanged RevisionCounter and LastModifiedDate from a prior deploy — proving the server did not report any new change for them.
sf data query --query "SELECT MemberType, MemberName, RevisionCounter, LastModifiedDate FROM SourceMember ORDER BY LastModifiedDate DESC LIMIT 400" --target-org --use-tooling-api
Despite this, the local .sf/orgs//maxRevision.json file is fully rewritten (new timestamp/size) after the CSS edit — suggesting the local revision-tracking logic rebuilds its known-state map incorrectly when processing new AuraDefinition/AuraDefinitionBundle revisions, causing it to "forget" that the other ~369 members were already known/synced.
Workaround currently in use:
sf project retrieve start -m AuraDefinitionBundle: --target-org
sf project reset tracking --target-org
System Information
CLI:
@salesforce/cli/2.143.6 win32-x64 node-v22.23.1
Plugin Version:
@oclif/plugin-autocomplete 3.2.53 (core)
@oclif/plugin-commands 4.1.60 (core)
@oclif/plugin-help 6.2.53 (core)
@oclif/plugin-not-found 3.2.88 (core)
@oclif/plugin-plugins 5.4.84 (core)
@oclif/plugin-search 1.2.53 (core)
@oclif/plugin-update 4.7.54 (core)
@oclif/plugin-version 2.2.50 (core)
@oclif/plugin-warn-if-update-available 3.1.68 (core)
@oclif/plugin-which 3.2.58 (core)
@salesforce/cli 2.143.6 (core)
agent 1.44.4 (core)
apex 3.9.38 (core)
api 1.3.46 (core)
auth 4.4.5 (core)
code-analyzer 5.14.0 (user)
data 4.0.110 (core)
deploy-retrieve 3.24.58 (core)
info 3.4.147 (core)
lightning-dev 6.2.18 (user)
limits 3.3.98 (core)
marketplace 1.3.38 (core)
org 5.11.16 (core)
packaging 2.30.1 (core)
schema 3.3.122 (core)
settings 2.4.92 (core)
signups 2.6.76 (user)
sobject 1.4.121 (core)
telemetry 3.8.27 (core)
templates 56.18.13 (core)
trust 3.8.33 (core)
user 3.10.4 (core)
@salesforce/sfdx-scanner 4.12.0 (user)
SF ENV. VARS.
SF_AUTOUPDATE_DISABLE,true
SF_BINPATH,C:\Users\Andre\AppData\Local\sf\client\bin\sf
SF_DISABLE_AUTOUPDATE,true
SF_UPDATE_INSTRUCTIONS,Use "npm update --global @salesforce/cli" to update npm-based installations.
Windows: true
Shell: cmd.exe
Channel: stable
Diagnostics
✅ pass - salesforcedx plugin isn’t installed
✅ pass - you don't have any linked plugins
✅ pass - [@salesforce/plugin-trust] can ping: https://registry.npmjs.org
✅ pass - [@salesforce/plugin-trust] can ping: https://registry.yarnpkg.com
✅ pass - [@salesforce/plugin-trust] can ping: https://registry.npmjs.org/
❌ fail - using latest or latest-rc CLI version
✅ pass - can access: https://test.salesforce.com
✅ pass - [@salesforce/plugin-deploy-retrieve] sourceApiVersion matches apiVersion
✅ pass - [@salesforce/plugin-deploy-retrieve] default target DevHub max apiVersion matches default target org max apiVersion
❌ warn - [@salesforce/plugin-deploy-retrieve] sourceApiVersion matches default target org max apiVersion
✅ pass - can access: https://appexchange.salesforce.com/services/data
✅ pass - can access: https://developer.salesforce.com/media/salesforce-cli/sf/channels/stable/sf-win32-x64-buildmanifest
❌ fail - [@salesforce/plugin-auth] CLI supports v2 crypto
✅ pass - [@salesforce/plugin-auth] CLI using stable v1 crypto
Expected result
After editing only the CSS resource of a single Aura component via the Salesforce Setup UI (Developer Console), sf project retrieve preview reports ~370 unrelated metadata components as changed (ApexClasses, CustomObjects, CustomFields, Layouts, PermissionSets, Flows, ListViews, RecordTypes, etc.) that were not actually modified. Editing the component's markup (.cmp/HTML) alone does not trigger this — only editing the CSS resource does.
Steps to reproduce:
sf project reset tracking --target-org (confirm clean baseline: sf project retrieve preview returns 0 files)
In the target org, edit only the markup (.cmp) of an Aura bundle via Developer Console, save.
Run sf project retrieve preview --target-org → correctly shows only 1 file (the edited bundle).
Now edit the CSS resource of the same (or another) Aura bundle via Developer Console, save.
Run sf project retrieve preview --target-org again.
Expected: Only the edited CSS file (and its parent bundle) should appear as changed.
Actual: ~370 files across unrelated metadata types are listed as "Will Retrieve", including components that have no relationship to the edited Aura bundle (e.g., unrelated CustomObjects, Flows, PermissionSets).
Evidence that this is a local tracking issue, not a real server-side change:
Querying SourceMember via Tooling API directly confirms the org itself only registered new revisions for the 3 members actually touched (AuraDefinitionBundle, AuraDefinition:xxx.css, AuraDefinition:xxx.cmp). All ~369 other "changed" entries retain their old, unchanged RevisionCounter and LastModifiedDate from a prior deploy — proving the server did not report any new change for them.
sf data query --query "SELECT MemberType, MemberName, RevisionCounter, LastModifiedDate FROM SourceMember ORDER BY LastModifiedDate DESC LIMIT 400" --target-org --use-tooling-api
Despite this, the local .sf/orgs//maxRevision.json file is fully rewritten (new timestamp/size) after the CSS edit — suggesting the local revision-tracking logic rebuilds its known-state map incorrectly when processing new AuraDefinition/AuraDefinitionBundle revisions, causing it to "forget" that the other ~369 members were already known/synced.
Workaround currently in use:
sf project retrieve start -m AuraDefinitionBundle: --target-org
sf project reset tracking --target-org
System Information
Diagnostics
✅ pass - salesforcedx plugin isn’t installed
✅ pass - you don't have any linked plugins
✅ pass - [@salesforce/plugin-trust] can ping: https://registry.npmjs.org
✅ pass - [@salesforce/plugin-trust] can ping: https://registry.yarnpkg.com
✅ pass - [@salesforce/plugin-trust] can ping: https://registry.npmjs.org/
❌ fail - using latest or latest-rc CLI version
✅ pass - can access: https://test.salesforce.com
✅ pass - [@salesforce/plugin-deploy-retrieve] sourceApiVersion matches apiVersion
✅ pass - [@salesforce/plugin-deploy-retrieve] default target DevHub max apiVersion matches default target org max apiVersion
❌ warn - [@salesforce/plugin-deploy-retrieve] sourceApiVersion matches default target org max apiVersion
✅ pass - can access: https://appexchange.salesforce.com/services/data
✅ pass - can access: https://developer.salesforce.com/media/salesforce-cli/sf/channels/stable/sf-win32-x64-buildmanifest
❌ fail - [@salesforce/plugin-auth] CLI supports v2 crypto
✅ pass - [@salesforce/plugin-auth] CLI using stable v1 crypto