Use the Doctor to Troubleshoot Problems
Run without flags, the command first displays basic information, such as whether you're on the latest CLI version. It then writes your configuration and a detailed diagnosis to a JSON file in the current directory. Use the --output-dir flag to specify a different directory. The name of the file is <timestamp>-diagnosis.json, such as 1708472775780-diagnosis.json.
1sf doctor --output-dir diagnostic-filesThe CLI doctor is in and ready to diagnose all your problems!
Run the Doctor on a Specific Command or Plugin
Use the --command flag to run a specific command in debug mode. Encapsulate the command in double quotes. The doctor generates two additional log files, one for the standard output (stdout) and another with debug information (stderr). The log files are called <timestamp>-command-stdout.log and <timestamp>-command-debug.log, respectively.
1sf doctor --command "org list --all"To run diagnostic tests on a specific plugin, rather than Salesforce CLI itself, use the --plugin flag. If the plugin isn't listening to the doctor, then you get a warning and no data.
1sf doctor --plugin @salesforce/plugin-deploy-retrieveCreate a GitHub Issue
To create a GitHub issue, use the --create-issue flag, enter a title at the prompt, and a browser window automatically opens with a partially filled GitHub issue. Enter the remaining information about your specific issue, click Submit new issue, and the Salesforce CLI team is alerted about your issue.
Interpret the Initial Doctor Output
1sf doctor --output-dir diagnostic-files
2=== Running all diagnostics
3
4pass - salesforcedx plugin not installed
5fail - no linked plugins
6warn - [@salesforce/plugin-deploy-retrieve] sourceApiVersion matches apiVersion
7pass - using latest or latest-rc CLI version
8...Each test that results in a fail or warn usually has a corresponding suggestion in the Suggestions section at the end of the output; make sure that you check them out!
Let’s look at the diagnostic tests that always run, and what you can do if they fail.
-
Test Name: salesforcedx plugin not
installed
What it does: Checks whether the salesforcedx plugin is installed. Having the plugin installed is an error, because the Salesforce CLI team stopped supporting it, and then removed it from the core CLI, many years ago. But some CLI installations continue to have it installed, which can cause problems.
If you get a fail result for this test, then your installation includes the salesforcedx plugin. You must uninstall it and update to the latest CLI version:
1sf plugins uninstall salesforcedx 2sf update -
Test Name: no linked plugins
What it does: Checks for any linked plugins in the CLI. Because the test checks for an absence of linked plugins, a pass means no linked plugins are detected, and a fail means that the doctor command detected at least one linked plugin. Linked plugins are plugins that you install from local files with the plugins link command.
If you get a fail for this test, see the Suggestions section at the end of the doctor output for the list of linked plugins. If you explicitly linked these plugins, great! If, however, you see a plugin that you don’t want linked, unlink it so you use the plugin version that’s included in Salesforce CLI. Another problem with linked plugins is that they aren’t updated when you update the CLI. Here’s how to unlink a plugin:
1sf plugins unlink my-plugin -
Test Name: [@salesforce/plugin-deploy-retrieve] sourceApiVersion matches
apiVersion
What it does: Checks whether the values of the apiVersion and sourceApiVersion variables are the same. Salesforce CLI uses the API version and source API version when deploying and retrieving metadata to and from the org.
If you get a fail or a warn, see the Suggestions section at the end of the doctor output for an explanation of why the test didn’t pass. For example, the values might be the same because you haven’t explicitly set them, and so they both default to the same value. If you desire this behavior, you don’t need to do anything.
See How API Version and Source API Version Work in Salesforce CLI for more information about how these two variables interact.
-
Test Name: using latest or latest-rc
CLI version
What it does: Checks whether the Salesforce CLI version is either the latest or the release candidate.
If you get a fail, we recommend that you update to the latest release of Salesforce CLI if possible. See Update Salesforce CLI for more information.
The doctor command also checks whether you’re using sfdx (v7) or sf (v1), both of which are deprecated. If you see this warning, read Move from sfdx (v7) to sf (v2) for information on how to move to sf (v2).
Interpret the Diagnostic File Information
versionDetail
Provides version information about Salesforce CLI and your computer, similar to the output of the sf version --verbose command. The JSON key names are self-explanatory, but here’s a recap anyway.
- cliVersion—Version of the installed Salesforce CLI.
- nodeVersion—Version of Node.js that Salesforce CLI is using.
- osVersion and architecture—Operating system version and architecture of your computer.
- rootPath—Location of the Salesforce CLI binary file.
- pluginVersions—List of core and user-installed plugins, along with their versions. User-installed plugins include the JIT plugins, such as packaging and devops-center.
sfdxEnvVars and sfEnvVars
Lists the environment variables that are set for your Salesforce CLI installation. The list includes user environment variables that you’ve explicitly set and internal variables that Salesforce CLI sets. See Salesforce CLI Environment Variables for list of user environment variables.
The sfdxEnvVars JSON object lists the deprecated SFDX_ environment variables. Even though they’re deprecated, they still affect the behavior of Salesforce CLI. The sfEnvVars object lists the SF_ environment variables.
Most of the deprecated SFDX_ environment variables have an SF_ equivalent with a similar name, such as SFDX_HIDE_RELEASE_NOTES and SF_HIDE_RELEASE_NOTES. Some environment variables had bigger name changes between SFDX and SF, see the Environment Variables section of the Migration Guide for details. If you set these SFDX_ and SF_ equivalent pairs to different values, the SF_ environment variable takes precedence.
Check the values of the user environment variables and ensure they’re what you expect and want. If you see a value you don’t want, determine how you’ve set the environment variable and change it as needed.
cliConfig
Lists the Salesforce CLI configuration settings, most of which are used by the underlying oclif framework, which Salesforce CLI is built on. A few examples include:
- binPath—Name and location of the sf binary.
- cacheDir—Directory that Salesforce CLI uses for internal caching.
- configDir—Directory in which Salesforce CLI stores internal configuration data.
- dataDir—Directory in which Salesforce CLI stores data.
- name—The npm name of Salesforce CLI, which is @salesforce/cli.
- theme—The default color theme for --help messages.
- shell—Shell you’re using, such as bash or zsh. The value is oclif’s best guess, but this information is notoriously difficult to glean, so the value can be wrong or unknown, especially on Windows computers.
See the oclif documentation for more information.
pluginSpecificData
If you ran the doctor command with either the --command or --plugin flag, and the associated plugin is listening to the doctor, then this section contains additional diagnostic information about the plugin. If the plugin isn’t listening, then this section is empty.
By default, the doctor runs all diagnostic tests, including all plugin-defined tests. You can target tests for a specific plugin using the --plugin flag as a way to reduce some noise or if you're a plugin author writing new doctor tests.