fix: improve Windows Rust environment setup for build workflows

[Syroxivoss]

Hello Tailwind CSS team,

I’m submitting this contribution set with a strong focus on reviewability, project fit, and contributor usefulness.

Instead of opening one large pull request, I deliberately split the work into three smaller PRs so each change can be reviewed on its own merits and verified independently:

• fix/windows-rust-env
• feat/hocus-variant
• docs/contributor-guides

I chose that structure intentionally. Since this repository spans the compiler core, multiple adapters, the Node bridge, and the oxide scanner, broad PRs can become difficult to review quickly. I wanted each change to stay close to the layer that actually owns the behavior, and I wanted the validation story for each PR to remain simple and concrete.

The first PR, fix/windows-rust-env, is focused on contributor workflows on Windows. The specific problem I addressed was that contributors could still hit cargo ENOENT failures during build workflows even when Rust was already installed, simply because the current shell environment did not expose the expected Rust binaries cleanly. To address that, I added environment-aware helper scripts, introduced a contributor-facing preflight check, and routed the relevant build/test commands through the same corrected Rust-aware execution path. I also updated the oxide package build commands to use that path consistently. The purpose of this PR is narrow: make the Windows contributor workflow more reliable without changing the actual compiler behavior.

The second PR, feat/hocus-variant, is a small but real product-facing change in Tailwind itself. I added a built-in hocus: variant that applies styles on both focus and hover. I kept the implementation aligned with existing variant behavior by preserving the @media (hover: hover) guard for hover output while still emitting direct focus selectors. I also updated the relevant focused tests so that the feature is covered both at the variant-output level and in @apply error reporting. The goal here was to contribute something user-visible while still keeping the scope compact and easy to reason about.

The third PR, docs/contributor-guides, is documentation-focused, but not generic documentation. I rewrote the contributor-facing guidance so it reflects how this repository actually works: the relationship between the core compiler, the adapter layer, @tailwindcss/node, the oxide scanner, integration fixtures, and the playground workflows. I specifically tried to avoid boilerplate open-source text and instead wrote the docs around the real workflows a contributor would hit in this monorepo, especially around setup, validation, Windows-specific issues, Rust, Bun, Playwright, and deciding where a change belongs before editing code. My intention was to improve contributor onboarding without adding docs that feel detached from the codebase.

Across the three PRs, I tried to keep a few principles consistent:

• small review surfaces instead of one large mixed change
• behavior changes made at the owning layer instead of through cross-cutting workarounds
• explicit and narrow validation for each PR
• no unrelated refactors mixed into functional fixes
• contributor documentation written specifically for this repository rather than copied generic guidance

Validation for the work included:

• pnpm run check:env
• cd crates/node && pnpm run build
• pnpm exec vitest run packages/tailwindcss/src/variants.test.ts packages/tailwindcss/src/index.test.ts -t "hocus|variant that does not exist"

For the docs work, I also manually reviewed the command paths, local guide links, and contributor flow to make sure the text matched the actual repository structure and workflows.

This is one of my first serious open-source contribution sets at this level of repository complexity, so I approached it conservatively: understand the local code path first, make the change in the nearest owning layer, validate the smallest relevant slice, and split the work into focused PRs instead of asking maintainers to parse one broad patch. If any of these changes should be scoped even more tightly, rewritten in a different style, or moved to a different layer, I’m happy to revise them.

Thank you for your time and review.

[coderabbitai]

Walkthrough

Adds a scripts infrastructure and updates npm scripts to route tasks through it. New files: scripts/rust-env.mjs (centralizes Rust/Cargo env and tool checks), scripts/preflight.mjs (environment validation for different contexts), and scripts/run-task.mjs (maps task names to command sequences, runs preflight, then executes commands). Root and crates/node/package.json npm scripts were refactored to invoke node ./scripts/run-task.mjs <task> (or equivalent path) instead of calling tooling directly.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change—improving Windows Rust environment setup—and is specific, concise, and directly related to the changeset's core purpose.
Description check	✅ Passed	The description is directly related to the changeset, providing clear context about the Windows Rust environment problem, the specific scripts added, and the purpose of the changes.
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.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

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 and usage tips.}

[coderabbitai]

Actionable comments posted: 3

🧹 Nitpick comments (4)

scripts/rust-env.mjs (1)

31-40: Consider validating command to avoid surprising shell parsing on Windows.

With shell: isWindows, spawnSync on Windows runs the command through cmd.exe, so a command name containing spaces or shell metacharacters would be interpreted by the shell. Since all current call sites pass fixed literals (cargo, rustc, rustup, bun), this is not an active issue — just something worth keeping in mind if commandExists ever gets used with user-supplied input.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/rust-env.mjs` around lines 31 - 40, The commandExists function
currently calls spawnSync(command, ['--version'], { shell: isWindows, ... }),
which can allow shell parsing surprises on Windows if command contains spaces or
metacharacters; update commandExists to validate or sanitize the command before
passing it to spawnSync (e.g., assert it matches a safe token pattern like
/^[A-Za-z0-9._-]+$/ or throw/return false for unsafe input) and/or avoid shell
mode for untrusted inputs by ensuring shell is false when command is not a
simple token; locate the commandExists function and modify the validation around
the command parameter and the spawnSync invocation to enforce this check.

scripts/run-task.mjs (1)

56-66: cwd = process.cwd() is intentional but worth documenting.

Spawned commands inherit the invoker's cwd rather than the repo root. This is needed so crates/node's napi build … passthrough runs in the oxide crate, but it also means predefined tasks like build (turbo …) will fail if someone ever invokes run-task.mjs from a subdirectory. A short comment above const cwd = process.cwd() explaining this contract would help future contributors.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/run-task.mjs` around lines 56 - 66, Add a short explanatory comment
above the const cwd = process.cwd() declaration explaining that the script
intentionally uses the invoker's working directory (process.cwd()) so spawned
commands inherit the caller's cwd — this is required so tasks like the
`crates/node` `napi build …` passthrough run inside the oxide crate; also note
the trade-off that running run-task.mjs from a subdirectory can cause predefined
tasks like `build` (e.g., `turbo …`) to fail. Reference the existing symbol
const cwd = process.cwd() and keep the comment concise.

scripts/preflight.mjs (1)

1-1: Dead code: unused spawnSync import and run() helper.

The locally defined run function (lines 68–75) is never called anywhere in this file — all subprocesses are executed via commandExists / readInstalledRustTargets from ./rust-env.mjs. The spawnSync import on line 1 is likewise unused. Safe to remove.

🧹 Proposed cleanup

-import { spawnSync } from 'node:child_process'
 import fs from 'node:fs'
 import path from 'node:path'
 import process from 'node:process'
@@
-function run(command, args) {
-  return spawnSync(command, args, {
-    cwd: root,
-    encoding: 'utf8',
-    stdio: ['ignore', 'pipe', 'pipe'],
-    env: rustEnv,
-  })
-}
-
 function formatList(items) {

Also applies to: 68-75

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/preflight.mjs` at line 1, Remove the dead code by deleting the unused
import and helper: remove the top-level import "spawnSync" (import { spawnSync }
from 'node:child_process') and delete the locally defined helper function named
run (the function defined around lines with signature run(...) that spawns a
subprocess). Ensure no other references to spawnSync or run remain; if any
helper logic from run is needed, consolidate calls to existing utilities
(commandExists / readInstalledRustTargets) instead.

package.json (1)

35-48: LGTM — task names match entries in predefinedCommands.

All routed tasks (build, dev, test, test:integrations, test:ui, vite, nextjs, plus the check:env → preflight.mjs doctor entry) are defined in scripts/run-task.mjs and scripts/preflight.mjs contexts, so none will hit the unknown-task error path.

One small note: tdd (vitest --hideSkippedTests) and bench (vitest bench) still invoke vitest directly and therefore bypass the Rust preflight. That's likely intentional for fast iteration, but if the motivation of this PR is to surface Rust env issues early on Windows, consider whether tdd should also run through run-task.mjs (or at least check:env) to avoid the original cargo ENOENT class of failures.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@package.json` around lines 35 - 48, The tdd script currently invokes vitest
directly ("tdd": "vitest --hideSkippedTests") and bypasses the preflight checks;
change it to route through the existing runner or preflight so Rust/Windows env
errors are detected early—either update the "tdd" script to call node
./scripts/run-task.mjs tdd (and implement a tdd case in scripts/run-task.mjs
that runs vitest) or prepend the preflight check by making "tdd" run node
./scripts/preflight.mjs doctor && vitest --hideSkippedTests; reference the "tdd"
and "bench" npm scripts and the run-task.mjs / preflight.mjs entrypoints when
locating where to implement the routing.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@scripts/preflight.mjs`:
- Around line 98-100: The message shown when hasDefaultCargoBin() is true is
misleading because that function is true whenever cargoBin exists (including
when CARGO_HOME was explicitly set); update the string construction to say "Rust
appears to be installed at the detected Cargo directory (<path>), so rerun the
command through the repo scripts such as `pnpm build` or `pnpm run check:env`"
and inject the cargoBin value (or equivalent detected path variable) into the
message; locate the ternary using hasDefaultCargoBin() and replace the hardcoded
"default cargo directory" text with the new phrasing that includes the cargoBin
path.

In `@scripts/run-task.mjs`:
- Around line 30-44: The unknown-task check runs after passthrough mutation so a
bogus task name can be ignored when passthrough starts with "--"; move
validation earlier by checking that task exists in predefinedCommands (i.e.
ensure predefinedCommands[task] is defined) and that task is truthy before you
compute or mutate the commands variable or apply the passthrough logic, or
alternatively add an explicit guard that if passthrough form is used and
predefinedCommands[task] is undefined you emit the unknown-task error/warning;
update the logic around the commands/passthrough handling (symbols:
predefinedCommands, task, passthrough, commands) to validate first and only then
build or override commands.

In `@scripts/rust-env.mjs`:
- Around line 23-28: The current Windows branch sets RUSTUP_TOOLCHAIN to a
hardcoded 'stable-x86_64-pc-windows-msvc' which breaks ARM64 Windows hosts;
update the env object handling for RUSTUP_TOOLCHAIN in scripts/rust-env.mjs so
it either omits RUSTUP_TOOLCHAIN entirely (letting rustup choose the default) or
derives the triple from Node's process.arch (e.g., map 'arm64' ->
'stable-aarch64-pc-windows-msvc' and default to the x86_64 triple for other
arches) instead of always forcing the x86_64 triple; change the RUSTUP_TOOLCHAIN
assignment in the Windows branch accordingly.

---

Nitpick comments:
In `@package.json`:
- Around line 35-48: The tdd script currently invokes vitest directly ("tdd":
"vitest --hideSkippedTests") and bypasses the preflight checks; change it to
route through the existing runner or preflight so Rust/Windows env errors are
detected early—either update the "tdd" script to call node
./scripts/run-task.mjs tdd (and implement a tdd case in scripts/run-task.mjs
that runs vitest) or prepend the preflight check by making "tdd" run node
./scripts/preflight.mjs doctor && vitest --hideSkippedTests; reference the "tdd"
and "bench" npm scripts and the run-task.mjs / preflight.mjs entrypoints when
locating where to implement the routing.

In `@scripts/preflight.mjs`:
- Line 1: Remove the dead code by deleting the unused import and helper: remove
the top-level import "spawnSync" (import { spawnSync } from
'node:child_process') and delete the locally defined helper function named run
(the function defined around lines with signature run(...) that spawns a
subprocess). Ensure no other references to spawnSync or run remain; if any
helper logic from run is needed, consolidate calls to existing utilities
(commandExists / readInstalledRustTargets) instead.

In `@scripts/run-task.mjs`:
- Around line 56-66: Add a short explanatory comment above the const cwd =
process.cwd() declaration explaining that the script intentionally uses the
invoker's working directory (process.cwd()) so spawned commands inherit the
caller's cwd — this is required so tasks like the `crates/node` `napi build …`
passthrough run inside the oxide crate; also note the trade-off that running
run-task.mjs from a subdirectory can cause predefined tasks like `build` (e.g.,
`turbo …`) to fail. Reference the existing symbol const cwd = process.cwd() and
keep the comment concise.

In `@scripts/rust-env.mjs`:
- Around line 31-40: The commandExists function currently calls
spawnSync(command, ['--version'], { shell: isWindows, ... }), which can allow
shell parsing surprises on Windows if command contains spaces or metacharacters;
update commandExists to validate or sanitize the command before passing it to
spawnSync (e.g., assert it matches a safe token pattern like /^[A-Za-z0-9._-]+$/
or throw/return false for unsafe input) and/or avoid shell mode for untrusted
inputs by ensuring shell is false when command is not a simple token; locate the
commandExists function and modify the validation around the command parameter
and the spawnSync invocation to enforce this check.

🪄 Autofix (Beta)

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 UI

Review profile: CHILL

Plan: Pro

Run ID: 7789ec75-bcdf-4edd-bac7-d5f58d76df00

📥 Commits

Reviewing files that changed from the base of the PR and between f62597a and bc68c66.

📒 Files selected for processing (5)

• crates/node/package.json
• package.json
• scripts/preflight.mjs
• scripts/run-task.mjs
• scripts/rust-env.mjs

[coderabbitai]

Actionable comments posted: 2

🧹 Nitpick comments (2)

scripts/run-task.mjs (1)

37-48: Passthrough without -- silently drops intermediate commands' args.

For multi-command tasks (test, test:ui) the non--- branch only appends passthrough args to the last command (line 46: index !== commands.length - 1). So pnpm test -- --reporter=verbose applies --reporter=verbose to vitest but not to cargo, which is probably intentional, however the inverse is also true: there is no way to forward flags to cargo test via this script. Consider documenting this behavior (or splitting into separate tasks like test:rust / test:js) so contributors aren't surprised.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/run-task.mjs` around lines 37 - 48, The current logic only appends
passthrough args to the last command (variables: passthrough, commands; mapping
callback with index !== commands.length - 1), which prevents forwarding flags to
earlier commands (e.g., cargo). Change the mapping so passthrough is appended to
every command when the user omits a `--` (or alternatively add a selector flag
to target a specific command); update the commands = commands.map(...) callback
to always return [entry[0], [...entry[1], ...passthrough]] instead of only for
the last index, and ensure behavior is documented in the task help/comments.

scripts/preflight.mjs (1)

113-128: rustup warning path skips the WASM target check even when cargo/rustc are present via another toolchain manager.

If a contributor uses a non-rustup Rust installation (Nix, system package, asdf, etc.), commandExists('rustup') returns false and the WASM target is never verified — only a warning is emitted. Downstream cargo build --target wasm32-wasip1-threads will then fail later with a less actionable error. Since needsWasmTarget contexts hard-require that target, consider escalating to an error (or at least making the warning spell out how to add the target without rustup) when context.needsWasmTarget is true.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/preflight.mjs` around lines 113 - 128, The current branch skips
verifying the WASM target when commandExists('rustup') is false, which lets
context.needsWasmTarget cases slip through as only a warning; update the logic
so when context.needsWasmTarget is true and rustup is not found, push an errors
entry (similar to the existing errors.push for missing targets) instead of just
a warnings.push, or at minimum make the warning actionable by specifying how to
add the target without rustup; adjust the block that references
commandExists('rustup'), context.needsWasmTarget, readInstalledRustTargets, and
wasmTarget to produce an errors.push with a clear title and body recommending
either rustup installation or platform-specific instructions for adding the wasm
target.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@scripts/preflight.mjs`:
- Line 67: The current assignment const context = contexts[command] ??
contexts.doctor silently treats unknown command values as doctor; instead,
explicitly validate the command: check whether contexts hasOwnProperty(command)
(or command in contexts) and if not, log an error and exit non‑zero (or throw)
so typos like "typo" fail fast; if you prefer permissive behavior, at minimum
log which context was chosen (e.g., console.log or processLogger) before running
the task — update the code around the contexts/command lookup (the const context
= ... line and the success message branch that checks command === 'doctor') to
use this validation/logging approach.

In `@scripts/run-task.mjs`:
- Around line 61-67: The loop using spawnSync over the commands array is
vulnerable to cmd.exe re-parsing when shell: isWindows is set; update the call
to avoid using a shell on Windows (i.e. set shell: false) so spawnSync(command,
args, ...) passes args directly to the executable, or if a shell is absolutely
required for some commands, build a single command string and properly escape
each arg before passing it to spawnSync as a string; change the code around
spawnSync, commands and the shell: isWindows option (and the passthrough path
that produces those args) so arbitrary user-supplied tokens are not handed
unescaped into cmd.exe.

---

Nitpick comments:
In `@scripts/preflight.mjs`:
- Around line 113-128: The current branch skips verifying the WASM target when
commandExists('rustup') is false, which lets context.needsWasmTarget cases slip
through as only a warning; update the logic so when context.needsWasmTarget is
true and rustup is not found, push an errors entry (similar to the existing
errors.push for missing targets) instead of just a warnings.push, or at minimum
make the warning actionable by specifying how to add the target without rustup;
adjust the block that references commandExists('rustup'),
context.needsWasmTarget, readInstalledRustTargets, and wasmTarget to produce an
errors.push with a clear title and body recommending either rustup installation
or platform-specific instructions for adding the wasm target.

In `@scripts/run-task.mjs`:
- Around line 37-48: The current logic only appends passthrough args to the last
command (variables: passthrough, commands; mapping callback with index !==
commands.length - 1), which prevents forwarding flags to earlier commands (e.g.,
cargo). Change the mapping so passthrough is appended to every command when the
user omits a `--` (or alternatively add a selector flag to target a specific
command); update the commands = commands.map(...) callback to always return
[entry[0], [...entry[1], ...passthrough]] instead of only for the last index,
and ensure behavior is documented in the task help/comments.

🪄 Autofix (Beta)

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 UI

Review profile: CHILL

Plan: Pro

Run ID: 2dbe23de-d988-4ea2-8cdc-ae6ddfa6f974

📥 Commits

Reviewing files that changed from the base of the PR and between bc68c66 and d9abddc.

📒 Files selected for processing (3)

• scripts/preflight.mjs
• scripts/run-task.mjs
• scripts/rust-env.mjs

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

• scripts/rust-env.mjs

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Unknown context silently falls back to doctor.

contexts[command] ?? contexts.doctor means an unrecognized task arg runs the doctor checks instead of erroring. In practice run-task.mjs already validates the task, so this is only reachable when preflight is invoked directly (e.g. node ./scripts/preflight.mjs typo), but the success message on line 178 still gates on command === 'doctor', so a typo'd context would run doctor-equivalent checks and print nothing on success, which is confusing. Consider erroring on unknown commands, or at least logging which context was selected.

Proposed fix

-const context = contexts[command] ?? contexts.doctor
+const context = contexts[command]
+if (!context) {
+  console.error(`Unknown preflight context: ${command}`)
+  console.error(`Known contexts: ${Object.keys(contexts).join(', ')}`)
+  process.exit(1)
+}

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	const context = contexts[command] ?? contexts.doctor
	const context = contexts[command]
	if (!context) {
	console.error(`Unknown preflight context: ${command}`)
	console.error(`Known contexts: ${Object.keys(contexts).join(', ')}`)
	process.exit(1)
	}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/preflight.mjs` at line 67, The current assignment const context =
contexts[command] ?? contexts.doctor silently treats unknown command values as
doctor; instead, explicitly validate the command: check whether contexts
hasOwnProperty(command) (or command in contexts) and if not, log an error and
exit non‑zero (or throw) so typos like "typo" fail fast; if you prefer
permissive behavior, at minimum log which context was chosen (e.g., console.log
or processLogger) before running the task — update the code around the
contexts/command lookup (the const context = ... line and the success message
branch that checks command === 'doctor') to use this validation/logging
approach.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🌐 Web query:

Does Node.js spawnSync with shell:true on Windows properly quote args containing spaces and special shell characters?

💡 Result:

No, Node.js spawnSync with shell: true on Windows does not properly quote individual arguments containing spaces or special shell characters like '&'. Instead, it simply joins the command and all args array elements with spaces into a single string, which is then passed to cmd.exe /d /s /c. This raw concatenation means spaces split arguments unless the user has already included shell-quoting in the arg strings themselves, and special characters like '&' are interpreted by cmd.exe, potentially truncating or altering command execution. The official documentation warns against passing unsanitized input with shell: true due to this risk of command injection via shell metacharacters. When shell: true and the shell is CMD, windowsVerbatimArguments is automatically true, meaning no additional quoting/escaping is done by Node.js before passing to the shell.

Citations:

• 1: https://nodejs.org/api/child_process.html
• 2: https://nodejs.org/api/child%5Fprocess.html
• 3: child_process should individually escape args[] on shell: true nodejs/node#29532
• 4: child_process.spawnSync() seems to be truncating arguments containing '&' nodejs/node#6702
• 5: Error: spawnSync npm.cmd EINVAL nodejs/node#59210

---

🏁 Script executed:

# First, find the file and inspect the relevant code sections
cd /tmp && find . -name "run-task.mjs" -type f 2>/dev/null | head -5

Repository: tailwindlabs/tailwindcss

Length of output: 50

---

🏁 Script executed:

# Check if file exists at the expected path
if [ -f scripts/run-task.mjs ]; then
  echo "File found at scripts/run-task.mjs"
  wc -l scripts/run-task.mjs
fi

Repository: tailwindlabs/tailwindcss

Length of output: 126

---

🏁 Script executed:

# Read the relevant sections of the file
if [ -f scripts/run-task.mjs ]; then
  echo "=== Lines 40-70 (including context around the issue) ==="
  sed -n '40,70p' scripts/run-task.mjs | cat -n
fi

Repository: tailwindlabs/tailwindcss

Length of output: 1070

---

🏁 Script executed:

# Also check lines around line 43 to see the passthrough path
if [ -f scripts/run-task.mjs ]; then
  echo "=== Lines 1-50 (to understand setup and line 43) ==="
  sed -n '1,50p' scripts/run-task.mjs | cat -n
fi

Repository: tailwindlabs/tailwindcss

Length of output: 2012

---

Args may not be shell-escaped correctly when shell: true on Windows.

With shell: isWindows, spawnSync passes command and joined args through cmd.exe. Node.js does minimal quoting for args when shell is truthy, so passthrough values that contain spaces, &, |, ^, ", etc. can be reinterpreted by the shell. For the hard-coded turbo/cargo/vitest/pnpm invocations this is fine, but the -- passthrough path (line 43) forwards arbitrary user-supplied tokens into this call, e.g. from crates/node napi build … --target x or any future ad-hoc use. A single arg containing a space (e.g. a path) will be split into two args on Windows.

Low impact for the current hard-coded call sites, but worth flagging since the override path is explicitly designed to accept arbitrary commands.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/run-task.mjs` around lines 61 - 67, The loop using spawnSync over the
commands array is vulnerable to cmd.exe re-parsing when shell: isWindows is set;
update the call to avoid using a shell on Windows (i.e. set shell: false) so
spawnSync(command, args, ...) passes args directly to the executable, or if a
shell is absolutely required for some commands, build a single command string
and properly escape each arg before passing it to spawnSync as a string; change
the code around spawnSync, commands and the shell: isWindows option (and the
passthrough path that produces those args) so arbitrary user-supplied tokens are
not handed unescaped into cmd.exe.

[RobinMalfait]

Hey! Thanks for your contributions, and I know I closed other PRs of yours already, but I would suggest to open issues / discussions first before making big changes to any codebase you find on GitHub. It's not fun to have to close somebody's PR, and it's not fun to get your PR closed when you put some work into this. So for that alone I'm sorry.

That said, we typically do all our development on macOS and verify everything on Linux & Windows machines as well (all tests and integration tests are setup in CI). We want to keep things simple, additional layers of indirection (by introducing some custom scripts) adds an additional layer of maintenance that is not necessary and will eventually get out of sync as well.

Thanks for the PR