Inconsistent behavior and documentation for sf org login access-token using the --no-prompt flag

[k-capehart]

Summary

Documentation states that for the sf org login access-token command:

To use the command in a CI/CD script, set the SFDX_ACCESS_TOKEN environment variable to the access token. Then run the command with the --no-prompt parameter.

However doing this on @salesforce/cli/2.17.14 generates the following warning:

Warning: Deprecated environment variable: SFDX_ACCESS_TOKEN. Please use SF_ACCESS_TOKEN instead.

When using SF_ACCESS_TOKEN instead of SFDX_ACCESS_TOKEN, in conjunction with the --no-prompt flag, the user is still prompted to enter the access token, leading me to believe that the SF_ACCESS_TOKEN environment variable is not working as expected.

Steps To Reproduce

Reproduce Warning

1. Open bash terminal
2. $ sf org display --verbose
3. Copy Access Token
4. $ export SFDX_ACCESS_TOKEN=*** given access token from previous step
5. $ sf org login access-token -r [url] -s --no-prompt
6. Authentication should complete successfully but with the following warning:

   Warning: Deprecated environment variable: SFDX_ACCESS_TOKEN. Please use SF_ACCESS_TOKEN instead.

Reproduce issue with SF_ACCESS_TOKEN and --no-prompt

1. Open new bash terminal to reset context
2. $ export SF_ACCESS_TOKEN=*** given access token
3. $ sf org login access-token -r [url] -s --no-prompt
4. The terminal should then prompt for the access-token despite setting it in the environment variable

   ? Access token of user to use for authentication

I verified this in two different salesforce orgs, but I first found it when authenticating in the following org in this repo: https://github.com/k-capehart/sfdc-dev-org

Expected result

Given the warning, the expected result is to not be prompted for an access token when setting the access token in the environment variable SF_ACCESS_TOKEN with the --no-prompt flag.

Actual result

The user is prompted to give the access token anyways

System Information

recreated using bash shell and zsh

sf version --verbose --json

{
  "architecture": "darwin-arm64",
  "cliVersion": "@salesforce/cli/2.17.14",
  "nodeVersion": "node-v20.8.1",
  "osVersion": "Darwin 22.3.0",
  "rootPath": "/opt/homebrew/lib/node_modules/@salesforce/cli",
  "shell": "zsh",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.0.1 (core)",
    "@oclif/plugin-commands 3.0.6 (core)",
    "@oclif/plugin-help 6.0.5 (core)",
    "@oclif/plugin-not-found 3.0.3 (core)",
    "@oclif/plugin-plugins 4.1.7 (core)",
    "@oclif/plugin-search 1.0.6 (core)",
    "@oclif/plugin-update 4.1.3 (core)",
    "@oclif/plugin-version 2.0.6 (core)",
    "@oclif/plugin-warn-if-update-available 3.0.2 (core)",
    "@oclif/plugin-which 3.0.8 (core)",
    "@salesforce/cli 2.17.14 (core)",
    "apex 2.3.20 (core)",
    "auth 2.8.26 (core)",
    "data 2.6.3 (core)",
    "deploy-retrieve 1.20.0 (core)",
    "dev 1.2.0 (user)",
    "info 3.0.1 (core)",
    "limits 3.0.1 (core)",
    "login 2.0.1 (core)",
    "marketplace 1.0.2 (core)",
    "org 2.11.8 (core)",
    "packaging 1.26.3 (user)",
    "schema 3.0.1 (core)",
    "settings 2.0.2 (core)",
    "signups 1.5.5 (user)",
    "sobject 0.2.15 (core)",
    "source 2.11.0 (core)",
    "telemetry 3.1.0 (core)",
    "templates 55.5.18 (core)",
    "trust 3.0.2 (core)",
    "user 2.3.42 (core)",
    "@salesforce/sfdx-scanner 3.17.0 (user)"
  ]
}

[github-actions]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[git2gus]

This issue has been linked to a new work item: W-14507517

[mshanemc]

@k-capehart yep, that's a bug. Thanks for finding it. It's looking for SFDX_ACCESS_TOKEN, which is what you need to use until this release goes out.

The linked PR above will fix the docs AND have it check SF_ACCESS_TOKEN and only use SFDX_ACCESS_TOKEN as fallback.

[k-capehart]

@mshanemc Thanks for the quick PR! For now my CI/CD workflow just sets both, so I'll be able to remove SFDX_ACCESS_TOKEN once I don't need it anymore.

[mshanemc]

cool, that'll reduce warning noise.