docs/tasks/task-configuration.md
This is an exhaustive list of all the configuration options available for tasks in mise.toml or
as file tasks.
All examples are in toml-task format instead of file, however they apply in both except where otherwise noted.
runstring | (string | { task: string, args?: string[], env?: { [key]: string } } | { tasks: string[] })[]The command(s) to run. This is the only required property for a task.
You can mix scripts with task references, and pass optional args and env to referenced tasks:
[tasks.grouped]
run = [
{ task = "t1" }, # run t1 (with its dependencies)
{ task = "build", args = ["--release"], env = { RUSTFLAGS = "-C opt-level=3" } },
{ tasks = ["t2", "t3"] }, # run t2 and t3 in parallel (with their dependencies)
"echo end", # then run a script
]
Simple forms still work and are equivalent:
tasks.a = "echo hello"
tasks.b = ["echo hello"]
tasks.c.run = "echo hello"
[tasks.d]
run = "echo hello"
[tasks.e]
run = ["echo hello"]
run_windowsstring | (string | { task: string, args?: string[], env?: { [key]: string } } | { tasks: string[] })[]Windows-specific variant of run supporting the same structured syntax:
[tasks.build]
run = "cargo build"
run_windows = "cargo build --features windows"
descriptionstringA description of the task. This is used in (among other places)
the help output, completions, mise run (without arguments), and mise tasks.
[tasks.build]
description = "Build the CLI"
run = "cargo build"
aliasstring | string[]An alias for the task so you can run it with mise run <alias> instead of the full task name.
[tasks.build]
alias = "b" # run with `mise run b`
run = "cargo build"
dependsstring | string[] | { task: string, args?: string[], env?: { [key]: string } }[]Tasks that must be run before this task. This is a list of task names or aliases. Arguments can be
passed to the task, e.g.: depends = ["build --release"]. If multiple tasks have the same dependency,
that dependency will only be run once. mise will run whatever it can in parallel (up to --jobs)
through the use of depends and related properties.
[tasks.build]
run = "cargo build"
[tasks.test]
depends = ["build"]
run = "cargo test"
You can pass environment variables to specific dependencies using two syntaxes:
Shell-style inline:
[tasks.test]
depends = ["NODE_ENV=test setup"]
run = "npm test"
[tasks.setup]
run = 'echo "Setting up for $NODE_ENV"'
Structured object format:
[tasks.test]
depends = [
{ task = "setup", env = { NODE_ENV = "test", DEBUG = "true" } }
]
run = "npm test"
The structured format also supports combining env vars with arguments:
[tasks.deploy]
depends = [
{ task = "build", args = ["--release"],
env = { RUSTFLAGS = "-C opt-level=3" } }
]
run = "./deploy.sh"
Note: These environment variables are passed only to the specified dependency, not to the current task or other dependencies.
You can forward a parent task's arguments to its dependencies using <span v-pre>{{usage.*}}</span> templates.
Both the parent and child tasks must define a usage spec for the arguments they accept:
[tasks.build]
usage = 'arg "<app>"'
run = 'echo "building {{usage.app}}"'
[tasks.deploy]
usage = 'arg "<app>"'
depends = [{ task = "build", args = ["{{usage.app}}"] }]
run = 'echo "deploying {{usage.app}}"'
Running mise run deploy myapp passes "myapp" to both deploy and its build dependency.
This also works with the string syntax:
[tasks.deploy]
usage = 'arg "<app>"'
depends = ["build {{usage.app}}"]
run = 'echo "deploying {{usage.app}}"'
And with flags:
[tasks.compile]
usage = 'flag "--target <target>"'
run = 'echo "compiling for $usage_target"'
[tasks.package]
usage = 'flag "--target <target>"'
depends = [{ task = "compile", args = ["--target", "{{usage.target}}"] }]
run = 'echo "packaging for $usage_target"'
Arguments flow through dependency chains — if A depends on B which depends on C, each task can forward its resolved arguments to its own dependencies.
depends_poststring | string[] | { task: string, args?: string[], env?: { [key]: string } }[]Like depends but these tasks run after this task and its dependencies complete. For example, you
may want a postlint task that you can run individually without also running lint:
[tasks.lint]
run = "eslint ."
depends_post = ["postlint"]
[tasks.postlint]
run = "echo 'linting complete'"
Supports the same argument and environment variable syntax as depends.
wait_forstring | string[] | { task: string, args?: string[], env?: { [key]: string } }[]Similar to depends, it will wait for these tasks to complete before running however they won't be
added to the list of tasks to run. This is essentially optional dependencies.
[tasks.lint]
wait_for = ["render"] # creates some js files, so if it's running, wait for it to finish
run = "eslint ."
Supports the same argument and environment variable syntax as depends.
wait_for matches tasks differently depending on whether args or env vars are specified:
wait_for = ["setup"] — matches by name, regardless of args or env overrides. If another task runs depends = ["DEBUG=1 setup"], this will still match and wait for it.wait_for = ["setup arg1"] or wait_for = ["DEBUG=1 setup"] — matches only tasks running with that exact args/env configuration.env{ [key]: string | int | bool }Environment variables specific to this task. These will not be passed to depends tasks.
[tasks.test]
env.TEST_ENV_VAR = "ABC"
run = [
"echo $TEST_ENV_VAR",
"mise run some-other-task", # running tasks like this _will_ have TEST_ENV_VAR set of course
]
tools{ [key]: string }Tools to install and activate before running the task. This is useful for tasks that require a specific tool to be installed or a tool with a different version. It will only be used for that task, not dependencies.
[tasks.build]
tools.rust = "1.50.0"
run = "cargo build"
dirstringmise.toml, or in the case of something like ~/src/myproj/.config/mise.toml, it will be ~/src/myproj.The directory to run the task from. The most common way this is used is when you want the task to execute in the user's current directory:
[tasks.test]
dir = "{{cwd}}"
run = "cargo test"
hideboolfalseHide the task from help, completion, and other output like mise tasks. Useful for deprecated or internal
tasks you don't want others to easily see.
[tasks.internal]
hide = true
run = "echo my internal task"
confirmstring | { message: string, default: string }A message to show before running the task. This is useful for tasks that are destructive or take a long
time to run. The user will be prompted to confirm before the task's own run command executes.
::: warning
confirm only guards the task's own run command. Dependencies (depends) will execute before the confirmation prompt appears. If you need confirmation before dependencies run, add confirm to the dependency tasks themselves, or use run = [{ task = "..." }] instead of depends.
:::
[tasks.release]
confirm = { message = "Are you sure you want to cut a release?", default = "no" }
description = 'Cut a new release'
file = 'scripts/release.sh'
The confirm message supports Tera templates and can reference usage arguments:
[tasks.deploy]
usage = '''
arg "<environment>" help="Environment to deploy to"
flag "--force" help="Force deployment"
'''
confirm = "Deploy to {{ usage.environment }}?{% if usage.force %} (forced){% endif %}"
run = "deploy.sh ${usage_environment}"
rawboolfalseConnects the task directly to the shell's stdin/stdout/stderr. This is useful for tasks that need to accept input or output in a way that mise's normal task handling doesn't support. This is not recommended to use because it really screws up the output whenever mise runs tasks in parallel. Ensure when using this that no other tasks are running at the same time.
In the future we could have a property like single = true or something that prevents multiple tasks
from running at the same time. If that sounds useful, search/file a ticket.
raw_argsboolfalseWhen true, mise does not parse arguments to the task at all — every argument
is passed through verbatim to the underlying command, including --help/-h.
Use this for tasks that act as a thin proxy for a tool which already has its
own argument parser (e.g. next build, Django manage.py, Python scripts
using argparse):
[tasks.manage]
raw_args = true
run = 'python manage.py'
mise run manage --help # forwarded to manage.py, not intercepted by mise
mise run manage migrate --fake # all flags reach manage.py unchanged
Without raw_args, mise intercepts --help and prints its own task help. As
an ad-hoc alternative for individual invocations, you can also use
mise run task -- --help — the -- separator now bypasses mise's usage
parser specifically for --help/-h. Arguments after that separator belong
to the task, so mise run task -- -- --help forwards -- --help to the task.
interactiveboolfalseConnects the task directly to the shell's stdin/stdout/stderr. Interactive tasks acquire an exclusive lock,
ensuring sole access to standard I/O — while an interactive task is running, all other tasks (both interactive
and non-interactive) are blocked. Non-interactive tasks can still run in parallel with each other. This is more
targeted than the broad raw setting which forces single-threaded execution globally (by setting jobs = 1).
sourcesstring | string[]Files or directories that this task uses as input, if this and outputs is defined, mise will skip
executing tasks where the modification time of the oldest output file is newer than the modification
time of the newest source file. This is useful for tasks that are expensive to run and only need to
be run when their inputs change.
The task itself will be automatically added as a source, so if you edit the definition that will also cause the task to be run.
This is also used in mise watch to know which files/directories to watch.
This can be specified with relative paths to the config file and/or with glob patterns, e.g.: src/**/*.rs.
Ensure you don't go crazy with adding a ton of files in a glob though—mise has to scan each and every one to check
the timestamp.
[tasks.build]
run = "cargo build"
sources = ["Cargo.toml", "src/**/*.rs"]
outputs = ["target/debug/mycli"]
Running the above will only execute cargo build if mise.toml, Cargo.toml, or any ".rs" file in the src directory
has changed since the last build.
The task_source_files function can be used to iterate over a task's
sources within its template context.
Entries in sources prefixed with ! are excluded, matching the convention
used by gitignore, watchexec, and rsync. Exclusions affect the freshness
check, the task_source_files template function, and which files
mise watch watches for changes.
[tasks.build]
sources = ["src/**/*.ts", "!src/**/*.test.ts", "!src/**/*.spec.ts", "tsconfig.json"]
run = "npm run build"
Entries are evaluated in order, and the latest matching entry wins. A later
non-negated entry can re-include a file an earlier ! excluded — for example,
["src/**/*.ts", "!src/**/*.test.ts", "src/keep.test.ts"] excludes all
*.test.ts files except src/keep.test.ts.
To include a literal path that begins with !, escape the prefix as \!
(e.g. "\\!important.txt" in TOML).
Use [task_config.input_groups] to define source patterns once and reuse them across tasks. Reference
a group from sources with @group:<name>. Groups can reference other groups; undefined references
and cycles are configuration errors.
Group entries are resolved relative to the config file that defines them, even when a task uses a
different dir. Ordinary entries written directly in sources remain relative to the task directory.
[settings]
experimental = true
[task_config.input_groups]
toolchain = ["rust-toolchain.toml", "Cargo.lock"]
rust = ["Cargo.toml", "src/**/*.rs", "@group:toolchain"]
[tasks.build]
run = "cargo build"
sources = ["@group:rust"]
outputs = ["target/debug/mycli"]
[tasks.test]
run = "cargo test"
sources = ["@group:rust"]
outputs = []
task_config.global_inputs adds source patterns to every task in the config scope. This is useful
for repository-wide configuration and lockfiles that should invalidate all cacheable tasks without
being repeated in each task's sources. Global inputs may also reference named groups.
[task_config]
global_inputs = ["mise.toml", ".github/tool-versions", "@group:lockfiles"]
[task_config.input_groups]
lockfiles = ["Cargo.lock", "pnpm-lock.yaml"]
When a task depends on another task that also has sources defined, and the dependency runs because
its sources changed, the dependent task will also re-run — even if the dependent's own sources haven't
changed. This is useful for monorepo workflows where downstream tasks should be invalidated by upstream
changes:
[tasks."core:build"]
run = "tsc -p packages/core"
sources = ["packages/core/src/**/*.ts"]
outputs = ["packages/core/dist/**/*.js"]
[tasks."frontend:build"]
run = "tsc -p packages/frontend"
sources = ["packages/frontend/src/**/*.ts"]
outputs = ["packages/frontend/dist/**/*.js"]
depends = ["core:build"]
If a file in packages/core/src/ changes, both core:build and frontend:build will run. If nothing
changes, both are skipped.
Note that dependencies without sources (which always run) do not trigger this invalidation —
otherwise sources on the dependent task would be effectively useless.
outputsstring | string[] | { auto = true }{ auto = true }The counterpart to sources, these are the files or directories that the task will create/modify after
it executes.
Entries prefixed with ! exclude matching outputs. As with sources, entries
are evaluated in order, a later entry can re-include a path, and \! escapes a
literal leading bang.
[tasks.build]
run = "npm run build"
sources = ["src/**"]
outputs = ["dist", "!dist/**/*.map", "!dist/.vite/**"]
Excluded files do not participate in output freshness checks and are not stored in task-cache artifacts. If excluded files already exist beneath an output directory when a cached artifact is restored, mise preserves them.
auto = true is an alternative to specifying output files manually. In that case, mise will touch
an internally tracked file based on the hash of the task definition (stored in ~/.local/state/mise/task-outputs/<hash> if you're curious).
This is useful if you want mise run to execute when sources change but don't want to have to manually touch
a file for sources to work.
[tasks.build]
run = "cargo build"
sources = ["Cargo.toml", "src/**/*.rs"]
outputs = { auto = true } # this is the default when sources is defined
cache <Badge type="warning" text="experimental" />{ enabled = bool, env = string[] }{ enabled = false, env = [] }Stores successful task results in a content-addressed local cache and reuses them when the same task
inputs are seen again. Declared filesystem outputs are restored after deletion. Tasks with
outputs = [] cache their successful result and logs without storing filesystem artifacts, which is
useful for checks such as linting, testing, and type checking.
Declaring outputs = [] asserts that the task has no filesystem side effects that a cache hit needs
to reproduce.
Artifact caching requires experimental, at least one
matching source, and either explicit output paths or outputs = [].
outputs = { auto = true }, absolute outputs, and output patterns (including
the body of an exclusion) that escape the task directory are not supported.
[settings]
experimental = true
[tasks.build]
run = "npm run build"
sources = ["package.json", "src/**"]
outputs = ["dist"]
cache = { enabled = true, env = ["NODE_ENV"] }
[tasks.lint]
run = "eslint ."
sources = ["package.json", "src/**"]
outputs = []
cache = { enabled = true }
To enable caching by default for every eligible task in a config scope, set
task_config.cache. Only tasks with at least one source and either explicit output paths or
outputs = [] inherit this default; other tasks remain uncached. A task-local cache value
overrides the scoped default.
[settings]
experimental = true
[task_config.cache]
enabled = true
env = ["NODE_ENV"]
[tasks.build]
run = "npm run build"
sources = ["package.json", "src/**"]
outputs = ["dist"]
[tasks.deploy]
run = "./deploy.sh"
cache = { enabled = false }
The cache key includes source contents, the task definition and arguments, resolved task environment,
the values (or absence) of variables named in cache.env, resolved tool versions, dependency
artifact keys, and the operating system and architecture. Variables inherited from the ambient
process are ignored unless listed in cache.env.
task_config.global_env adds ambient variable names to every enabled task cache in the config
scope, including tasks with a task-local cache value. Unlike the default values under
task_config.cache, these names always compose with task-local cache.env.
[task_config]
global_env = ["CI", "NODE_ENV"]
For cache-enabled tasks, variables named in cache.env or task_config.global_env remain available
when environment inheritance is denied. Disabled and non-cache tasks do not inherit variables
through cache configuration. Use pass_through_env for variables that a task needs at runtime but
which must not affect its cache key, such as short-lived credentials. The scoped
task_config.global_pass_through_env equivalent applies to every task. In mise's default,
non-sandboxed environment mode, ambient variables already pass through; these options matter when
deny_env, deny_all, or the corresponding CLI option is active.
[task_config]
global_pass_through_env = ["CI_JOB_TOKEN"]
[tasks.build]
pass_through_env = ["NPM_TOKEN"]
Pass-through variables can change task behavior without invalidating cached results. Tasks should not use them for values that affect generated outputs. Their values are not added to the key or persisted as cache metadata, but a task can still expose them by writing them to cached output files or logs.
Cache entries are stored under MISE_CACHE_DIR/task-artifacts/v2. Filesystem outputs use
zstd-compressed tar archives; result-only tasks store just their manifest and captured logs. Entries
are included in the existing mise cache clear and mise cache prune behavior. Only successful task
runs are cached. Cache read/write failures are treated as misses and never turn a successful task run
into a failure.
Stdout and stderr are stored as ordered, redacted streams and replayed using the output mode selected for the cache hit. Prefix, interleave, keep-order, timed, replacing, quiet, silent, and per-stream silence therefore apply to replayed output just as they do to live output. Raw and interactive tasks retain inherited terminal I/O and conservatively bypass artifact caching.
Cacheable dependencies contribute their artifact keys to dependent task keys, so a dependent can restore the matching artifact after its dependencies execute, skip, or restore. If a dependency executes without a stable artifact key, its dependents conservatively execute.
shellstringunix_default_inline_shell_args or windows_default_inline_shell_argsThe shell to use to run the task. This is useful if you want to run a task with a different shell than
the default such as fish, zsh, or pwsh. Generally though, it's recommended to use a shebang instead
because that will allow IDEs with mise support to show syntax highlighting and linting for the script.
When the shell is PowerShell (pwsh or powershell), mise passes -NoProfile so your PowerShell
profile is not loaded, matching the non-interactive behavior of sh -c/zsh -c. This avoids profiles
that mutate PATH (for example a mise activation snippet) shadowing a task's own installed tools. Set
windows_powershell_no_profile to false
if your tasks depend on side effects from your profile.
[tasks.hello]
run = '''
#!/usr/bin/env node
console.log('hello world')
'''
quietboolfalseSuppress mise's output for the task such as showing the command that is run, e.g.: [build] $ cargo build.
When this is set, mise won't show any output other than what the script itself outputs. If you'd also
like to hide even the output that the task emits, use silent.
quiet is a verbosity setting and is independent of the output style: it no longer
forces un-prefixed output, so output = "prefix" together with quiet = true keeps the task-name
prefixes while hiding mise's own messages.
silentbool | "stdout" | "stderr"falseSuppress all output from the task. If set to "stdout" or "stderr", only that stream will be suppressed.
outputstringtask.output setting)Output style for this task: prefix, interleave, keep-order, replacing, timed, quiet, or
silent. This is the per-task equivalent of the global task.output setting and is orthogonal to the
quiet/silent verbosity fields, so styles and quietness combine freely
(e.g. output = "prefix" + quiet = true). The quiet/silent values are kept for backwards
compatibility and bundle a style with that verbosity.
usagestring::: tip For comprehensive information about task arguments and the usage field, see the dedicated Task Arguments page. :::
More advanced usage specs can be added to the task's usage field. This only applies to toml-tasks.
[tasks.test]
usage = '''
arg "<file>" help="The file to test" default="src/main.rs"
'''
run = 'cargo test ${usage_file?}'
Both args and flags in usage specs can specify an environment variable as an alternative source for their value. This allows task arguments to be provided through environment variables when not specified on the command line.
The precedence order is:
For positional arguments:
[tasks.deploy]
usage = '''
arg "<environment>" env="DEPLOY_ENV" help="Target environment" default="staging"
arg "<region>" env="AWS_REGION" help="AWS region" default="us-east-1"
'''
run = '''
echo "Deploying to ${usage_environment?} in ${usage_region?}"
'''
Usage examples:
# Using CLI args (highest priority)
mise run deploy production us-west-2
# Using environment variables
export DEPLOY_ENV=production
export AWS_REGION=us-west-2
mise run deploy
# Using defaults (lowest priority)
mise run deploy # deploys to staging in us-east-1
# CLI overrides environment variable
export DEPLOY_ENV=staging
mise run deploy production # deploys to production
For flags:
[tasks.build]
usage = '''
flag "-p --profile <profile>" env="BUILD_PROFILE" help="Build profile" default="dev"
flag "-v --verbose" env="VERBOSE" help="Verbose output"
'''
run = '''
echo "Building with profile: ${usage_profile?}"
echo "Verbose: ${usage_verbose:-false}"
'''
Usage examples:
# Using CLI flags
mise run build --profile release --verbose
# Using environment variables
export BUILD_PROFILE=release
export VERBOSE=true
mise run build
# Mixed usage - env var provides one, CLI provides another
export BUILD_PROFILE=release
mise run build --verbose
File tasks (tasks defined as executable files in mise-tasks/ or .mise/tasks/) also support the env attribute:
#!/usr/bin/env bash
#USAGE arg "<input>" env="INPUT_FILE" help="Input file to process"
#USAGE flag "-o --output <file>" env="OUTPUT_FILE" help="Output file" default="out.txt"
echo "Processing ${usage_input?} -> ${usage_output?}"
Required arguments:
Environment variables can satisfy required argument checks. If an argument is marked as required (using angle brackets <arg>), providing its value through the environment variable specified in the env attribute fulfills that requirement:
[tasks.deploy]
usage = '''
arg "<api-key>" env="API_KEY" help="API key for deployment"
'''
run = 'deploy --api-key ${usage_api_key?}'
# This will fail - no API_KEY provided
mise run deploy
# This succeeds - API_KEY provided via environment
export API_KEY=secret123
mise run deploy
# This also succeeds - provided via CLI
mise run deploy secret123
Vars are values that can be shared between TOML tasks and other Tera-rendered config like tool
versions/options. They are similar to environment variables, but they are not exported to task
processes. Reference them with <span v-pre>{{vars.NAME}}</span>.
[vars]
e2e_args = '--headless'
[tasks.test]
run = './scripts/test-e2e.sh {{vars.e2e_args}}'
Vars can also use value-producing directive forms from [env]:
[vars]
e2e_args = { default = "--headless" }
api_token = { required = "Set api_token in mise.local.toml" }
secret_arg = { value = "--token=abc123", redact = true }
_.file = ".env"
The default form reads from a process environment variable with the same name when it is set and
non-empty; values from [env] are not used for this lookup. The required form must be satisfied by
the process environment or by a later config file like mise.local.toml. Values marked with
redact = true are hidden from task output. Secrets are also supported as
vars.
Tasks can also define task-local vars that override config vars for that task:
[tasks.test]
vars = { e2e_args = "--headed" }
run = './scripts/test-e2e.sh {{vars.e2e_args}}'
Like most configuration in mise, vars can be defined across several files. So for example, you could
put some vars in your global mise config ~/.config/mise/config.toml, use them in a task at
~/src/work/myproject/mise.toml. You can also override those vars in "later" config files such
as ~/src/work/myproject/mise.local.toml and they will be used inside tasks of any config file.
As of this writing vars are only supported in TOML tasks. I want to add support for file tasks, but I don't want to turn all file tasks into tera templates just for this feature.
[task_config] optionsOptions available in the top-level mise.toml [task_config] section. These apply to all tasks which
are included by that config file or use the same root directory, e.g.: ~/src/myproject/mise.toml's [task_config]
applies to file tasks like ~/src/myproject/mise-tasks/mytask. Set cascade = true to also apply the
section to tasks owned by descendant config roots.
task_config.cascadeCascade this config's [task_config] values to descendant config roots. Descendant values override
individual inherited fields. A descendant can set cascade = false to stop inheriting the section.
[task_config]
cascade = true
shell = "bash -c"
This applies to dir, shell, cache, and includes. Inherited include paths remain relative to
the config root where they were defined, allowing a monorepo root to provide one shared task set.
task_config.dirChange the default directory tasks are run from.
[task_config]
dir = "{{cwd}}"
task_config.shellSet the default shell for tasks in this config scope. A task's explicit shell setting takes
precedence, including a shell inherited from a task template. With task_config.cascade = true,
descendant config roots inherit this default and may override it with their own task_config.shell.
[task_config]
shell = "bash -c"
Unlike the global-only
unix_default_inline_shell_args and
windows_default_inline_shell_args
settings, this default is scoped to project tasks and cannot change the interpreter used by hooks,
tool installation, or tasks from another config root.
task_config.cache <Badge type="warning" text="experimental" />Sets the default artifact-cache configuration for tasks in this config scope. The default is only
inherited by cache-eligible tasks with sources and either explicit output paths or outputs = [].
Task-local and task-template cache configuration takes precedence, including
cache = { enabled = false }.
[task_config.cache]
enabled = true
env = ["NODE_ENV", "CI"]
task_config.global_env <Badge type="warning" text="experimental" />Adds ambient environment variable names to the cache key of every cache-enabled task in the config
scope. These values compose with task-local cache.env rather than acting as defaults.
[task_config]
global_env = ["CI", "NODE_ENV"]
task_config.global_pass_through_env <Badge type="warning" text="experimental" />Preserves ambient environment variables when environment inheritance is denied, without adding their values to task cache keys.
[task_config]
global_pass_through_env = ["CI_JOB_TOKEN"]
task_config.global_inputs <Badge type="warning" text="experimental" />Adds config-root-relative source paths and glob patterns to every task in this config scope. Entries
may reference a named input group with @group:<name>.
[task_config]
global_inputs = ["mise.toml", "@group:lockfiles"]
task_config.input_groups <Badge type="warning" text="experimental" />Defines reusable, config-root-relative source groups. Tasks reference them from sources with
@group:<name>. Groups may reference other groups.
[task_config.input_groups]
lockfiles = ["Cargo.lock", "pnpm-lock.yaml"]
rust = ["Cargo.toml", "src/**/*.rs", "@group:lockfiles"]
task_config.includes {#task-config-includes}Set the toml files and file-task directories mise should search when looking for tasks.
[task_config]
includes = [
"tasks.toml", # a task toml file
"mytasks" # a directory containing file tasks
]
When task_config.includes is set, it replaces the default file-task directories for that config scope instead of adding to them.
Include entries are rendered as Tera templates, so they can reference values such as config_root,
env, and resolved vars.
The default file-task directories are:
mise-tasks.mise-tasks.mise/tasks.config/mise/tasksmise/tasksIf you want to keep the defaults and add another directory, include the defaults explicitly:
[task_config]
includes = [
"mise-tasks",
".mise-tasks",
".mise/tasks",
".config/mise/tasks",
"mise/tasks",
"mytasks",
"tasks.toml",
]
For local and monorepo task discovery, mise uses the nearest config file that defines
task_config.includes. When the parent has task_config.cascade = true, its includes are inherited
until a child defines its own. A child config's includes replaces both the defaults and any
inherited includes for that directory.
Global config files are loaded independently, so each global config file uses its own task_config.includes or the default directories if includes is unset.
Entries are evaluated in order, and when more than one include defines a task with the same name the last entry in the list wins.
This applies uniformly to directory, toml-file, and git:: includes, so to override a task coming from a git:: include with a local one, list the local directory after the git:: entry:
[task_config]
includes = [
"git::https://github.com/myorg/shared-tasks.git//tasks", # remote task…
".mise/tasks", # …is overridden by the local one with the same name
]
If using included task toml files, note that they have a different format than the mise.toml file. They are just a list of tasks.
The file should be the same format as the [tasks] section of mise.toml but without the [task] prefix:
::: code-group
task1 = "echo task1"
task2 = "echo task2"
task3 = "echo task3"
[task4]
run = "echo task4"
vars = { target = "linux" }
:::
If you want auto-completion/validation in included toml tasks files, you can use the following JSON schema: https://mise.en.dev/schema/mise-task.json
You can include directories or individual task toml files from git repositories using the git:: URL syntax:
::: code-group
[task_config]
includes = [
"git::ssh://[email protected]/myorg/shared-tasks.git//tasks?ref=v1.0.0",
"git::ssh://[email protected]/myorg/shared-tasks.git//tasks/release.toml?ref=v1.0.0",
]
[task_config]
includes = [
"git::https://github.com/myorg/shared-tasks.git//tasks?ref=main",
"git::https://github.com/myorg/shared-tasks.git//tasks/release.toml?ref=main",
]
:::
URL format: git::<protocol>://<url>//<path>?ref=<ref>
Required fields:
protocol: The git protocol (ssh or https).url: The git repository URL.path: The path to a directory or a .toml task file in the repository.Optional fields:
ref: The git reference (branch, tag, commit). Defaults to the repository's default branch.When path points at a directory, mise loads both executable file tasks and any .toml task files inside that directory. When path points at a single .toml file, only that file is loaded.
Included .toml files use the task toml file format (the keys are task names — there is no [tasks.…] prefix). The repository will be cloned and cached in MISE_CACHE_DIR/remote-git-tasks-cache. Tasks from the include will be loaded as if they were local. You can disable caching with MISE_TASK_REMOTE_NO_CACHE=true or the --no-cache flag.
mise supports monorepo-style task organization with target path syntax. Enable it by setting monorepo_root = true in your root mise.toml.
For complete documentation on monorepo tasks including:
See the dedicated Monorepo Tasks documentation.
redactions <Badge type="warning" text="experimental" />string[]Redactions are a way to hide sensitive information from the output of tasks. This is useful for things like API keys, passwords, or other sensitive information that you don't want to accidentally leak in logs or other output.
A list of environment variables to redact from the output.
redactions = ["API_KEY", "PASSWORD"]
Running the above task will output echo [redacted] instead.
You can also specify these as a glob pattern, e.g.: redactions.env = ["SECRETS_*"].
[vars] optionsSee Vars.
The following settings control task behavior. These can be set globally in ~/.config/mise/config.toml or per-project in mise.toml: