Skip to main content
Install @isox-sh/cli to get the isox binary. The examples below use isox; for a local installation, run npx isox, pnpm exec isox, or yarn isox.

Commands

In isox build web, build is the target name and web is the project name. Use isox run web:build when you prefer an explicit reference, or when the target name conflicts with a built-in CLI command such as add or init.

Executor option overrides

Use --verbose for debug logging and error stacks. Execution commands forward unknown flags to the executor as option overrides:
Hyphenated names become camelCase (--max-warnings becomes maxWarnings). Bare flags are true, --no-<name> is false, numeric values become numbers, and repeated flags become arrays. Executors may validate the options they support. Isox’s own flags, such as --verbose, --config, and --parallel, stay with the CLI. init, add, migrate, reset, and plan reject unknown flags. Use --options for a JSON object when values need explicit types, nested objects, or names that overlap with CLI flags:
Forwarded executor-option flags take precedence over --options. Reserved CLI flags do not override executor options: for example, run-many --parallel=4 with --options '{"parallel":2}' runs up to four projects concurrently while passing parallel: 2 to each executor. In multi-project execution, overrides apply only to the requested target; pre/post targets keep their own options.

Pre and post stages

For affected, plan, and run-many, --pre-targets and --post-targets accept comma- or newline-separated command lists. Use --pre-targets-json and --post-targets-json for exact arrays, including command names that contain commas. For example, --pre-targets-json '["prepare,assets:acc"]' runs prepare,assets with its acc configuration. Do not combine a list flag with its JSON counterpart. See affected projects and CI for stage ordering.

Task output

run-many and executing affected show a live progress footer in interactive terminals. It lists running tasks with elapsed times and counts pending, completed, failed, and cached tasks, plus a completion bar. Cyan indicates running work, green indicates success, and red highlights failures and their diagnostics. Results are indented beneath the stage heading; diagnostics are indented beneath the failed task. Colors respect NO_COLOR, FORCE_COLOR, and terminal support. Completed results stay above the footer:
Successful tool output is hidden by default outside GitHub Actions. Failed and cancelled tasks print their captured diagnostics beneath their result; large output is truncated with an explicit notice. The final summary includes failures, cancellations, and tasks that never started. CI, redirected output, and ISOX_PROGRESS=0 use the same compact task results, cache labels, failure diagnostics, and summaries without cursor animation. In GitHub Actions, every completed task gets a collapsible log group such as ✅ > isox run api:build (1.25s) or ❌ > isox run web:build (failed after 1.25s). Expand the group to inspect that task’s captured stdout and stderr, including successful and cached output. Parallel tasks publish complete groups so their logs stay separate. Large logs retain their bounded tail with a truncation notice. Use --verbose to list the selected projects and stream all tool output with detailed lifecycle messages instead of buffering it into groups.

Named configurations

Commands can define named option overrides in configurations and select a fallback with defaultConfiguration. For example, a command definition can be:
Use your own build script and select a configuration with:
--prod selects production. --config, --configuration, and -c are aliases; an explicit name takes precedence over --prod, then defaultConfiguration applies if neither selects a name. Without any selection or default, only base options are used. An unknown configuration fails with an error. Names retain their exact spelling, including leading zeros in names such as 001. Options are merged at the top level: { ...options, ...configurations[name], ...cliOverrides } after workspace target defaults are merged. Nested objects and arrays are replaced rather than recursively merged. This works with native and Nx executors, including automatically migrated Nx project files. The source configuration and workspace cache retain their original values; the selected options are computed for each invocation. Only one configuration can be selected per invocation. Executor CLI flags override the selected configuration.

Workspace cache

Isox keeps project definitions, dependency analysis, and task results in .isox: affected --all, plan --all, and ordinary run-many selection do not infer dependencies. Execution can request analysis separately for task caching, ordering selected projects with cached outputs, or executor needs. After editing project definitions, target defaults, or discovery rules, run isox reset before a single-project command. Source and import edits do not require a reset. A dependency-analysis cache hit alone does not skip execution. Use --skip-cache to bypass task-result reads and writes. Before running isox reset, stop active builds and recover any needed interrupted-task backups from .isox/tasks. Reset removes all of .isox, including those backups, task results, TypeScript output ownership records, and build locks. Compiled output stays in place. See output recovery. See cache behavior and invalidation and task caching for details.

Current scope

Affected selection follows inferred and explicitly declared dependencies. Parallel execution uses separate child CLI processes, and the GitHub actions distribute exact weighted project lists. See affected projects and CI. Cached builds with declared outputs wait for selected dependencies, even with --parallel=1. Independent projects can run concurrently. Targets with dependsOn expand required tasks outside the selected project list, within each worker’s checkout. Local task caching is opt-in; remote caching and isolation remain on the roadmap.

Upgrade Isox

See Updating Isox and running migrations for the plan, review, install, and run workflow, including custom plans and retries.

Publish migration scripts

See publishing migration scripts for the package registry format, migration API, and build configuration.