`sf org login web` does not work when `SF_CONTAINER_MODE` is set to true

[mhemani-reach]

Note
Before you submit your issue, make sure that:

• You're using the latest version of Salesforce CLI.
• You've searched both open and closed issues for related posts.
• You've used the doctor command to diagnose common issues.
• You understand that GitHub Issues don't adhere to any agreement or SLA.
  • If you require immediate assistance, use official channels such as Salesforce Customer Support.

Summary

I am trying to use sf org login web in the salesforce/cli:latest-slim container; the following environment variables are set SF_CONTAINER_MODE=true && SFDX_CONTAINER_MODE=true. This is documented here to ensure that url is outputted, rather than opening the browser, for the org open or org login web commands. Instead it errors with the following: "Error (SfError): "<%= config.bin %> <%= command.id %>" not supported when authorizing to a headless environment. Use another OAuth flow (e.g., JWT Bearer Flow)."

Steps To Reproduce

• Run the container docker run --rm -it salesforce/cli:latest-slim
• Inside the containerl shell, run echo $SF_CONTAINER_MODE and echo $SFDX_CONTAINER_MODE and observe that the values are set to true
• Inside the container shell, run sf org login web

Expected result

URL should have been outputted to the console as documented in the linked docs

Actual result

Error message: "Error (SfError): "<%= config.bin %> <%= command.id %>" not supported when authorizing to a headless environment. Use another OAuth flow (e.g., JWT Bearer Flow)."

Additional information

System Information

{
  "architecture": "linux-x64",
  "cliVersion": "@salesforce/cli/2.108.6",
  "nodeVersion": "node-v22.19.0",
  "osVersion": "Linux 6.10.14-linuxkit",
  "rootPath": "/usr/local/sf",
  "shell": "bash",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.2.35 (core)",
    "@oclif/plugin-commands 4.1.33 (core)",
    "@oclif/plugin-help 6.2.33 (core)",
    "@oclif/plugin-not-found 3.2.68 (core)",
    "@oclif/plugin-plugins 5.4.47 (core)",
    "@oclif/plugin-search 1.2.31 (core)",
    "@oclif/plugin-update 4.7.7 (core)",
    "@oclif/plugin-version 2.2.33 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.48 (core)",
    "@oclif/plugin-which 3.2.40 (core)",
    "@salesforce/cli 2.108.6 (core)",
    "agent 1.24.13 (core)",
    "apex 3.8.1 (core)",
    "api 1.3.3 (core)",
    "auth 3.9.8 (core)",
    "data 4.0.57 (core)",
    "deploy-retrieve 3.23.3 (core)",
    "info 3.4.88 (core)",
    "limits 3.3.67 (core)",
    "marketplace 1.3.8 (core)",
    "org 5.9.30 (core)",
    "packaging 2.20.5 (core)",
    "schema 3.3.82 (core)",
    "settings 2.4.48 (core)",
    "sobject 1.4.73 (core)",
    "telemetry 3.6.57 (core)",
    "templates 56.3.65 (core)",
    "trust 3.7.113 (core)",
    "user 3.6.38 (core)"
  ]
}

[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.

[stephen-cox-nzx]

Here is a successful workaround based on the info from @mhemani-reach and @stephenlf .

Replace <YourSandboxAlias>, <MyDomainName> and <SandboxName> as appropriate:

export SF_CONTAINER_MODE=false
export SFDX_CONTAINER_MODE=false
alias firefox='xdg-open'
sf org login web --alias <YourSandboxAlias> --instance-url https://<MyDomainName>--<SandboxName>.sandbox.my.salesforce.com
# run a test command
sf apex list log -o <YourSandboxAlias> 

This is using this devcontainer:

{
  "name": "Salesforce Project",
  "dockerFile": "Dockerfile",
  "extensions": [
    "salesforce.salesforcedx-vscode",
    "redhat.vscode-xml",
    "dbaeumer.vscode-eslint",
    "esbenp.prettier-vscode"
  ],
  "settings": {
    "salesforcedx-vscode-apex.java.home": "/usr/lib/jvm/java-11-openjdk-amd64"
  }
}

and this Dockerfile:

FROM docker.io/salesforce/cli:latest-rc-slim
RUN sf plugins install code-analyzer; \
    apt-get update; \
    apt-get install -y xdg-utils

And the devcontainer is running on a remote RHEL8 server with podman as the container runtime, with a local Windows 10 workstation via vscode.

The devcontainer will need additional configuration to:

• support mounting the workspace if SELinux is configured
• mounting the user's SSH etc. for git access
• proxying SSH (if required)

[mhemani-reach]

We're not using the cli in vscode, we're building a custom dev toolchain container. I've tried this workaround using docker run, outside of vscode and it does not work, so this issue still remains

[iowillhoit]

Hey @mhemani-reach, this is a mistake in our documentation. We don't support running sf org login web in a headless environment. Just FYI: If you authenticate another way, running the sf org open command will return a one-time-use url to log in when in a headless env.

We will get the docs updated and I will fix the "<%= config.bin %> <%= command.id %>" in the error message. Those values are not being replaced.

[git2gus]

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

[iowillhoit]

Our tech writer submitted a change to our online documentation to reflect that this is not supported. It will be published in the coming weeks (might be slightly delayed due to Dreamforce)

[bastir85]

@iowillhoit This change seems to break container-based development workflows for us.

It would be great if Salesforce could support this standard use case again. From what I can tell, this would only require two small adjustments in sf-core:
1. Allow the local auth server to bind to 0.0.0.0 (not just localhost).
2. Print the authentication URL to the console instead of forcing the use of a local browser.

These two changes would make containerized authentication workflows fully functional again, without compromising security.

[mhemani-reach]

@bastir85 I agree and opened a feature request here: #3426, please feel free to add additional details