`sf org sandbox resume` fails with no meaningful information

[kyle-blair]

Summary

The sf org sandbox resume fails with a status/exit code of 68 but with no other information about what went wrong or how to address it. What does 68 mean? A quick search for 68 mentions it might be related to certificates.

Steps To Reproduce

1. Authenticate to a production org.
2. Create a sandbox.
3. Once the sandbox is ready, run sf org resume sandbox --wait 0 --json --name sandbox --target-org production.
4. In the sandbox, change the configuration so that authentication will fail. I removed my current device's IP address from my profile's allowed IP ranges, but be aware this will lock you out of the sandbox.
5. Rerun the same command from step 3 sf org resume sandbox --wait 0 --json --name sandbox --target-org production.

Expected result

If the command fails (non-zero exit code), then there should be, at a minimum, some indication of what failed included in the output. Ideally, the output also includes why this failure might have occurred and options to address the situation.

Actual result

The command's exit code/status is 68 but that is the only information provided as to why the command failed. The login actually failed due to restricted IP, but the cli output made it seem like the polling simply timed out. The logic around timeout and 68 status is indeed masking actual errors.

{
  "status": 68,
  "result": {
    "attributes": {
      "type": "SandboxProcess",
      "url": "/services/data/v60.0/tooling/sobjects/SandboxProcess/..."
    },
    "Id": "...",
    "Status": "Completed",
    "SandboxName": "...",
    "SandboxInfoId": "...",
    "LicenseType": "DEVELOPER",
    "CreatedDate": "2026-01-20T19:27:03.000+0000",
    "CopyProgress": 100,
    "SandboxOrganization": "...",
    "SourceId": null,
    "Description": "",
    "EndDate": "2026-01-23T09:22:08.000+0000",
    "Features": null
  },
  "warnings": []
}

Additional information

System Information

{
  "architecture": "darwin-arm64",
  "cliVersion": "@salesforce/cli/2.117.7",
  "nodeVersion": "node-v24.11.1",
  "osVersion": "Darwin 24.6.0",
  "rootPath": "/Users/user/.nvm/versions/node/v24.11.1/lib/node_modules/@salesforce/cli",
  "shell": "bash",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.2.39 (core)",
    "@oclif/plugin-commands 4.1.38 (core)",
    "@oclif/plugin-help 6.2.36 (core)",
    "@oclif/plugin-not-found 3.2.73 (core)",
    "@oclif/plugin-plugins 5.4.54 (core)",
    "@oclif/plugin-search 1.2.36 (core)",
    "@oclif/plugin-update 4.7.16 (core)",
    "@oclif/plugin-version 2.2.36 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.53 (core)",
    "@oclif/plugin-which 3.2.42 (core)",
    "@salesforce/cli 2.117.7 (core)",
    "agent 1.26.0 (core)",
    "apex 3.9.5 (core)",
    "api 1.3.6 (core)",
    "auth 3.9.26 (core)",
    "data 4.0.66 (core)",
    "deploy-retrieve 3.24.5 (core)",
    "info 3.4.100 (core)",
    "limits 3.3.74 (core)",
    "marketplace 1.3.8 (core)",
    "org 5.9.53 (core)",
    "packaging 2.24.2 (core)",
    "schema 3.3.90 (core)",
    "settings 2.4.54 (core)",
    "sobject 1.4.81 (core)",
    "telemetry 3.6.71 (core)",
    "templates 56.4.0 (core)",
    "trust 3.7.113 (core)",
    "user 3.6.44 (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.

[github-actions]

Hello @kyle-blair 👋 None of the versions of sf you shared match the latest release.

Shared: 2.117.7
Latest: 2.119.8

Update to the latest version of Salesforce CLI (docs) and confirm that you're still seeing your issue.
You can also try the rc and nightly releases! (docs)

After updating, share the full output of sf version --verbose --json

[kyle-blair]

{
  "architecture": "darwin-arm64",
  "cliVersion": "@salesforce/cli/2.119.8",
  "nodeVersion": "node-v24.11.1",
  "osVersion": "Darwin 24.6.0",
  "rootPath": "/Users/user/.nvm/versions/node/v24.11.1/lib/node_modules/@salesforce/cli",
  "shell": "bash",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.2.39 (core)",
    "@oclif/plugin-commands 4.1.38 (core)",
    "@oclif/plugin-help 6.2.36 (core)",
    "@oclif/plugin-not-found 3.2.73 (core)",
    "@oclif/plugin-plugins 5.4.54 (core)",
    "@oclif/plugin-search 1.2.36 (core)",
    "@oclif/plugin-update 4.7.16 (core)",
    "@oclif/plugin-version 2.2.36 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.53 (core)",
    "@oclif/plugin-which 3.2.42 (core)",
    "@salesforce/cli 2.119.8 (core)",
    "agent 1.26.2 (core)",
    "apex 3.9.5 (core)",
    "api 1.3.7 (core)",
    "auth 4.1.0 (core)",
    "data 4.0.67 (core)",
    "deploy-retrieve 3.24.7 (core)",
    "info 3.4.100 (core)",
    "limits 3.3.74 (core)",
    "marketplace 1.3.8 (core)",
    "org 5.9.57 (core)",
    "packaging 2.24.5 (core)",
    "schema 3.3.90 (core)",
    "settings 2.4.54 (core)",
    "sobject 1.4.81 (core)",
    "telemetry 3.6.71 (core)",
    "templates 56.4.0 (core)",
    "trust 3.7.113 (core)",
    "user 3.6.45 (core)"
  ]
}

[kyle-blair]

I should add that we currently see a spike in the number of 68 statuses from completed sandboxes, which is unusual.

[WillieRuemmele]

Hi @kyle-blair - it seems like exit 68 is for polling timeout - you should be able to check the sandbox refresh status from your "controlling" org, either a devhub or prod?

[kyle-blair]

@WillieRuemmele We noticed a spike in these 68 exits even for completed sandboxes, so there definitely seems to be a bug. You can see in the example I posted, it has an EndDate populated.

[kyle-blair]

And there are several other open issues around the --wait mechanism. I'm getting quite suspicious of it.

#3452
#3393

[kyle-blair]

The code you linked also doesn't seem particularly deterministic. I bet it is masking errors, since it's the first check in the catch block. With a wait of zero, I imagine this.pollingTimeout may be true to begin with, or immediately be set to true, then if the process throws an actual error it is assumed to be a timeout.

[kyle-blair]

I'll look through the code some more, thanks for linking it.