Summary
Workflow shell steps currently execute local shell commands from workflow YAML. This is a powerful and useful capability, but catalog-installed or downloaded workflows should make that execution boundary explicit.
Why
A workflow definition can contain arbitrary shell commands. Users should have a clear prompt or policy gate before a workflow with shell execution runs, especially when the workflow came from a catalog, URL, or third-party source.
Proposed direction
- Add a workflow-level permission such as
requires.permissions.shell: true.
- Reject or pause before running shell steps unless the workflow declares the capability and the user opts in.
- Surface the exact command or a summarized command list before execution.
- Keep local/development workflows ergonomic, but make downloaded/catalog workflows visibly executable.
Acceptance criteria
- Workflows with
type: shell require an explicit declaration or opt-in.
- Existing bundled workflows without shell steps continue to run unchanged.
- Tests cover shell steps with and without the permission declaration.
- Documentation explains that shell workflows execute local code with user privileges.
Summary
Workflow
shellsteps currently execute local shell commands from workflow YAML. This is a powerful and useful capability, but catalog-installed or downloaded workflows should make that execution boundary explicit.Why
A workflow definition can contain arbitrary shell commands. Users should have a clear prompt or policy gate before a workflow with shell execution runs, especially when the workflow came from a catalog, URL, or third-party source.
Proposed direction
requires.permissions.shell: true.Acceptance criteria
type: shellrequire an explicit declaration or opt-in.