Script Execution
Run a Bash or PowerShell script on the AI Kit server.
What it does
Executes a script file already on the server's filesystem, optionally passing arguments. Captures stdout and stderr separately and writes each to memory. Useful for the long tail of integrations the platform does not provide out of the box — system administration tasks, legacy systems, custom command-line tools.
This is also the most powerful and most dangerous integration in the catalog. Treat it like a loaded weapon.
What you configure
| Field | What it controls | Required | Notes |
|---|---|---|---|
| Script path | Absolute path to the script file. | required | The file must already exist on the server. |
| Script type | Bash or PowerShell. | required | Determines which interpreter the platform invokes. |
| Arguments | List of strings passed to the script. | optional | Each item becomes one argument. Pull values from memory when needed. |
| Standard output (memory output) | Where stdout is stored. | required | Capture for downstream parsing or logging. |
| Error output (memory output) | Where stderr is stored. | optional | Capture even when you don't expect errors — it makes debugging much easier. |
📷 SCREENSHOT: The Script Execution step with path, script-type selector, and argument list visible.
Example scenario
Trigger a legacy report. A cron-triggered workflow needs to run a 15-year-old reporting tool. The tool is invoked as a Bash script on the same server. The script is wrapped by a Script Execution step; its stdout is captured and forwarded to an LLM Prompt that summarizes the report for the team email.
Recommendations
- ✅ Keep scripts idempotent where possible — running the same script twice should be safe.
- ✅ Use explicit paths inside the script. Do not rely on the working directory the platform happens to use.
- ✅ Capture stderr even on happy paths. It is the single biggest debugging help when a script misbehaves.
- ✅ Place all scripts in a dedicated, read-only-to-the-platform directory. Reviewing them is then easy.
- ⚠️ Arguments are passed as separate strings, not joined into a command line. This means standard shell quoting is unnecessary — and trying to "escape" values may double-escape them.
- ❌ Do not assemble script paths from memory at runtime. That is path injection. Hard-code the path.
- ❌ Do not run shell-injection-prone constructs (
bash -c "$user_input") inside the script. Treat all arguments as data, never as code. - ❌ Do not use this integration to run anything that requires interactive input. The platform does not provide a TTY.
What to do next
- For HTTP-only integrations: HTTP Request.
- For database operations: Database Query.
- For event-driven runs based on new files: Filesystem Watcher.