feat(blocks): add execute command block for self-hosted shell execution

[waleedlatif1]

Summary

• Add Execute Command block that runs shell commands on the host machine via child_process.exec
• Gated behind EXECUTE_COMMAND_ENABLED feature flag, self-hosted only (blocked on hosted)
• Supports variable injection (<block.output>, {{ENV_VAR}}, <variable.name>)
• Configurable working directory and timeout
• Returns stdout, stderr, exitCode — non-zero exits are data, not errors (matches n8n behavior)
• Added env vars to Helm chart and .env.example

Type of Change

• New feature

Testing

Tested manually

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[cursor]

PR Summary

High Risk
Introduces a new capability to execute arbitrary host shell commands via child_process.exec; even with self-hosted-only feature gating, misconfiguration or untrusted inputs could lead to severe security impact.

Overview
Adds a new self-hosted-only Execute Command block and tool (execute_command_run) that executes host shell commands via a new /api/tools/execute-command/run endpoint, returning stdout/stderr/exitCode and supporting <block.field>, {{ENV_VAR}}, and <variable.name> interpolation.

Introduces EXECUTE_COMMAND_ENABLED / NEXT_PUBLIC_EXECUTE_COMMAND_ENABLED feature flags (including env schema + Helm + .env.example) to gate both server execution and UI visibility, wires the block into the block/tool registries and executor handler registry, and adds a TerminalIcon. Also fixes workflow variable resolution in function execution to normalize variable name comparisons.

^{Written by Cursor Bugbot for commit 5782b68. Configure here.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Mar 5, 2026 11:14pm

[waleedlatif1]

@cursor review

[waleedlatif1]

@greptile

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

[greptile-apps]

Greptile Summary

This PR adds an Execute Command block that runs arbitrary shell commands on the host machine via child_process.exec, gated behind an EXECUTE_COMMAND_ENABLED feature flag that is automatically blocked on hosted environments. It follows the project's established block/tool/handler architecture and integrates well with the existing variable-resolution and executor infrastructure.

Several issues raised in the prior review round appear to have been addressed: the index-based string splicing (slice + splice) eliminates the $-pattern corruption from String.prototype.replace; getSafeBaseEnv() prevents server secrets from leaking to child processes; isMaxBuffer detection is now independent of error.killed; a parsedTimeout > 0 guard replaces the earlier falsy-default gap; and block outputs are now declared including the error field.

Four key concerns remain that should be addressed:

1. Timeout / MAX_DURATION mismatch — MAX_DURATION = 210 s is the hard ceiling for the route, but the block UI allows users to configure any positive timeout. A timeout greater than 210,000 ms will cause the route function to be killed by the platform before exec's own timeout fires, orphaning the child process on the host and leaving the client with an unhandled 504 error.

2. Silent envVars mismatch for blocked key names — envVars is used for {{ENV_VAR}} template substitution (unfiltered) and as the child process environment (filtered by filterUserEnv). Workflow env vars whose names collide with BLOCKED_ENV_KEYS (e.g. PATH, HOME) will correctly substitute in templates but will be silently dropped from the child process environment, creating confusing debugging experiences where template resolution and actual runtime behavior diverge.

3. workingDirectory ignores variable-reference syntax — only command is passed through resolveCommandVariables; the working directory field silently treats <block.output> or {{ENV_VAR}} as literal path strings, despite the command field and wand prompt documenting these syntaxes.

4. Dead-code throw in the handler — the throw new Error branch when !result.success && !result.output is unreachable because the route always populates output. This diverges from the stated n8n-style philosophy (treat all failures as data) and could mislead future maintainers.

The feature is self-hosted only and behind a feature flag, which limits blast radius. However, the timeout/MAX_DURATION gap and the envVars dual-use mismatch are real operational concerns that should be addressed before wide adoption.

Confidence Score: 3/5

• Safe to merge for self-hosted users who understand shell execution risks, but orphaned child processes from timeout/MAX_DURATION mismatch and silent envVars filtering require attention before wide adoption.
• All four verified comments identify real issues in the code: (1) user-configured timeouts exceeding the platform's 210s MAX_DURATION cause orphaned processes, a genuine operational problem; (2) envVars filtering is silent and asymmetric between template resolution and child process environment, causing user confusion; (3) workingDirectory lacks variable syntax support despite command field and wand prompt encouraging it; (4) the handler has unreachable code that violates stated philosophy. However, the feature is gated behind EXECUTE_COMMAND_ENABLED and self-hosted only, significantly limiting blast radius. The security model (getSafeBaseEnv isolation, filterUserEnv protection) is sound. These issues require fixes but are not blockers for a self-hosted-only feature.
• apps/sim/app/api/tools/execute-command/run/route.ts (timeout ceiling and envVars filtering asymmetry), apps/sim/executor/handlers/execute-command/execute-command-handler.ts (dead-code throw branch), apps/sim/blocks/blocks/execute-command.ts (workingDirectory variable syntax mismatch)

_{Last reviewed commit: 5782b68}

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[greptile-apps]

envVars used for both template resolution and child process environment — silently filters blocked keys in one path but not the other

The same envVars object serves two purposes: (1) template substitution in resolveCommandVariables (lines 353–360) and (2) as the child process environment via filterUserEnv (line 263). When a workflow env var has a name in BLOCKED_ENV_KEYS (e.g., PATH, HOME), it will:

• Resolve correctly in template patterns like echo {{PATH}}
• Be silently dropped from the child process environment

Concrete example: User sets envVars.PATH = "/custom/bin" and writes command echo {{PATH}} && echo $PATH. The resolved command becomes echo /custom/bin && echo $PATH, but when executed, the process inherits the server's PATH from getSafeBaseEnv(), not the user's custom value. This is a confusing contradiction within a single command.

Consider documenting in bestPractices that workflow env vars matching keys in BLOCKED_ENV_KEYS are available for template substitution but will NOT be injected into the child process environment.

[greptile-apps]

User-configured timeout can exceed MAX_DURATION, orphaning the child process

MAX_DURATION = 210 seconds is the Next.js maximum route duration. However, a user can configure any positive timeout value via the block UI (line 68 in execute-command.ts). When user-configured timeout exceeds MAX_DURATION * 1000:

1. exec starts the child process with the user's timeout (e.g., 300,000 ms).
2. At 210 seconds, the Next.js/hosting platform kills the route handler.
3. The child process continues running on the host as an orphan process.
4. The client receives a 504 / connection-closed error instead of the clean "Command timed out" response.

This is a real operational problem for self-hosted deployments with long-running build scripts or migrations. Consider enforcing an upper bound on timeout less than MAX_DURATION:

const MAX_ALLOWED_TIMEOUT_MS = (MAX_DURATION - 10) * 1000 // 200 s, leaving buffer
const timeout = Math.min(
  parsedTimeout > 0 ? parsedTimeout : DEFAULT_EXECUTION_TIMEOUT_MS,
  MAX_ALLOWED_TIMEOUT_MS
)

[greptile-apps]

workingDirectory silently ignores variable-reference syntax

Unlike the command field, workingDirectory is passed directly to exec as cwd (route.ts line 364) without going through resolveCommandVariables. This means <blockName.output>, {{ENV_VAR}}, and <variable.name> syntax in the working directory field are treated as literal path strings rather than being substituted.

This is asymmetric and confusing because:

• The command field prominently documents both syntaxes (lines 17–18)
• The wand prompt instructs the LLM to use these syntaxes (lines 40–41)
• Users or the LLM are likely to write workingDirectory: <filesBlock.outputPath> and be surprised when it doesn't resolve

Consider either:

1. Passing workingDirectory through resolveCommandVariables before using it as cwd, or
2. Adding a note to bestPractices explicitly stating that variable-reference syntax is not supported in the Working Directory field.

[greptile-apps]

Unreachable throw branch — handler already returns data on failure

The route handler always returns an output object regardless of the success value (timeout case: route.ts lines 376–386, maxBuffer case: lines 388–398, error case: lines 408–418). This means result.output is never falsy when !result.success, making the throw new Error(...) branch at line 53 unreachable in practice.

The dead branch could mislead future readers into thinking there is a failure mode where no output is returned. More importantly, it diverges from the stated n8n-style philosophy that "non-zero exits are data, not errors" — failures should be returned as structured data, not thrown.

Consider removing the unreachable branch and always returning the output for consistency:

if (!result.success) {
  return {
    ...(result.output ?? { stdout: '', stderr: '', exitCode: 1 }),
    error: result.error || 'Command execution failed',
  }
}

return { ...result.output, error: null }

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}