Scope & Overrides

Nash tasks can originate from multiple sources. Understanding the merge behavior is key to managing tasks across your workflow.

Task Sources

Tasks are loaded in the following order, with later sources overriding earlier ones:

Bundled — defaults read from Nash's binary (since 0.10.0)
Global — tasks.toml in your Nash configuration directory
Project — .nash.toml in the current project root

VS Code tasks from .vscode/tasks.json are converted and appended separately, not merged into native tasks. Print bundled entries with nash config defaults tasks.toml.

Merge Rules

When the same id appears in multiple sources:

In Nash 0.10.0, higher layers replace only the fields they set.
Execution fields command, argv, and step replace one another.
enabled = false removes an entry; a higher layer can set enabled = true to restore it. keys = [] removes its shortcuts.
Entries with different IDs remain available.
Project overrides affect task execution, but project keys do not create bindings. Shortcuts use the bundled and global layers.

See Commands and tasks for override examples and migration from older copied defaults.

#  tasks.toml (global)
[[task]]
id = "build"
title = "Build (Global)"
command = "make"

#  .nash.toml (project)
[[task]]
id = "build"
title = "Build (Project)"
command = "cargo build --release"

In this example, running the "Build" task uses the project-level definition (cargo build --release). Other global fields remain inherited unless the project overrides them too.

VS Code Task Conversion

Nash can consume VS Code's tasks.json and make those tasks available in the nash command palette. Conversion applies the following mapping:

VS Code Field	Nash Equivalent
`label`	`title`
`type`	Used to determine execution strategy
`command`	`command` (shell) or `argv` (process)
`args`	Appended to `command` or `argv`
`options.cwd`	`cwd`
`options.env`	`env`
`presentation.panel`	Influences `keep` behavior

Converted tasks have a [VSCode] prefix on their IDs and titles and run in the current pane. They do not override a native task with the same label.

Practical Example

A typical project setup might look like:

# ~/.config/nash/tasks.toml — personal defaults
version = 1

[[task]]
id = "lint"
title = "Lint"
command = "eslint . --max-warnings=0"

[[task]]
id = "test"
title = "Run Tests"
command = "jest --no-coverage"

# /my-project/.nash.toml — project overrides
version = 1

[[task]]
id = "test"
title = "Run Tests"
command = "jest --no-coverage --testPathPattern='src'"
env = { CI = "false" }

[[task]]
id = "deploy-staging"
title = "Deploy to Staging"
target = "new_tab"
command = "scripts/deploy.sh staging"

Here the global lint task is inherited as-is, while the test task is overridden with a project-specific variant. The deploy-staging task is only available within the project.