Skip to content

This page covers what to do when a swy command or tool execution fails — exit codes, common failure modes, and the diagnostic commands to run first.


Exit codes

Every swy exec (and related) call returns a standard exit code, making it easy to handle failures in scripts and CI/CD pipelines.

Exit CodeMeaning
0Execution completed successfully
1Execution failed
2Invalid input or validation error
3Authentication failed
4Execution blocked by policy
5Tool not found

Common failure modes

Authentication failed (exit code 3)

The account session or provider credentials Swytchcode needs weren’t available or had expired.

  1. Check your account session: swy whoami. If nothing is signed in, run swy login.
  2. Check the provider connection: swy auth status. If the provider isn’t listed, run swy auth connect <provider>.
  3. If you’re using SWYTCHCODE_TOKEN in CI, confirm it’s actually set in the job environment — the CLI reads it only from the process environment, never from a .env file.

See Authentication for the full connect/disconnect/reconnect flow.

Execution blocked by policy (exit code 4)

A rule in .swytchcode/integrations/policies.json matched the request and blocked it before any API call was made.

  1. List your active policies: swy policy list.
  2. Look up the specific violation: swy audit policy (add -n 5 to see the most recent few).
  3. Adjust or remove the offending rule with swy policy add/swy policy remove <id>, then re-validate: swy policy validate.

See policies.json for the full schema and Policy Rules for how conditions are evaluated.

Tool not found (exit code 5)

The canonical ID you executed hasn’t been enabled in this project’s tooling.json.

  1. Confirm what’s actually enabled: swy list tooling.
  2. If the tool exists in an installed integration but isn’t enabled yet, add it: swy add <canonical_id>.
  3. If the integration itself isn’t installed, fetch it first: swy get <project>.

swy sync fails

swy sync [project] re-fetches the workflow/method list from the backend for integrations already installed via swy get - it doesn’t install anything new and doesn’t touch tooling.json. Two errors are common:

no integrations found: run swy get <project>

No project’s integrations have been fetched yet. Run swy get <project> first (or swy bootstrap to fetch everything already declared in tooling.json.integrations), then retry swy sync.

fetch workflows from backend: ...

swy sync reached the network/auth layer but the request itself failed - usually a connectivity problem or an expired session. Check swy whoami and swy doctor --network.

Invalid input or validation error (exit code 2)

The request didn’t match the tool’s input schema before it was sent.

  1. Check the exact schema the tool expects: swy info <canonical_id>.
  2. Re-run with --dry-run to validate inputs without executing: swy exec <canonical_id> --dry-run.

Network or connectivity issues

If a command hangs, times out, or can’t reach the registry:

Terminal window
swy doctor --network

This checks every network endpoint the CLI may contact and reports its current status, alongside your local tooling.json, integration bundles, and auth environment.


Diagnostics reference

CommandWhat it tells you
swy doctorLocal diagnostics: tooling, bundles, auth, permissions, secrets.
swy doctor --networkSame, plus reachability of every network endpoint the CLI may contact.
swy audit network -n 10Recent outbound network calls: host, method, status, duration.
swy audit policy -n 10Recent policy-violation log entries.
swy audit statsLocal execution history: total runs, success rate, last run.
swy whoamiCurrent authentication state.

See the full CLI Reference for every flag and subcommand.


Policy action types

When writing a policies.json rule, only these action types are currently supported:

ActionDescription
AUTH_FAILEDAuthentication failed.
POLICY_BLOCKEDRequest blocked by policy.

Still stuck?

If none of the above resolves it, reach out — include the command you ran, the exit code, and (if relevant) the output of swy doctor.