Error from source-tracked deployment after deleting a local `AiAuthoringBundle`

[SCWells72]

Summary

It looks like source-tracking doesn't currently handle removal of an AiAuthoringBundle very well.

Steps To Reproduce

1. Create a project against a scratch org enabled for Agent Script dev.
2. mkdir -p force-app/main/default/aiAuthoringBundles/TestScript
3. Add force-app/main/default/aiAuthoringBundles/TestScript/TestScript.agent as:

   config:
       default_agent_user: "user@org.com"
       agent_name: "TestScript"
   
   start_agent start_node:
       description: "TestScript"

4. Add force-app/main/default/aiAuthoringBundles/TestScript/TestScript.bundle-meta.xml as:

   <?xml version="1.0" encoding="UTF-8"?>
   <AiAuthoringBundle xmlns="http://soap.sforce.com/2006/04/metadata">
       <bundleType>AGENT</bundleType>
       <versionTag>v0.1</versionTag>
   </AiAuthoringBundle>

5. Push the project to the org.
6. Delete force-app/main/default/aiAuthoringBundles/TestScript.
7. Push the project to the org and it will fail with:

   Error (ENOENT): ENOENT: no such file or directory, open '/path/to/project/force-app/main/default/aiAuthoringBundles/TestScript/TestScript.agent'
   

It will continue to fail until you do something like sf project reset tracking.

Expected result

Source-tracking should handle the removed AiAuthoringBundle metadata and apply the local removal to the server.

Actual result

See above.

Additional information

System Information

{
  "architecture": "win32-arm64",
  "cliVersion": "@salesforce/cli/2.120.3",
  "nodeVersion": "node-v22.13.0",
  "osVersion": "Windows_NT 10.0.26200",
  "rootPath": "C:\\Users\\Scott\\AppData\\Roaming\\npm\\node_modules\\@salesforce\\cli",
  "shell": "cmd.exe",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.2.39 (core)",
    "@oclif/plugin-commands 4.1.38 (core)",
    "@oclif/plugin-help 6.2.36 (core)",
    "@oclif/plugin-not-found 3.2.73 (core)",
    "@oclif/plugin-plugins 5.4.54 (core)",
    "@oclif/plugin-search 1.2.36 (core)",
    "@oclif/plugin-update 4.7.16 (core)",
    "@oclif/plugin-version 2.2.36 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.54 (core)",
    "@oclif/plugin-which 3.2.42 (core)",
    "@salesforce/cli 2.120.3 (core)",
    "agent 1.26.5 (core)",
    "apex 3.9.5 (core)",
    "api 1.3.7 (core)",
    "auth 4.1.2 (core)",
    "code-analyzer 5.8.0 (user) published 31 days ago (Sun Dec 28 2025) (latest is 5.9.0)",
    "community 3.3.48 (user) published 54 days ago (Sat Dec 06 2025)",
    "data 4.0.67 (core)",
    "deploy-retrieve 3.24.7 (core)",
    "info 3.4.100 (core)",
    "lightning-dev 5.1.4 (user) published 19 days ago (Fri Jan 09 2026) (latest is 4.5.3)",
    "limits 3.3.74 (core)",
    "marketplace 1.3.8 (core)",
    "org 5.9.59 (core)",
    "packaging 2.24.7 (core)",
    "schema 3.3.90 (core)",
    "settings 2.4.54 (core)",
    "sobject 1.4.81 (core)",
    "telemetry 3.6.71 (core)",
    "templates 56.4.2 (core)",
    "trust 3.7.113 (core)",
    "user 3.6.46 (core)",
    "@salesforce/sfdx-plugin-lwc-test 1.2.1 (user) published 481 days ago (Fri Oct 04 2024)",
    "@salesforce/sfdx-scanner 4.12.0 (user) published 274 days ago (Tue Apr 29 2025)"
  ]
}

[github-actions]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[github-actions]

Hello @SCWells72 👋 None of the versions of sf you shared match the latest release.

Shared: 2.119.8
Latest: 2.120.3

Update to the latest version of Salesforce CLI (docs) and confirm that you're still seeing your issue.
You can also try the rc and nightly releases! (docs)

After updating, share the full output of sf version --verbose --json

[WillieRuemmele]

Hey there @SCWells72 - I literally just put up a PR fixing this for another bug... we'll get this fixed.

NOTE: I haven't been able to delete a published AAB, even if I include theBot/BotVersions to be deleted... it's following a Flow pattern for deleting 😦

[SCWells72]

Thanks for the update, @WillieRuemmele. Also, do you know why MetadataApi.listMetadata() for AiAuthoringBundle returns names/filenames with numeric suffixes like TestScript_1 when the actual on-disk name doesn't include that suffix? I'm assuming it's some kind of versioning suffix, but it means that the name from listMetadata() can't be used directly to correlate to the associated directory and bundle files. Right now I'm just stripping that numeric suffix, but I don't know what kinds of problems that will likely introduce somewhere down the line. Is AiAuthorizationBundle well-documented somewhere?

[WillieRuemmele]

the _<number> is the server-side versioning, it's used when 'committing' in the UI, but in the filesystem is doesn't make as much since, because your local .agent file is always essentially, the next draft to-be-committed. This can be seen temporarily in the -meta.xml file as

  <target>MyAgent.v3</target>

when publishing.

during the publish command, we retrieve all other related metadata created as part of the publish, Bot/Version and that's when that -meta tag is removed, and the .agent is back in a 'draft' state. I'm sure you've seen the documentation here and we have some here - but it's nothing probably as extensive as you're after

[SCWells72]

Thanks. Yeah, I've seen all of that. So two things:

1. It sounds like stripping the numeric suffix from the name reported by listMetadata to correlate that information to the on-disk representation is safe/fine, correct?
2. The AiAuthoringBundle directory structure docs look incorrect with regard to the meta.xml file. Based on the example repo and my own experience, the files should be scriptName.agent and scriptName.bundle-meta.xml, not scriptName-meta.xml as documented there, no? FWIW, I think is might have also deployed fine with scriptName.agent-meta.xml (which makes WAY more sense to me!).

Thoughts?

[WillieRuemmele]

1. yes, stripping the number is the best approach, for now.
2. Ha! yes, the first link I sent has the wrong suffix, In my project, theres MyAgent.bundle-meta.xml which is what we're using

[SCWells72]

Any idea why it's <scriptName>.bundle-meta.xml instead of <scriptName>.agent-meta.xml when there's (to my knowledge) no <scriptName>.bundle file in the <scriptName> bundle directory?

I just tried deploying a new one with <scriptName>.agent-meta.xml instead, and it did deploy successfully, but when I retrieved it, no meta.xml file was included in the retrieval payload. So it seems that a meta.xml file isn't even needed to deploy these bundles, but if you provide one, it seems that it must be named as *.bundle-meta.xml.

Just seems odd to me...