[JamBalaya56562]

From #4792. Not Closes — that thread asks for three things and this is one of them (see "Not in this PR").

Problem

A task_config.includes entry that points at nothing is dropped in silence. Measured on v2026.8.2:

$ cat mise.toml
[task_config]
includes = ["./does-not-exist.toml", "./real-tasks.toml"]

$ mise tasks ls
hello

$ echo $?
0

Nothing on stderr, and nothing at --verbose either — grepping the verbose output for the missing filename returns zero lines. mise tasks validate is just as quiet:

$ mise tasks validate
✓ All 1 task(s) validated successfully

So a typo, a renamed file, or a moved directory makes tasks disappear with no way to find out why. The failure mode is silent absence: the tasks that did load look completely normal.

The site is expand_task_include, whose literal-path branch is:

if resolved.exists() {
    vec![resolved]
} else {
    vec![]
}

The glob branch immediately above it already warn!s when expansion fails, so the silence is specific to literal paths.

What this changes

warn_once! at load time, and a missing-include issue in mise tasks validate:

$ mise tasks
mise WARN  task_config.includes entry 'gone.toml' does not exist: ~/proj/gone.toml
hello

$ mise tasks validate
1 task(s) validated with 1 issue(s):

  ⚠ 1 warning(s)

Task: task_config.includes
  ⚠ Include path does not exist: ~/proj/gone.toml [missing-include]
      Tasks from this include are silently absent. Remove it from task_config.includes or create the path.

Both go through one new pure function, missing_literal_include, so the two paths cannot drift.

The built-in defaults must not warn — this is the whole risk of the change

When includes is unset, default_task_includes() supplies five directories — mise-tasks, .mise-tasks, .mise/tasks, .config/mise/tasks, mise/tasks — and they go through the same expansion. A project has at most one of them, so warning unconditionally would print four or five lines on essentially every mise invocation.

task_include_patterns_for_dir already returns a "used the defaults" flag; load_tasks_from_configs did not, so this adds one there (uses_default_includes) and gates the warning on it. There is an e2e assertion for exactly this, because without it the regression is invisible in review: a project with a real mise-tasks/ and no [task_config] must produce no warning.

Globs are deliberately excluded

includes = ["tasks/*.toml"] matching nothing is the normal state of a directory whose task files have not been written yet, so a glob is never reported. Only literal paths are.

git:: includes are untouched

They branch to resolve_git_url_to_path before expansion (config/mod.rs), so an include that has not been fetched yet cannot be mistaken for a missing local path.

Noise

mise hook-env and mise env do not load tasks, so this cannot reach the prompt. Within a run, the same config is loaded once per directory and each resolves the include to the same absolute path, so keying warn_once! on the rendered message collapses a monorepo's worth of repeats to one line.

Severity is Warning, and that is a judgement call

mise tasks validate exits non-zero only on Error, so this does not fail CI. That matches the existing granularity — missing-directory and not-executable are warnings, missing-file is an error — and an include may legitimately be optional in a shared config.

If you would rather this fail CI, it is a one-line change (Severity::Warning → Severity::Error in validate_task_includes). I have no strong view; the reporter's use case is automation, which argues for Error, but silently breaking someone's mise tasks validate in CI argues against.

Verification

• Unit tests for missing_literal_include cover: existing file, existing directory, absent path, glob (never reported), and an absolute include not being joined onto the include root. They live in config's existing #[cfg(unix)] test module, so they run in CI, not on my box (Windows).
• New e2e e2e/tasks/test_task_broken_include covers the warning, the validate issue in both human and --json output, a directory include being satisfied, the defaults not warning, and a zero-match glob not warning.
• cargo fmt --all, cargo clippy --all-targets clean on the touched files.

One existing test needed a change, and it is worth a look

e2e/tasks/test_task_edit_nested_names captured a path with 2>&1:

includes = ["tasks.d", "existing-tasks"]     # tasks.d deliberately absent
TASK_PATH5=$(mise tasks edit dotted --path 2>&1)
assert "printf '%s' \"$TASK_PATH5\"" "$PWD/existing-tasks/dotted"

The new warning landed in the capture and broke the equality. I changed it to take stdout only, which is what a path capture wants anyway — but the reason it fired is worth your judgement rather than mine.

That block tests a real pattern: "select the first existing directory in include order", which task_creation_dir_for_dir supports deliberately. Under that reading a missing entry is a candidate that lost, not a mistake, and warning about it is noise. Under the reading this PR takes — a missing include means tasks are silently absent — it is exactly what the user should hear.

I went with the second because task_config.includes is documented as "files and directories mise should search", not as a candidate list, and the candidate behaviour is specific to where mise tasks add puts a new task. But if you would rather the loader stay quiet when some other include in the same list did resolve, that is a small change and I am happy to make it.

The other three blocks in that file with missing includes are unaffected: they assert with assert_fail_contains, which tolerates extra stderr.

Not in this PR

• mise tasks include <path>, the command Add subcommand for mise tasks to include in the global config.toml an external tasks.toml #4792 actually asks for. Worth knowing before anyone builds it: setting includes replaces the five default directories rather than adding to them, so a naive append command silently drops the user's existing tasks. Measured — a project whose only task lives in mise-tasks/ loses it the moment one includes entry is written. Any such command has to seed the defaults on first write, or refuse. That is a design decision, not a mechanical addition.
• Removing dead includes (Add subcommand for mise tasks to include in the global config.toml an external tasks.toml #4792's third ask). Easier to shape once detection exists.
• git:: includes whose fetch fails. Different code path, different problem.

Summary by CodeRabbit

• New Features

  • Task validation now detects and reports missing task include paths.
  • Validation output includes missing-include issues in standard and JSON formats.
  • Missing explicit includes generate warnings, while glob patterns, built-in directories, and empty matches remain quiet.

• Documentation

  • Updated task validation documentation to describe checks for nonexistent include paths.

• Bug Fixes

  • Improved handling and diagnostics for relative and absolute task include paths.
  • Refined task editing output to avoid including unrelated warnings in reported paths.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

Task include handling now detects missing literal paths during loading and validation. It excludes globs, Git URLs, and built-in defaults. Documentation and end-to-end tests cover the new diagnostics and supported include forms.

Changes

Task include validation

Layer / File(s)	Summary
Include detection and classification src/config/mod.rs	Missing literal includes are detected relative to the effective include root. Globs, Git URLs, existing paths, and built-in defaults are excluded.
Task loading warnings src/config/mod.rs	Task loading emits one warning per missing explicit literal include before expansion.
Validation, documentation, and regression coverage src/cli/tasks/validate.rs, docs/cli/tasks/validate.md, mise.usage.kdl, e2e/tasks/test_task_broken_include, e2e/tasks/test_task_edit_nested_names	mise tasks validate reports missing-include warnings. Help and usage documentation describe the check. End-to-end tests cover missing files, directories, defaults, globs, JSON output, and stderr handling.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Sequence Diagram(s)

sequenceDiagram
  participant TasksValidate
  participant Config
  participant TaskIncludes
  participant Diagnostics
  TasksValidate->>Config: collect task configuration
  Config->>TaskIncludes: inspect explicit includes
  TaskIncludes-->>Config: return missing literal paths
  Config-->>TasksValidate: provide missing include paths
  TasksValidate->>Diagnostics: emit missing-include warnings

Loading

Possibly related PRs

• jdx/mise#11106: Both modify task include handling in src/config/mod.rs.
• jdx/mise#11206: Both modify task-include loading and discovery in src/config/mod.rs.

Poem

A rabbit checks each task path,
Finds missing files along the path.
Globs hop by, defaults stay still,
Warnings bloom when paths will not fill.
Tests thump softly: all is bright! 🐇

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: warnings for nonexistent task_config.includes paths.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/config/mod.rs`:
- Around line 4641-4650: Update the warn_once! call in the
missing_literal_include handling to deduplicate by the resolved missing path
rather than the raw include string. Use missing/display_path(&missing) as the
warning key while preserving the existing warning text and behavior.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited), Organization UI (inherited)

Review profile: CHILL

Plan: Pro Plus

Run ID: 2cb65e97-93b2-46e5-b3c7-7f71d9998af7

📥 Commits

Reviewing files that changed from the base of the PR and between 566f807 and 7992cf4.

📒 Files selected for processing (5)

• docs/cli/tasks/validate.md
• e2e/tasks/test_task_broken_include
• mise.usage.kdl
• src/cli/tasks/validate.rs
• src/config/mod.rs

[github-actions]

This PR currently has failing checks. If this continues for 7 days, it will be closed automatically.

This is warning day 1 of 7.

Please update the PR when you have a chance. Feel free to reopen or create a new PR if it is closed and you'd like to continue working on it.

This comment was generated by an automated workflow.

[greptile-apps]

Greptile Summary

This PR adds diagnostics for explicit, nonexistent task_config.includes paths while excluding default directories, glob patterns, and Git includes.

• Emits a deduplicated warning while loading task sources.
• Adds structured missing-include warnings to task validation.
• Adds unit and end-to-end coverage and updates validation documentation.

Confidence Score: 5/5

The PR appears safe to merge because no blocking failure remains within the eligible follow-up review scope.

No blocking failure remains.

Important Files Changed

Filename	Overview
src/config/mod.rs	Adds shared missing-literal-include detection, load-time warnings, default-include suppression, and focused unit tests.
src/cli/tasks/validate.rs	Adds structured warning-level validation issues for missing explicit task include paths.
e2e/tasks/test_task_broken_include	Covers load-time and validation diagnostics, existing directories, default includes, and unmatched globs.
e2e/tasks/test_task_edit_nested_names	Keeps path capture limited to stdout now that task loading may emit the intended warning on stderr.
docs/cli/tasks/validate.md	Documents missing task include detection among validation checks.
mise.usage.kdl	Updates generated CLI usage content to describe task include validation.

_{Reviews (3): Last reviewed commit: "feat(tasks): warn when a task_config.inc..." | Re-trigger Greptile}

[jdx]

Thanks for working on this, and especially for calling out the ambiguity in the PR description.

I don't think a missing task_config.includes entry should produce a warning. These entries are search candidates, and missing candidates can be intentional—for example, the existing mise tasks edit behavior explicitly selects the first existing directory from an ordered include list. The documentation also recommends explicitly listing all five default directories when adding a custom include; most of those directories are normally absent, so this change would make the documented configuration noisy.

This is consistent with similar config and environment-file search paths, which quietly skip absent candidates. Since mise currently has no way to distinguish an optional include from a typo, validation would have the same false positives. If we want required includes in the future, I think that needs explicit syntax rather than being inferred from whether a literal path exists.

Because removing the load-time and validation warnings leaves no substantive change here, I'm going to close this. Thanks again for the careful investigation and tests.

AI-assisted — Tool: Codex; model: unavailable/unavailable; version: unavailable.