"swy exec" Explained: Inputs, Outputs, and Exit Codes

Every other Swytchcode command leads up to one moment: actually running a tool. swy exec is that command, the single execution path that takes a request, runs it through Swytchcode's execution pipeline, and returns the result.

The Two Ways to Call It

swy exec <canonical_id> [flags]
swy exec "<intent>" [flags]

Pass a canonical ID, like github.issues.create, and it executes directly. Pass a plain-English description instead, with no dot in it, and Swytchcode runs a semantic search behind the scenes and shows you an interactive picker to choose the right tool before executing it. This is the same backend that powers swy discover, so you don't strictly need to run discover separately as a human; exec with an intent string does both steps in one.

Passing Input

swy exec accepts input either as CLI flags or as JSON piped through stdin, whichever fits your workflow better. For a quick one-off call, flags are usually simpler. For anything with a larger or more structured payload, piping JSON in avoids having to flatten everything into command-line arguments.

What Happens Underneath

This is where Swytchcode's execution pipeline actually runs. A single swy exec call goes through authentication, input validation against the tool's schema, any policy rules that apply to it, and Swytchcode's built-in retry and idempotency handling, before the request ever reaches the real API. That's the point of having a single execution path: every call gets the same protections, regardless of whether it came from a human typing a command, an MCP-connected editor, or a runtime SDK integration in a custom application.

Before You Run It

Two commands are worth using before you actually execute anything new: swy list tooling confirms the canonical ID you're about to call is actually enabled in your project, and swy info <canonical_id> shows you its full resolved input and output schema, so you know what it expects before you send anything.

Frequently Asked Questions

• What's the difference between a canonical ID and an intent in swy exec? A canonical ID, containing a dot, executes a specific tool directly. A plain-English intent, with no dot, triggers a semantic search with an interactive picker first.
• Can I pass a JSON payload instead of flags? Yes. swy exec accepts input either as CLI flags or as JSON piped through stdin.
• Does swy exec go through the same checks as other ways of calling Swytchcode? Yes. Every request, whether it comes from swy exec, an MCP-connected editor, or a runtime SDK integration, goes through the same execution pipeline: authentication, validation, policy checks, retries, and idempotency.
• How do I know what input a tool expects before running it? Run swy info <canonical_id> first. It shows the tool's fully resolved input and output schema.

Where to Go Next

• exec Reference: the full input and output contract, exit codes, and error handling
• Swytchcode CLI Commands: the complete command reference
• What Is an Execution Layer?: what's actually happening underneath every exec call