Salesforce CLI secrets: fix your pipeline before October 28

Your deployment can authenticate successfully and still send an invalid token to its next API call. A pipeline that extracts credentials from the JSON output of sf org display can receive a redacted value instead of the token it expects.

Salesforce has scheduled the removal of SF_TEMP_SHOW_SECRETS for October 28, 2026, when the change reaches the CLI’s latest release. Audit scripts that read authentication output before updating the runner. Replace secret extraction with the dedicated authentication commands, or let a supported CLI command make the API request itself.

The announcement says the release candidate became available on October 21. As of this article’s publication, October 28 is still a scheduled release date. A pinned older installation won’t change simply because the calendar turns; a runner that installs latest can pick up the change on its next build.

Find the script that consumes the credential

Search the repository, shared pipeline templates, container build files, and runner configuration for SF_TEMP_SHOW_SECRETS. Also search for org display, accessToken, and sfdxAuthUrl. A script may depend on the old output even if somebody else configured the environment variable.

For a local inventory, this search prints matching filenames rather than entire lines that might contain credentials:

rg -l --hidden \
  -g '!.git/**' -g '!node_modules/**' -g '!.env*' \
  'SF_TEMP_SHOW_SECRETS|org display|accessToken|sfdxAuthUrl' .

Review those files in your editor. Record the owner, how the CLI version is installed, and what consumes the extracted value. Include scheduled exports and release reporting scripts alongside the metadata deployment job.

A nonempty-string check is insufficient. The literal [REDACTED] is nonempty, so a weak validation step can pass while the API request fails later. Move the check next to credential retrieval and make the error describe that boundary without printing the value.

Retrieve only the credential the job needs

Salesforce’s supported replacements are sf org auth show-access-token, show-sfdx-auth-url, and show-user-password. The migration announcement documents structured output and a noninteractive option for unattended use. Existing stored SFDX Auth URLs remain usable with sf org login sfdx-url.

For a Bash job that needs an access token, the following adapts the documented command and adds local validation. Run it inside the existing job’s secret-handling controls, with shell tracing disabled:

set +x
set -euo pipefail

sf_access_token="$(
  sf org auth show-access-token \
    --target-org my-org --json --no-prompt |
  jq -er '.result.accessToken |
    select(type == "string" and length > 0 and . != "[REDACTED]")'
)"

# Pass sf_access_token directly to the authorized API client.
# Never echo it or upload it as a build artifact.
# Remove it when the dependent request finishes.
unset sf_access_token

Replace my-org with the intended authenticated alias. This example only retrieves and validates the value; it doesn’t make an API call. Keep the dependent request between retrieval and cleanup in your own job.

If the next step already has a CLI equivalent, consider removing token extraction. Salesforce’s Winter ‘27 developer guide identifies sf api request rest and sf api request graphql as generally available. Check their help and supported inputs before replacing a custom HTTP client.

Test the request that follows the login

Use a non-production org and the same runner image as your release pipeline. Run the candidate CLI version with SF_TEMP_SHOW_SECRETS unset. A successful login proves only that authentication worked; exercise the read, deploy, or test operation that previously consumed the extracted token.

Include two failure cases. An unknown org alias should stop the job at retrieval, and a missing or redacted value should stop it before the API client runs. The log should identify the failed step while keeping credentials out of stdout, error reports, and uploaded artifacts.

Check all paths that capture command output. A command can stop printing a secret to the console while a wrapper still saves its JSON into a debug artifact. If the audit finds exposed credentials, revoke or rotate the affected credential and review its access through your OAuth token governance process.

Remove the workaround from runner configuration after the migrated job passes. Record the tested CLI version and the pipeline commit so another maintainer can reproduce the result.

Keep the other authentication deadlines separate

This change affects how the local CLI reveals credentials. The SOAP login permission change and OAuth username-password retirement affect different authentication paths. Fixing one doesn’t complete the others.

Start with the job that installs the newest CLI on every run. It has the shortest distance between an upstream release and an unexpected failure in your own deployment.