This article explains how to create and run commands in the Swif Web App that:

When you create a new command in Swif Web App, you’ll now see three main ways to provide your script:

Note: Existing “custom command” shell-script functionality becomes Run by Command Script, and remains unchanged. The new options are additive.

You’ll land on a multi-step flow. The first step now groups fields into:

When you select Run by Command Script as the Script Source:

Review page:

Use this when you need a quick, direct command without external files or Git.

Learn more at Run by Command Script.

Swif supports running OSQuery commands as a specialized command type. This lets you run SQL‑style queries against devices (Mac, Windows, and Linux) and view the results in a structured table, without writing any custom parsing or UI.

OSQuery commands are most useful when you want to:

You can create reusable OSQuery command templates in the Swif Web App.

For OSQuery templates:

You can then use this template to create and run OSQuery commands across Mac, Windows, and Linux devices.

When you run an OSQuery command (e.g., from a template or directly):

For OSQuery commands specifically:

Note: The content and columns in the result depend entirely on the OSQuery SQL you use. Different queries can return different sets of columns.

OSQuery results are displayed as a structured, readable table instead of a raw text block.

You can open the OSQuery Command Report in two ways:

Both entry points show the same underlying data; the view is consistent between Commands and Device Details.

Because OSQuery queries are fully customizable:

To help you focus on the data that matters:

Example: VS Code Extensions
If you use an OSQuery script that returns VS Code extensions, you may see columns like:

These will appear automatically if the query includes them—no extra configuration needed.

From the OSQuery Command Report you can:

The CSV includes the same dynamic columns and rows you see in the report at the time of download, making it easy to:

When you choose Run by File as the Execution Type:

Important:
If you only provide a build or run command (e.g. python main.py) but do not supply the file and filename, the agent would have to store a randomly named file, which breaks references like python main.py. That’s why an exact filename is required.

For Run by File:

This is intentional: Run by File is optimized for simpler executions, not long-lived scheduled jobs or webhook-driven pipelines.

Use Run by File when you have a single script file and want a straightforward way to execute it without Git.

When you select Run by Git Repo as the Execution Type:

Typical fields in the Run by Git Repo flow include:

These fields are wired to backend capabilities for:

For Run by Git Repo:

This keeps the UX focused on Git + execution itself.

The Review step for Run by Git Repo shows:

The Web App UX is designed to be consistent across all three OS platforms, while allowing for platform-specific constraints to be surfaced.

Across all three, the core behavior & UX remain aligned, so you don’t need to learn a separate workflow per OS.

Once you’ve created a Run by Git Repo command:

The Web App surfaces user-friendly errors for Command reports, including cases like:

Errors are displayed in the existing command/job detail UI, using the same patterns as other runners where possible.

When this feature is working as intended:

Use this quick guide to pick the right option:

In addition to running a single command, you can trigger all manual commands configured on a device group in one click. This is useful when you want to:

Note
This feature runs only manual commands on the group. Scheduled commands are not included and always stay at the end of the list for scheduling purposes.

(If you don’t see this button, make sure the group has at least one manual command configured.)

When you click Run All Manual Commands on a group:

Example:

Clicking Run All Manual Commands on G1 will issue them to devices as:

You can follow progress and logs per device in the usual Commands / Command Report views.

Each group can define its own manual execution order for commands. This order controls:

To change the order:

Behavior details:

When you use Run All Manual Commands:

If you need scheduled behavior (e.g., nightly jobs), continue using scheduling on individual commands. If you need a one-time or ad‑hoc “playbook” run for a group, use Run All Manual Commands.

You can control the order in which Run Manually commands are executed for each group. This order is used both when you run individual manual commands and when you use Run All Manual Commands on that group.