[BUG]: NavigationMenu SourceMember name mismatch prevents source-tracked retrieve from completing

Reproduce the mismatch with the listed sf project retrieve preview and start commands, using the NavigationMenu path under community/main/default and the SourceMember Tooling API query. Trace how NavigationMenu:Default_Navigation is matched to the Metadata API fullName, then verify that retrieval updates the existing file and clears the component from the next retrieve preview.

Before You Submit

• I'm using the latest version of Salesforce CLI
• I've searched the existing issues
• I've run sf doctor to diagnose common issues

Related Issue

https://github.com/forcedotcom/cli/issues/2781

Command

sf project retrieve start --target-org

Org Type

Scratch Org

Did this work before?

Not sure

Last Working Version

No response

Summary

Source tracking reports an Experience Cloud NavigationMenu under the SourceMember name Default_Navigation, while Metadata API returns the same component as SFDC_Default_Navigation_Complaint_Public.

Because these names do not match, sf project retrieve start cannot associate the remote SourceMember change with the existing local component.

The component already exists in a configured non-default package directory:

community/main/default/navigationMenus/SFDC_Default_Navigation_Complaint_Public.navigationMenu-meta.xml

After changing the navigation menu in Experience Builder, sf project retrieve preview reports NavigationMenu:Default_Navigation with no path or projectRelativePath.

On CLI 2.152.14, sf project retrieve start successfully retrieves SFDC_Default_Navigation_Complaint_Public from Metadata API, but writes no files ("files": []) and does not clear the source-tracked change. The same Default_Navigation change therefore appears on every subsequent retrieve preview.

Repository to Reproduce

No response

Steps to reproduce

1. Create or use a source-tracked scratch org containing an Experience Cloud site with a NavigationMenu.

2. Store the NavigationMenu in a configured non-default package directory. For example:

   community/main/default/navigationMenus/SFDC_Default_Navigation_Complaint_Public.navigationMenu-meta.xml

   force-app is the default package directory.

3. Reset source tracking:

   sf project reset tracking --target-org <scratch-org-alias>

4. Verify both source-tracking previews show no changes:

   sf project retrieve preview --target-org <scratch-org-alias> --json

   sf project deploy preview --target-org <scratch-org-alias> --json

5. Modify the NavigationMenu in Experience Builder. For example, change the label of one menu item.

6. Run:

   sf project retrieve preview --target-org <scratch-org-alias> --json

   The CLI reports the changed component as NavigationMenu:Default_Navigation, with no path or projectRelativePath.

7. Run:

   sf project retrieve start --target-org <scratch-org-alias> --json

   Metadata API successfully returns the component with the fullName SFDC_Default_Navigation_Complaint_Public, but the command returns "files": [].

8. Run retrieve preview again:

   sf project retrieve preview --target-org <scratch-org-alias> --json

   NavigationMenu:Default_Navigation is still listed in toRetrieve.

9. The naming mismatch can also be confirmed through the Tooling API:

   sf data query --use-tooling-api --target-org <scratch-org-alias> --query "SELECT Id, MemberType, MemberName, RevisionCounter, IsNameObsolete FROM SourceMember WHERE MemberType = 'NavigationMenu'"

   The SourceMember has MemberName = Default_Navigation, while Metadata API identifies the component as SFDC_Default_Navigation_Complaint_Public.

Expected Result

sf project retrieve start should associate the changed NavigationMenu SourceMember with the existing local NavigationMenu component, retrieve the change into its existing package directory, and update source tracking so the component no longer appears in sf project retrieve preview.

The SourceMember name used for source tracking and the NavigationMenu fullName returned by Metadata API should be reconciled correctly.

Actual Result

Source tracking identifies the changed component as:

NavigationMenu:Default_Navigation

Metadata API identifies and successfully retrieves the component as:

NavigationMenu:SFDC_Default_Navigation_Complaint_Public

The CLI does not associate these identities.

On CLI 2.152.14, the retrieve succeeds at the Metadata API level but returns "files": []. The existing file is not updated and source tracking is not advanced. NavigationMenu:Default_Navigation therefore remains in toRetrieve after the retrieve completes successfully.

On CLI 2.150.6, the behavior was more severe: the retrieve created a duplicate SFDC_Default_Navigation_Complaint_Public.navigationMenu-meta.xml in the default force-app package directory even though the same component already existed under community.

CLI 2.152.14 no longer reproduces the duplicate-file behavior, but the underlying SourceMember/fullName mismatch and inability to complete the source-tracked retrieve remain.

System Information

{
  "architecture": "win32-x64",
  "cliVersion": "@salesforce/cli/2.152.14",
  "nodeVersion": "node-v22.17.1",
  "osVersion": "Windows_NT 10.0.26100",
  "rootPath": "C:\\Users\\dalden\\AppData\\Roaming\\npm\\node_modules\\@salesforce\\cli",
  "shell": "powershell",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 4.0.1 (core)",
    "@oclif/plugin-commands 5.0.0 (core)",
    "@oclif/plugin-help 7.0.0 (core)",
    "@oclif/plugin-not-found 4.0.0 (core)",
    "@oclif/plugin-plugins 7.0.1 (core)",
    "@oclif/plugin-search 2.0.0 (core)",
    "@oclif/plugin-update 5.0.0 (core)",
    "@oclif/plugin-version 3.0.1 (core)",
    "@oclif/plugin-warn-if-update-available 4.0.0 (core)",
    "@oclif/plugin-which 4.0.0 (core)",
    "@salesforce/cli 2.152.14 (core)",
    "agent 2.2.2 (core)",
    "apex 4.2.0 (core)",
    "api 2.0.10 (core)",
    "auth 5.0.7 (core)",
    "code-analyzer 5.16.0 (user)",
    "community 3.3.57 (user)",
    "data 5.1.8 (core)",
    "deploy-retrieve 4.2.2 (core)",
    "info 4.0.10 (core)",
    "limits 4.0.5 (core)",
    "marketplace 2.0.6 (core)",
    "org 6.0.13 (core)",
    "packaging 3.0.7 (core)",
    "schema 4.0.7 (core)",
    "settings 3.0.7 (core)",
    "signups 2.6.66 (user)",
    "sobject 2.0.6 (core)",
    "source 3.5.21 (user)",
    "telemetry 4.1.0 (core)",
    "templates 57.3.0 (core)",
    "trust 4.0.12 (core)",
    "user 5.0.4 (core)"
  ]
}

Additional Information

Tooling API confirms that this is not merely a local CLI naming artifact. Salesforce reports the SourceMember as:

• MemberType: NavigationMenu
• MemberName: Default_Navigation

Metadata API reports the corresponding NavigationMenu as:

• Type: NavigationMenu
• fullName: SFDC_Default_Navigation_Complaint_Public

The local source-tracking state likewise records the remote member as NavigationMenu__Default_Navigation.

As a control test, an ApexClass stored in the same non-default community package directory was modified in the scratch org. sf project retrieve preview correctly resolved that component to its existing community/... path. This suggests the issue is specific to NavigationMenu identity resolution rather than general handling of non-default package directories.

Resetting source tracking produces a clean baseline, but the issue immediately returns after the next NavigationMenu modification.

.forceignore patterns targeting both Default_Navigation.navigationMenu and the actual SFDC_Default_Navigation_Complaint_Public.navigationMenu-meta.xml path did not prevent the SourceMember change from appearing.

There is also historical evidence of Default_Navigation naming behavior in #772, although that issue concerns .forceignore rather than this source-tracking identity mismatch.

Screenshots or Log Files

No response