Repository navigation
Announcement: Upcoming Breaking Changes - Enhancing CLI Credential Security and Mitigating Exposure Risks #3560
Description
Overview
Self link: sfdc.co/cli-credential-auth-command-changes
To significantly improve security posture and reduce the risk of accidental credential exposure, the Salesforce CLI team is changing how sensitive authentication artifacts-specifically Access Tokens, Passwords, and SFDX Auth URLs-are returned in command outputs.
Starting May 27, 2026, these secrets will be completely removed from the standard human-readable and --json outputs of existing commands. We are introducing new dedicated commands designed specifically for explicit credential retrieval. A temporary environment variable workaround will be available to prevent immediate pipeline breakage, but it will be strictly decommissioned at a later date.
Why are we making this change?
A recent security review identified elevated risks associated with sensitive credentials being exposed through standard CLI workflows. While historically designed for developer convenience, these outputs present a heightened vulnerability in modern AI-assisted and agentic development environments.
AI coding agents and automated systems often store execution logs in plain text. If an AI agent executes a standard command that returns a credential, that secret may be permanently recorded in unencrypted chat history. To align with broader platform security goals, we are shifting toward an explicit model for retrieving a credential that requires deliberate user intent and is clearly labeled as a high-risk operation. These new explicit commands can be deny-listed from a coding agent's permitted execution.
Detailed Changes & Impacted Commands
Removal from Standard Outputs (Effective May 27, 2026)
Sensitive data (Access Token, SFDX Auth URL, and Password) will be redacted from standard human-readable text and --json outputs across several commands:
- Plugin-org
sf org displaysf org listsf org create scratchsf org resume scratch
- Plugin-user
sf org display usersf org list users
- Plugin-auth
sf org login jwtsf org login websf org login sfdx-urlsf org login access-tokensf org list auth
Example:
sf org display -o test-axctqdrsf0xf@example.com
Warning: Secrets are now hidden from 'sf org display' command output. Use the 'sf org auth' commands instead. As a temporary workaround, you can set SF_TEMP_SHOW_SECRETS=true to render these secrets. This workaround will be removed in an upcoming release.
Org Description
┌─────────────────┬───────────────────────────────────────────────────────────────────────────────────────┐
│ KEY │ VALUE │
├─────────────────┼───────────────────────────────────────────────────────────────────────────────────────┤
│ Access Token │ [REDACTED] Use 'sf org auth show-access-token' to view │
│ Api Version │ 66.0 │
│ Client Id │ 3MVG9i1HRpGLXp.oar0z6z6xsKD_P8CZp5Mb07PzDxTmh90QP8m48lxXCTnL6uYxG65yPUXKFHdWABCDEFHIJ │
│ Created By │ admin@foo.org │
│ Created Date │ 2026-05-19T01:44:44.000+0000 │
│ Dev Hub Id │ admin@foo.org │
│ Edition │ Developer │
│ Expiration Date │ 2026-05-20 │
│ Id │ 00DDP000006GRcP2AW │
│ Instance Url │ https://customer-connect-9302-dev-ed.scratch.my.salesforce.com/ │
│ Org Name │ foo company │
│ Password │ [REDACTED] Use 'sf org auth show-user-password' to view │
│ Signup Username │ test-axctqdrsf0xf@example.com │
│ Status │ Active │
│ Username │ test-axctqdrsf0xf@example.com │
└─────────────────┴───────────────────────────────────────────────────────────────────────────────────────┘
New Dedicated Retrieval Commands
If you must explicitly retrieve a credential, you will need to migrate to these new interactive commands:
sf org auth show-access-tokensf org auth show-sfdx-auth-urlsf org auth show-user-password
Example:
sf org auth show-access-token
✔ You’re about to reveal the access token for "test-axctqdrsf0xf@example.com". This token grants full access
to the org with your current permissions. Sharing or logging this token is equivalent to sharing your
credentials. Do you want to continue?
# Yes
┌──────────────┬────────────────────────────────────────────────────────────────┐
│ Key │ Value │
├──────────────┼────────────────────────────────────────────────────────────────┤
│ Access Token │ 00DXXXXXXXXXXXX!YYYYYYYYYYYYYYYYYYYYYYYY.ZZZZZZZZZZZZZZZZZZZZZ │
└──────────────┴────────────────────────────────────────────────────────────────┘
Note
These commands are interactive by default and will render a security warning. To use them in non-interactive environments (like CI/CD), you must explicitly append the --json or --no-prompt flags.
Critical Timeline & Deadlines
| Date | Milestone | Action Required |
|---|---|---|
| May 20, 2026 | Public awareness outreach | Review your internal CI/CD scripts for any exposure dependencies. |
| May 27, 2026 | Production Release | Secrets are removed from existing commands. If your pipelines break, deploy the temporary env variable workaround immediately. |
| Summer 2026 | Workaround Deprecation | The temporary environment variable is completely removed. Your workflows must be updated to the new dedicated commands by this date. |
Recommended Actions & Migration Path
We know that thousands of sf CLI workflows rely on these outputs every day for legitimate steps like end-to-end testing, scratch org setup, or automated post-deployment steps. To minimize operational disruption, please follow this phased migration path:
Temporary Mitigation
If you cannot rewrite your pipelines before May 27, you can inject a temporary environment variable into your CI/CD environment to maintain legacy behavior:
# Set this in your CI/CD environment to temporarily preserve old behavior
SF_TEMP_SHOW_SECRETS=trueThis is a temporary workaround and the support for this environment variable will be removed in summer 2026.
Permanent Migration
Update your automation scripts to use the new explicit commands. For example, if your CI/CD script was parsing sf org display --json to fetch an access token, swap the logic to call the explicit command directly:
# Legacy way - credentials will be redacted beginning May 27th 2026
sf org display --json
{
"status": 0,
"result": {
"id": "00DBi000003zte4NAB",
"devHubId": "mitchspano.test@agentforce.com",
"apiVersion": "66.0",
"accessToken": "00DXXXXXXXXXXXX!YYYYYYYYYYYYYYYYYYYYYYYY.ZZZZZZZZZZZZZZZZZZZZZ",
"instanceUrl": "https://site-flow-9136-dev-ed.scratch.my.salesforce.com",
"username": "test-rgv2dvamaow7@example.com",
"clientId": "PlatformCLI",
"status": "Active",
"expirationDate": "2026-06-03",
"createdBy": "mitchspano.test@agentforce.com",
"edition": "Developer",
"orgName": "mspano company",
"createdDate": "2026-05-14T20:06:26.000+0000",
"signupUsername": "test-123@example.com",
"alias": "TDX_2026"
},
"warnings": [
"This command will expose sensitive information that allows for subsequent activity using your current authenticated session.\nSharing this information is equivalent to logging someone in under the current credential, resulting in unintended access and escalation of privilege.\nFor additional information, please review the authorization section of the https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth_web_flow.htm."
]
}# New way - use if you need to parse access token programmatically
sf org auth show-access-token --json
{
"status": 0,
"result": {
"accessToken": "00DXXXXXXXXXXXX!YYYYYYYYYYYYYYYYYYYYYYYY.ZZZZZZZZZZZZZZZZZZZZZ"
},
"warnings": [
"This command exposes a sensitive Access Token that allows for subsequent activity using your current authenticated session. Sharing this information is equivalent to logging someone in under the current credential, resulting in unintended access and escalation of privilege. For additional information about org authorization, review https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth.htm."
]
}
We also recommend prohibiting these sf org auth show-* commands from any AI coding agent's permissions.
Feedback
We would love to hear how your teams are actually using these credentials in your workflows so we can best shape the future roadmap and security posture for the sf CLI. Please participate in this discussion.
Activity
jort-kuhlmann commentedon May 21, 2026
@mitchspano vlocityinc/vlocity_build#790
dkelll commentedon May 22, 2026
@mitchspano Are there any plans to change
sf org login --url-only?paragdesai-vagov commentedon May 22, 2026
Besides the commands listed in the initial message above. Is there a full list of commands this will affect?
we use sfdx auth urls for service accounts created in salesforce environments. The auth_urls are stored as secrets in our repos, then the secrets are used in our workflows (not the actual auth url).
Will this still affect our cicd workflows?
petter-eikeland commentedon May 23, 2026
@mitchspano Just to double check: This change only applies to the
sfCLI commands you listed. Theunderlying
@salesforce/coreAuthInfo.*methods are unaffected by this announcement (e.g.AuthInfo.getSfdxAuthUrl()method)?Adapt sf CLI auth to upcoming credential-redaction breaking change
HunainCriteria commentedon May 25, 2026
Also want to mention about the old
sfdxcommands, I know they've been deprecated/not-supported, but wouldt i affect them as well?iowillhoit commentedon May 26, 2026
@dkelll Currently no plans to change
sf org open --url-only. That command produces a one-time use url.iowillhoit commentedon May 26, 2026
@paragdesai-vagov that is the full list of commands.
Before this change, the only way to obtain the SFDX Auth url (via a command) was with the
sf org display --verbosecommand. That auth value has been removed from thesf org display --verboseoutput in this change. You will need to usesf org auth show-sfdx-auth-urlinstead.However, to use the auth url, you will still be able to run the
sf org login sfdx-urlcommand. That has not changed. If you have existing auth urls stored as CI/CD secrets, your auth should continue to work.iowillhoit commentedon May 26, 2026
@petter-eikeland correct, commands only. The https://github.com/forcedotcom/sfdx-core library is unchanged.
iowillhoit commentedon May 26, 2026
@HunainCriteria, any CLI version before
2.136.xwill function as before. That said,sfdx(v7) was deprecated over 3 years ago, you should update :)fix: handle SF CLI 2.136.8 access token redaction in sfdxLogin
cmatos23 commentedon May 27, 2026
if this is a breaking change, why are we not incrementing the major version? we all have to sort of memorize that 2.136.x is breaking.
Fetch access token via `sf org auth show-access-token`
fix: fetch sfdx auth URL via 'org auth show-sfdx-auth-url'
chore(dev-env): set SF_TEMP_SHOW_SECRETS to work around sf CLI token …
chore(dev-env): set SF_TEMP_SHOW_SECRETS to work around sf CLI token …
chore(dev-env): set SF_TEMP_SHOW_SECRETS to work around sf CLI token …
AndrewStopchenko-SO commentedon Aug 6, 2026
This seems like an improvement from the security perspective. But this harms the UX of using the Salesforce CLI.
Please take the
sf org display --verbosecommand as an example.I tend to create 30-day-long scratch orgs, and then keep
sfdxUrland other for these temporary orgs so that I can import that on another computer and continue my work, if need be.Prior behavior
Previously, I was using the
sf org displayto get the general org details - alias, orgID, userName, expirationDate (without the access token & sfdxUrl). This is the default mode for this command - show me the org details.But when I needed to get both org general details and the sfdxUrl in one place, I had to explicitly include that extra
--verboseflag. So, this is the "elevated" mode for the command, which was explicitly expressed by adding that--verboseflag.New behavior
Now, when I run the
sf org display --verbose, the output includes additional props for the org, but those props are redacted, only containing clues on how to get this information with new commands: [REDACTED] Use 'sf org auth show-sfdx-auth-url' to view.As a result:
--verboseflag became completely useless the way it works now, the added information has low-to-none value.sfdxUrlfor the scratch org, we now must run & parse 2 separate commands.sf org display --verbose -o <orgAlias>command cannot be treated as "yes, I explicitly confirm that I want to see thesfdxUrlfor that org"? How is this different from running that newsf org auth show-sfdx-auth-urlcommand instead?--verboseflag get deprecated if I don't receive the elevated mode output anyway?fix(robot): fall back to sf org auth show-access-token when sf redact…
iowillhoit commentedon Oct 16, 2026
Hey all, regarding:
The temporary
SF_TEMP_SHOW_SECRETSenv var will be removed on October 28th. See #3658 for more details.