I've already looked at the existing questions and made sure of the following:

  1. Only package.xml & destructiveChanges.xml are in the folder I'm trying to deploy.
  2. package.xml is empty outside of the version
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
  1. The items in destructiveChanges.xml exist in the org I'm trying to delete them from.
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
  1. The folder is at the root of the project.
  2. Updated SFDX CLI

I've tried deploying it by the directory and by a zip of the directory. The same package.xml can be used to retrieve items from ORG via the VSC UI fine. I've only been able to find a bug from 2015 about this issue. Here's a picture of the attempts: Picture of VSC terminal attempting to deploy a destructive package by directory and then by zip

Is there anything I'm missing/overlooking? Did I format the command improperly? Any advice would be appreciated.

  • My understanding is that the complaint is about empty package.xml, so, I guess you cannot have a deployment to delete only, using the destructive changes xml. When I used it I always had something to deploy and some components to remove. May 13, 2021 at 17:36
  • @JefersonChaves other documentation I've read says that package.xml has to be empty but I'll try to add something random to it to see if it'll go. It'd be a bit upsetting if I have to deploy something random every time I want to clean up an apex class from production.
    – MadameEvil
    May 13, 2021 at 17:49
  • @JefersonChaves No, you can have an empty package.xml (given the example here).
    – sfdcfox
    May 13, 2021 at 17:49
  • 1
    Give me just a couple minutes while I do some testing, MadameEvil. I'll be right back with you.
    – sfdcfox
    May 13, 2021 at 17:59
  • @sfdcfox I feel that Metada API supports that (in fact remember using that with ANT) but sfdx mdapi is not honoring, yet: github.com/forcedotcom/cli/issues/188 May 13, 2021 at 18:42

2 Answers 2


This doesn't appear to be a problem in the latest version. I've tried the following:

sfdx force:mdapi:deploy -f manifest.zip -w 10


sfdx force:mdapi:deploy -d manifest/ -w 10

Both worked out well, and deleted the file in question. I also tried it with and without the normal XML header:

<?xml version="1.0" encoding="UTF-8"?>

Absolutely nothing I've tried has resulted in this error.

It might just be a problem with how PowerShell works, or maybe you have a space in your file path (e.g. C:\Users\Brian Fear\workspace has been known to cause problems in some commands/versions).

The only real suggestion I have is to try and move your project to a space without spaces, such as C:\workspace\myproject\.

  • Just to make sure since SFDX has lied to me about being updated before, this is the version I'm on sfdx-cli: Updating CLI... already on the latest version: 7.100.0-9d243d8 does that match up with the version you're running?
    – MadameEvil
    May 13, 2021 at 19:08
  • @MadameEvil sfdx-cli/7.101.0 win32-x64 node-v14.6.0 is what I'm on. It may be worth noting that I use the npm package npm install -g sfdx-cli and not the binary installer. I am aware that the bin install has had occasional issues, so I prefer the npm version instead.
    – sfdcfox
    May 13, 2021 at 19:13
  • I tried from bash shell instead of power shell to the same effect. I reinstalled via npm and still can't seem to get the version you're on. I wonder if it's a difference in the node versions causing issues? sfdx-cli/7.100.0 win32-x64 node-v16.0.0 I may try on a different machine with a fresh instal of CLI and see if that helps.
    – MadameEvil
    May 13, 2021 at 19:30

I had the same but after removing the parameter -l RunLocalTests it works ok. I guess this parameter expects something in the package.xml

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .