CLI commands are slow in directories using long-expired scratch orgs

[aheber]

Summary

This is a dup and clarification of #3015. If the CLI is invoked in a directory where the configured target-org points to an unresolvable instanceUrl and that org's file indicates the API Version needs to be re-checked (old instanceApiVersionLastRetrieved) then commands are excessively slowed, up to 30+ seconds slower for each invocation.

Steps To Reproduce

I put together the simplest repro I could here along with lots of details. I'll reiterate the important parts in this issue.

https://github.com/aheber/sf-repo-slow-commands

There is an easy way and a hard way.

Easy way

Take any scratch org that is default on a project folder. In that project folder execute sf data query -h and note the wall-clock time it took to execute.

Open the ~/.sfdx/ORG_USERNAME.json file, corrupt the instanceUrl and move the instanceApiVersionLastRetrieved a week or more into the past. Back in the project folder execute again sf data query -h. There should be a 10x+ difference in duration.

Hard way

Obviously that scenario is very contrived. You can take a project folder where the default scratch org is expired or deleted (at least a couple of days prior) but the associated org record hasn't been cleaned out of your auth'd orgs yet. Execute sf data query -h and note that it takes significantly longer than in a directory where the scratch org is valid.

Expected result

If the command I'm running doesn't explicitly need an org, don't do work on that org. Also, if this scenario comes up, don't keep trying the fruitless action for every invocation in the future. I should see error messages, or I should see internal rate limiting on failed adjacent actions like this.

Actual result

The CLI is engaging with orgs that are not in scope for the action and is silently wasting time and slowing down execution without informing the user.

Additional information

I would expect the API version of an org to only be checked when that org is going to be used for a given command, or when it is pertinent to the task at hand. The idea that this API version is being validated no matter what, even for commands that don't use an org or where a different --target-org is being provided, seems like a poor choice. This muddies the context and just seems to waste time and add complexity. (Don't ask how much time I spent related to discovering, troubleshooting, isolating, and replicating this problem)

System Information

VSCode's built-in terminal and Ghostty, both using zsh

{
  "architecture": "darwin-arm64",
  "cliVersion": "@salesforce/cli/2.108.6",
  "nodeVersion": "node-v22.19.0",
  "osVersion": "Darwin 25.0.0",
  "rootPath": "/Users/heber/.local/share/sf/client/2.108.6-399bc9e",
  "shell": "zsh",
  "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[bot]]

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.

[WillieRuemmele]

Hi @aheber - thanks for all of the investigation, I agree that it's weird that the org is refreshed when the command has no requirement for an org. I've verified this behavior

➜  dreamhouse-lwc git:(main) ✗  hub:(GLOBAL - DevHub) scratch:([email protected])
 ➜  time sf data query -h          
Execute a SOQL query.

...

sf data query -h  0.61s user 0.21s system 32% cpu 2.476 total
➜  dreamhouse-lwc git:(main) ✗  hub:(GLOBAL - DevHub) scratch:([email protected])
 ➜  vim ~/.sfdx/[email protected] 
➜  dreamhouse-lwc git:(main) ✗  hub:(GLOBAL - DevHub) scratch:([email protected])
 ➜  time sf data query -h                         
Execute a SOQL query.
...

sf data query -h  0.61s user 0.21s system 4% cpu 18.472 total

[git2gus[bot]]

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

[aheber]

Glad you were able to see it. Thanks!