forcedotcom/cli holds the Salesforce CLI tracker, not the tool itself

A repository whose real content is the conversation around the tool

forcedotcom/cli is not the Salesforce CLI. It is a tracker for it. The repository description says as much in two words, issues and discussions only, and the project documentation repeats it: the maintainers use the place to collect feedback from the community and to publish proposals for CLI changes so that people can react before the work lands. Weekly release notes are stored there as well.

What that means for a reader is that the useful content is procedural rather than technical. There is no package to install here, no source tree to clone and compile. The top level of the repository reflects that: apart from the tracker configuration and governance files, it holds a CHANGELOG.md, a CODEOWNERS file, a SECURITY.md, a package.json, a tsconfig.json, a yarn.lock, a releasenotes directory and a README. The one piece of code in the repository exists to support the tracker itself, not the CLI.

For a Salesforce developer, the practical value is different from the usual open source repository. This is where a deprecation gets proposed, where a bug report about a command lands, and where a weekly note explains what changed. It is also the place the maintainers point contributors at when they want to reach the people who actually use the tool.

Release notes live here, and the GitHub release list stays empty

One structural detail catches people out. The repository has no GitHub releases at all. The changelog is delivered as a directory of weekly notes instead, and the project documentation links to a Release Notes index under that directory for reading what is new and what changed in recent weekly updates to Salesforce CLI.

That split has a practical consequence. A tool that pulls its version history from the releases page of its repository will find nothing here, and a reader skimming the repository sidebar will not see a version dropdown. The history lives in files, and the cadence is weekly rather than tied to a tagged release. The changelog file at the top level and the weekly notes under releasenotes are therefore two views of the same stream, and neither one is a semantic version tag you can pin a build to.

The project documentation points to what it calls the up-to-date list of CLI repositories, which lives in the salesforcecli organisation and is linked from the same page. That link is the bridge between this tracker and the code, and it is also the fastest way to find where a given command or plugin is actually implemented.

The sf v2 unification explains why two command names still show up

Salesforce CLI has been through a renaming that older scripts still reflect. In July 2023 the maintainers announced general availability of sf version 2, described as the culmination of a unification effort that started back in 2021 with sf version 1. The unified binary is written to understand both sfdx style and sf style commands, so a script written against the older name keeps working after the switch.

The stated reason for the move is size. Because the unified CLI is smaller, the README says it is faster to install and update, which is the practical argument for a tool that developers are told to keep current. Two migration guides are linked for the transition: one for moving from sfdx version 7 to sf version 2, and one for migrating sfdx style commands to the new sf style.

For a reader of this repository, the unification matters because it is the reason a single tracker can accept both kinds of command syntax in an issue title, and the reason the release notes mention both names. It is also the context in which a proposal to change command behaviour is judged, since a change that looks minor under the sfdx name may be a breaking change under the sf name.

The real installation steps and command reference sit in other documentation

There is no install command in this repository, and there is no package to copy from it. Installation, updating and configuring the CLI are covered by the Salesforce CLI Setup Guide, which the project documentation links alongside a Salesforce DX Developer Guide with step-by-step instructions for using the DX tools and a Salesforce CLI Command Reference described as the complete reference for all CLI commands.

The same list includes an sf Plugin Developer Guide, hosted on the salesforcecli wiki, for people writing their own custom plugin, and a Trailhead trail of tutorials on Trailhead for building apps together with package development. A link to the Salesforce Developers Blog closes the set. Anyone who expected to find a download command or a sample configuration here will find a set of links to where those things actually live, which is a reasonable design for a tracker but a common point of confusion for a newcomer landing on the repository through a search result.

So the practical reading order for someone new to the project is the setup guide for the install, the command reference for what exists, this repository for what is about to change, and the release notes index for what changed this week.

Proposals run through discussions, bugs run through issues, and neither is support

The documented workflow is specific. For a feature or an enhancement, you first review the existing discussions to see whether somebody has already asked for it, and only if nothing matches do you create a new discussion. For a bug, you check the existing issues first and then open a new issue if it is not already reported. Two separate queues, two separate buttons, and an explicit instruction to search before filing.

The project documentation also posts a notice that stands out because it is unusual for a public tracker to say so plainly. GitHub is not a mechanism for receiving support under any agreement or service level agreement, and anyone who needs immediate assistance is told to use official Salesforce customer support channels instead. In practice that means an issue opened here is a feedback and triage channel, not a support ticket, and a developer with a production outage has a different path to follow than a developer who wants a new flag.

Contributing code is a separate track again, covered by a contributing guide in the .github directory. The repository also carries a code of conduct and a security policy, so there is a defined route for reporting a vulnerability as well.

The Actions tree ships compiled files, and a pre-commit hook handles it

The one place with actual build tooling is the GitHub Actions source under .github. The contributing instructions are specific about how it works: when you contribute to the Actions, you modify the files under .github/actions/**/src, and a pre-commit hook builds and commits the compiled lib files for you. When you add a new action, you add its path to the references in the base tsconfig.json file.

The build configuration in package.json is a small TypeScript project. The script section defines a single build step, and the husky configuration wires the pre-commit hook to that build followed by a git add of the compiled action output:

{
  "name": "cli",
  "version": "1.0.0",
  "scripts": {
    "build": "tsc --build"
  },

Two details of the dependency list are worth noticing. The runtime dependencies are three packages, @actions/core, @actions/github and semver, which is what an Actions helper needs and nothing more. The development toolchain pins typescript at 4.9.5 and prettier at 1.19.1, both old enough to be worth a look before you extend the tree, since the formatting rules and the compiler behaviour are what the committed lib files were generated with.

The project name and licence are also fixed in the same file:

  "homepage": "https://github.com/forcedotcom/cli#readme",
  "license": "Apache-2.0"

Apache-2.0 for the tracker, and a recent push with no tagged releases

The licence is Apache-2.0, recorded in the package.json and in a LICENSE.txt file at the top level. The same permissive terms apply to the tracker configuration, the Actions helper code and the release notes, which is convenient for a company that wants to mirror the notes or reuse the automation. This is a licensing observation about the files, not advice on how any of it fits a particular product.

On maintenance, the two signals pull in different directions. The last push was on 2026-10-21, so the repository is being worked on. The release history, on the other hand, is empty in the GitHub sense, because the weekly notes under releasenotes replace tagged releases entirely. There is no v-prefixed tag to pin a checkout to, and no version string in the package.json that tracks the CLI, since the 1.0.0 there describes the tracker project rather than the tool being discussed.

That distinction is the one to keep in mind whenever you read the numbers attached to this repository. The activity belongs to the tracker, the tracker is about the CLI, and the CLI itself is versioned and released somewhere else entirely.

Editorial conclusion

Use forcedotcom/cli as the place to track what the Salesforce CLI is about to change and to read the weekly release notes, and treat the setup guide and command reference as the real documentation. Do not expect to find the tool, its source code, or an installation command here, because this repository deliberately holds none of those. Before opening an issue, check the existing discussions and issues, and if you need a guarantee on response time, use official Salesforce customer support channels instead. One concrete check first: confirm the sf version on your machine matches the sf v2 unification described here, since the migration from sfdx (v7) is the change most likely to affect your scripts.

Frequently asked questions

Official sources

1. forcedotcom/cli on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README