CLI commands are slow in directories using long-expired scratch orgs #3425
Description
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)"
]
}