fix(windows): block reserved names in tools

[applerom]

Issue for this PR

Fixes #13369

Type of change

• Bug fix
• Refactor / code improvement
• New feature
• Documentation

What does this PR do?

This fixes a native Windows footgun around reserved device names.

It rejects reserved Windows basenames like NUL, CON, PRN, AUX, COM1-COM9, and LPT1-LPT9 in the write, edit, and patch flows so those tools fail early instead of creating paths that Windows treats specially.

It also adds a narrow bash-side guard for literal reserved-name redirect targets when the bash tool is running through a POSIX shell on Windows (for example Git Bash). This covers the observed >NUL case that can create an undeletable artifact on native Windows.

The bash change is intentionally limited to literal redirect targets. It does not try to evaluate full dynamic shell expansion semantics.

How did you verify your code works?

I tested this locally on native Windows after rebasing onto the latest dev.

Commands run:

• bun test test/tool/bash.test.ts test/tool/apply_patch.test.ts test/tool/edit.test.ts test/tool/write.test.ts
• bun test test/util/filesystem.test.ts --test-name-pattern "Windows reserved names"

Screenshots / recordings

Not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found related PRs that address similar Windows reserved names issues:

1. PR fix: prevent Windows reserved device names from being added to directory checks and simplify bash description parameter #11605 - "fix: prevent Windows reserved device names from being added to directory checks and simplify bash description parameter"

   • This appears to be an earlier attempt at addressing Windows reserved device names

2. PR fix: prevent undeletable nul file on Windows #13406 - "fix: prevent undeletable nul file on Windows"

   • Directly related to the >NUL issue mentioned in the current PR

3. PR fix: Windows CLI and deep link issues (#11657, #11666, #11674) #11724 - "fix: Windows CLI and deep link issues (Windows: opencode CLI hangs at startup when running internal npm list / npm config get registry #11657, [Windows] Opening with deep link duplicates projects #11666, [BUG]: (app): Clicking on overflowed tab on the right in the file view/review section does not scroll it into view #11674)"

   • General Windows-related fixes that may overlap with reserved names handling

These PRs suggest there have been previous efforts to address Windows reserved name issues. You should verify whether PR #11605 and #13406 were already merged or closed, and whether this PR (18076) is intended to supersede or complement them.

[applerom]

I got the same issue again locally on native Windows 11 (without using WSL) after opening this PR.

In a later OpenCode session, the bash tool was still running through Git Bash and an agent emitted a literal redirect like ping -n 5 127.0.0.1 > nul 2>&1, which created a reserved-name nul artifact in the project root again.

That is the exact failure mode this PR is intentionally scoped to prevent.

[rekram1-node]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.