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 roo<F17>pt

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.

In Nash 0.11.9, cwd information from TLS, SSH or Unix proxy domains is not used to discover local project files, even if it claims the local hostname. Nash skips project .nash.toml and VS Code task discovery for those panes; bundled nd global tasks remain available. A direct Unix-socket mux pane can use a validated local cwd for project discovery. A remote cwd shown in the UI does not grant access to matching paths on the GUI's host.

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.