Capabilities

The executor implements exactly six capabilities. Each is opt-in twice: once on the WordPress side (the worker's grants) and once on the executor side (the local allowlist in config.toml). A job only runs if both agree.

Key	What it does	Typical use
`shell.run`	Execute a shell command (cmd / powershell / pwsh / bash / sh / auto) with a hard timeout, optional stdin, env overrides, and working directory.	Run scripts, scheduled maintenance, build pipelines, anything you would put in cron.
`fs.read`	Read a file as utf-8 or base64, with a max-bytes guard and best-effort MIME detection.	Hand a config file, a log fragment or a generated artifact back to the workflow.
`fs.write`	Write a file (overwrite / append / create-only), auto-creating parent directories. Base64 input accepted.	Drop a generated report, save a downloaded asset, stage a file before another step picks it up.
`fs.list`	Directory listing, optional recursive, hidden filter, max-entries cap.	Inventory a release directory, drive a per-file loop in the workflow.
`http.request`	Arbitrary HTTP call (any method, any headers, JSON or string body) with timeout. Status code is surfaced as the exit code.	Hit a LAN-only API, call a self-hosted service, fetch from a private host the WordPress server cannot reach.
`system.info`	OS, arch, hostname, CPU count, memory, executor version, uptime, advertised capabilities.	Health checks, populating workflow metadata, fleet inventory.

Every capability accepts an executor-side timeout, refuses to perform operations outside the configured allowlist, and returns a uniform { exit_code, stdout, stderr, output, duration_ms, error } payload that workflow nodes downstream can switch on.