Invalid JSON parsing when using sf org display --verbose --json output with sf org login sfdx-url

[db-lyon]

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

Invalid JSON parsing when using sf org display --verbose --json output with sf org login sfdx-url

Steps To Reproduce

1. Run sf org display --verbose --json > files/authFile.json
2. Attempt to use the generated file with sf org login sfdx-url --sfdx-url-file files/authFile.json

Expected result

The JSON file should be properly generated and parsed for the login command.

Actual result

The command fails with error:

Error (1): Unexpected token '', "{
 "... is not valid JSON

This suggests there might be an encoding issue when writing the JSON to file.

Additional information

The error appears to be related to file encoding when writing JSON output to a file. The presence of `` characters suggests a potential UTF-8/Unicode encoding mismatch.

Exact terminal output:

PS C:\Users\david\Projects\REDACTED> sf version
@salesforce/cli/2.78.3 win32-x64 node-v22.13.1

PS C:\Users\david\Projects\REDACTED> sf org display --verbose --json > files/authFile.json

PS C:\Users\david\Projects\REDACTED> sf org login sfdx-url --sfdx-url-file files/authFile.json
Error (1): Unexpected token '�', "��{
 "... is not valid JSON

System Information

Reproduced with many environments across 3 devices.

• Shell: PowerShell/ Bash / Terminal
• OS: Windows 11 64-bit / Linux (GitHub Actions & Docker) / macOS)
• CLI Version: @salesforce/cli/2.78.3 win32-x64 node-v22.13.1

{
  "architecture": "win32-x64",
  "cliVersion": "@salesforce/cli/2.78.3",
  "nodeVersion": "node-v22.13.1",
  "osVersion": "Windows_NT 10.0.26100",
  "rootPath": "C:\\Users\\david\\AppData\\Local\\sf\\client\\2.78.3-b3024dd",
  "shell": "powershell",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.2.21 (core)",
    "@oclif/plugin-commands 4.1.20 (core)",
    "@oclif/plugin-help 6.2.25 (core)",
    "@oclif/plugin-not-found 3.2.40 (core)",
    "@oclif/plugin-plugins 5.4.32 (core)",
    "@oclif/plugin-search 1.2.21 (core)",
    "@oclif/plugin-update 4.6.31 (core)",
    "@oclif/plugin-version 2.2.23 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.33 (core)",
    "@oclif/plugin-which 3.2.29 (core)",
    "@salesforce/cli 2.78.3 (core)",
    "apex 3.6.8 (core)",
    "api 1.3.3 (core)",
    "auth 3.6.94 (core)",
    "data 4.0.11 (core)",
    "deploy-retrieve 3.20.0 (core)",
    "info 3.4.39 (core)",
    "limits 3.3.46 (core)",
    "marketplace 1.3.7 (core)",
    "org 5.2.32 (core)",
    "packaging 2.10.3 (user) published 8 days ago (Fri Feb 28 2025)",
    "schema 3.3.50 (core)",
    "settings 2.4.16 (core)",
    "signups 2.6.13 (user) published 29 days ago (Sat Feb 08 2025) (latest is 2.6.18)",
    "sobject 1.4.50 (core)",
    "telemetry 3.6.33 (core)",
    "templates 56.3.38 (core)",
    "trust 3.7.65 (core)",
    "user 3.6.9 (core)",
    "@salesforce/sfdx-scanner 4.9.0 (user) published 40 days ago (Tue Jan 28 2025) (latest is 4.10.0)"
  ]
}

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

[db-lyon]

If I force utf-8 encoding, it seems to work fine:

PS C:\Users\david\Projects\REDACTED> sf org display --verbose --json | Out-File -Encoding utf8 files/authFile.json

PS C:\Users\david\Projects\REDACTED> sf org login sfdx-url --sfdx-url-file files/authFile.json
Successfully authorized devhub-user@REDACTED.com with org ID 00DKj000002YeXAMA0

[WillieRuemmele]

hi @db-lyon - this is an interesting one, and I'm glad you've found a workaround. Because the CLI isn't writing this file, we're not in control of the encoding.

I think you'll have to continue ensuring that it's written in UTF-8 so it can be consumed correctly

I know within many, if not all of the CLI commands, they'll be reading and writing files to utf-8 format