sf check global-view fails immediately on org-information dataset (queryMore error) — EE org with all 4 required permissions

[DedicatedCPA]

Describe the bug

After installing @orgcheck/sfdx-plugin@8.0.5, every sf check subcommand (global-view, apex-classes, hardcoded-urls) errors out within seconds at the org-information dataset with a queryMore SOQL failure. The in-app VF page version of Org Check works fine on the same org with the same user.

Environment

• macOS Darwin 25.2.0, ARM64
• Node v22.13.1
• @salesforce/cli 2.133.4 (also reproduced on 2.125.2 — upgrading did not help)
• @orgcheck/sfdx-plugin 8.0.5 (latest)
• Org: Enterprise Edition, NamespacePrefix=null, ~1700 unmanaged ApexClass, ~2300 CustomField, 178 PermissionSetAssignments matching the plugin's filter. Not unusually large.

Required permissions verified TRUE for the running user

Confirmed via direct SOQL probe (per the fix path described in #714):

PermissionsModifyAllData       True
PermissionsAuthorApex          True
PermissionsApiEnabled          True
PermissionsInstallPackaging    True

Reproduction

sf plugins install @orgcheck/sfdx-plugin    # → installed v8.0.5 ✓
sf check global-view --target-org production --xlsx-file /tmp/x.xlsx --accept-the-terms
sf check apex-classes --target-org production --xlsx-file /tmp/x.xlsx --accept-the-terms
sf check hardcoded-urls --target-org production --accept-the-terms
sf check clear-all-cache --target-org production

All produce identical error within ~3 seconds:

Error (1): An error occurred while running the dataset
(message: There was an error while retrieving the data for this dataset
(either cache issue or dataset.run issue).
... at nt.<anonymous> (.../@orgcheck/api/dist/orgcheck.js:1:141809)

JSON output (--json flag) reveals the underlying cause chain:

recipe: 'org-information',
cause: Error: There was an error while running a SOQL query with the standard queryMore
       at Fa.<anonymous> (.../orgcheck.js:1:266887)

Eliminated as causes

Hypothesis	Tried	Result
Missing 4 required perms	Direct probe of UserPermissionAccess	All 4 = TRUE ✓ (matches #714/#715 fix path)
Stale plugin cache	sf check clear-all-cache then --invalidate-cache flag	Same error
Auth token expired	sf org refresh-token then retry	Same error
--accept-the-terms not set	Set on every call	Same error
Specific subcommand bug	All 3 sf check commands	Identical error
@salesforce/cli version	Upgraded 2.125.2 → 2.133.4	Same error
The org-information primary query is broken	Direct sf data query -q "SELECT Id, Name, IsSandbox, OrganizationType, TrialExpirationDate, NamespacePrefix FROM Organization LIMIT 1"	Returns the row cleanly — so the failing query is something else the dataset bundles, OR a CLI-vs-VF execution-path difference

What still works

The in-app VF page version of Org Check works fine on this org. The Excel export from OrgCheck_App_VFP is clean (we use it as our weekly source today). So the same engine + same Tooling API endpoints + same user identity succeed in-browser; only the CLI plugin path fails.

Asks

1. Could you point me at where the org-information dataset's full query list is composed in packages/orgcheck-api/? I'd like to localize whether a specific query is failing or whether it's a CLI execution wrapper bug.
2. Is there a verbose / trace log flag for the plugin that would expose the exact failing SOQL string before it's sent? SFDX_LOG_LEVEL=debug doesn't surface it.
3. Happy to file a PR if I can pinpoint the offending query/path.

Thanks for the project — the in-app version is a daily driver for us.

[VinceFINET]

list of queries performed by both application (they share the same library --> https://salesforcelabs.github.io/OrgCheck/queries/

normally the logs would be located at .sf
The logs filename look like this on my mac: sf-2026-05-07.log

[VinceFINET]

I see the target org is "production" in case of a production org the plugin should output the following error without a speicifc tag for produciton usage

So try to add "--accept-the-terms" in the command

if it works nice!
but i need to fix the error / message because in your case you didn't have any information.
sorry about that.