[JamBalaya56562]

Using windows_executable_extensions the way it is documented breaks a task that worked a moment
earlier. mise-tasks/hello.sh, with a shebang:

A) default settings
> mise run hello
ran-via-bash                       # the shebang picks bash

B) "sh" added to windows_executable_extensions, nothing else changed
> mise run hello
[hello] ERROR %1 is not a valid Win32 application. (os error 193)

The shebang is never read in B. mise decided the OS could start the file and handed it to
Command::new.

Why

can_execute_directly subtracted a fixed interpreter-only list — ["ps1", "vbs"] — from
windows_executable_extensions, and treated whatever remained as something CreateProcess can
start. Against the shipped default that leaves exe/bat/cmd/com, which is exactly the set
the OS can start, so the shape was right for the default list and wrong for every other one. The
setting is user-editable; the list of what Windows can launch is not.

Two callers depend on that answer, and both are affected:

• task_executor's file-task path — the reproduction above.
• backend::is_spawnable, which decides whether a tool's binary can be spawned from a path.

The change

The two questions are separate, so they are asked separately and ANDed:

• Does mise treat this extension as executable? windows_executable_extensions, which a user
  may narrow.
• Can the OS start it? A new fixed OS_LAUNCHABLE_EXTENSIONS — exe and com natively, bat
  and cmd because std routes those through cmd.exe with escaped arguments — which a user may not
  widen.

For the default list the answers are identical to before (exe/bat/cmd/com yes,
ps1/vbs no), which is precisely why the old shape looked correct. INTERPRETER_ONLY_EXTENSIONS
is gone: can_execute_directly was its only non-test use.

A file that is now correctly rejected falls through to shell_from_shebang, then
shell_from_extension, then default_file_shell — the existing chain, which is how the .sh
above finds bash again.

Deliberately unchanged

• shell_from_extension gains no extensions. Which interpreters mise should know by default is
  a separate call; a user who adds sh is served by the shebang.
• The default windows_executable_extensions.
• An extension with neither a shebang nor a mapping — a .py with no shebang, say — still
  fails. It reaches cmd /c rather than CreateProcess, so os error 193 becomes a failure from
  the configured default shell. Better located, still a failure.
• The whitelist is not configurable. It describes what the OS can do, not a policy.

Tests

• src/file.rs: os_can_launch_extension accepts exe/com/bat/cmd case-insensitively and
  rejects ps1/vbs along with extensions a user might add (sh, py, js) and the empty
  string; can_execute_directly gives the same answers as before for the default list.
• src/task/task_executor.rs: the shell_from_extension invariant now derives its extensions from
  the setting minus the OS-launchable list instead of a hand-kept constant, so a new default
  extension without an interpreter mapping is caught too. It asserts the derived set is non-empty
  so the loop cannot pass vacuously.
• e2e-win/task_executable_extensions.Tests.ps1: the reproduction above, both halves, plus a
  .cmd task to show the whitelist still launches what it should. The script body is printf, so
  the assertion can only pass through bash.

No unit test overrides windows_executable_extensions: Settings::override_with mutates
process-wide state that other tests in the same binary read through is_executable. The widened
setting is covered in e2e-win, in its own process — which is also how the bug was measured.

Verification

Measured on 2026.8.2 windows-x64: the A/B pair above. Existing tests were checked against the new
predicate rather than assumed —
is_spawnable_rejects_interpreter_only_extensions_case_insensitively asserts .PS1 is rejected,
which the whitelist still does, and which_in_dirs_ignores_missing_candidates uses tool.exe.

cargo fmt was run locally. The build, clippy and the test suite were not — those are left to
CI, so behaviour after the fix rests on the measurement above and on the tests rather than on a
running binary.

Found while auditing Windows behaviour, the same pass that produced #12007, #12008, #12012, #12013,
#12014 and #12016. No existing issue or discussion covers it.

Summary by CodeRabbit

• New Features

  • Improved Windows task launching with reliable support for .exe, .com, .bat, and .cmd files.
  • User-configured executable extensions are now limited to formats Windows can launch directly.
  • Shell scripts continue to use shebang-based execution by default, while explicitly configured shell extensions remain supported.

• Bug Fixes

  • Improved case-insensitive extension handling for Windows task execution.
  • Fixed direct execution behavior for command files and other supported Windows executables.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

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

Review profile: CHILL

Plan: Pro Plus

Run ID: 2bc71453-97ea-4352-8316-d93cff0f2ac3

📥 Commits

Reviewing files that changed from the base of the PR and between 3c8ae04 and b2d8130.

📒 Files selected for processing (1)

• src/file.rs

🚧 Files skipped from review as they are similar to previous changes (1)

• src/file.rs

---

📝 Walkthrough

Walkthrough

Windows direct task execution now accepts only OS-launchable extensions. Tests cover configured extensions, interpreter mappings, Bash shebang execution, and direct CMD execution.

Changes

Windows executable handling

Layer / File(s)	Summary
OS launchability detection src/file.rs	can_execute_directly now checks the fixed Windows whitelist exe, com, bat, and cmd with case-insensitive matching. Tests cover launchable and non-launchable extensions.
Task execution validation src/task/task_executor.rs, e2e-win/task_executable_extensions.Tests.ps1	Interpreter-extension coverage now derives from configured settings and OS launchability. Windows end-to-end tests cover Bash and CMD task execution.

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

Merge Risk: ⚪ Minimal · up to b2d81

The change restores shebang-based execution for configured non-native extensions while preserving supported Windows launchable extensions, with no actionable merge-blocking risk remaining after normal checks and review.

Sequence Diagram(s)

sequenceDiagram
  participant WindowsTask
  participant task_executor
  participant can_execute_directly
  participant Shell
  WindowsTask->>task_executor: execute task
  task_executor->>can_execute_directly: check extension
  can_execute_directly-->>task_executor: direct-launchable or interpreter-required
  task_executor->>Shell: run through mapped interpreter when required

Loading

Possibly related PRs

• jdx/mise#11923: Shares Windows executable handling and task-execution behavior.
• jdx/mise#12008: Implements related Windows executable-extension detection behavior.

Suggested reviewers: greptile-apps

Poem

A rabbit checks extensions bright,
.cmd hops into direct flight.
Bash waits where interpreters call,
Shebangs guide the task through all.
Whitelisted paths keep launches right.

🚥 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 fix: validating configured extensions against Windows OS-launchable extensions.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
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.}

[greptile-apps]

Greptile Summary

The PR separates user-configured executable-extension policy from the fixed set of extensions Windows can launch directly.

• Adds a case-insensitive Windows OS-launchable extension predicate for exe, com, bat, and cmd.
• Routes configured script extensions through the existing shebang, extension, and default-shell fallback chain.
• Adds Windows unit and end-to-end coverage for shell-script fallback and native command-file execution.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
src/file.rs	Replaces the interpreter-only blacklist with a fixed Windows direct-launch allowlist while retaining the configured-extension check.
src/task/task_executor.rs	Updates the interpreter-mapping invariant test to derive non-launchable extensions from current default settings.
e2e-win/task_executable_extensions.Tests.ps1	Adds isolated Windows coverage proving configured .sh tasks use their shebang while .cmd tasks remain directly launchable.

_{Reviews (5): Last reviewed commit: "fix(file): stop trusting a configured ex..." | Re-trigger Greptile}