feat(windows): prefer PowerShell defaults for shell tools

[Hona]

Summary

• prefer pwsh, then powershell, before Git Bash and cmd.exe on Windows when SHELL is unset for both Shell.preferred() and Shell.acceptable()
• keep the existing Git Bash path resolution fallback intact instead of switching to plain bash lookup
• show the active process.platform and resolved shell name in the bash tool definition so agents can see the runtime context

[Copilot]

Pull request overview

Adjusts Windows shell selection defaults to prefer PowerShell-family shells and improves runtime transparency for the bash tool by surfacing OS/shell context in its description.

Changes:

• Update Shell.preferred() / Shell.acceptable() to prefer pwsh, then powershell, when SHELL is unset on Windows.
• Keep existing Windows Git Bash path-resolution fallback behavior intact.
• Inject process.platform and a resolved shell name into the bash tool description template.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
packages/opencode/src/tool/bash.txt	Adds OS + resolved shell placeholders to the tool description.
packages/opencode/src/tool/bash.ts	Resolves shell “display name” and substitutes OS/shell into the tool description.
packages/opencode/src/shell/shell.ts	Introduces base() helper and changes Windows default shell preference order.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

On Windows, returning the bare string "pwsh"/"powershell" here can break downstream logic that assumes shells ending with "sh" are POSIX shells (e.g. Pty.create() appends -l when command.endsWith("sh"), which matches pwsh). Consider returning the resolved executable path from Bun.which(...) (typically ends with .exe) or otherwise ensuring the returned value won’t match that heuristic; also consider de-duplicating the pwsh/powershell selection logic between preferred and acceptable to avoid drift.

[Copilot]

base() is used for the blacklist check, but on Windows path.win32.basename(file, ".exe") only strips the extension if the casing matches exactly, and it preserves casing of the name. If SHELL is something like Nu.EXE or NU.EXE, base() won’t produce "nu", so the blacklist won’t apply. Consider using path.win32.parse(file).name.toLowerCase() (or lowercasing the basename result) to make the check robust.

Suggested change

	if (process.platform === "win32") return path.win32.basename(file, ".exe")
	return path.basename(file)
	if (process.platform === "win32") {
	// Use parse().name to strip the extension in a case-insensitive way, then normalize to lowercase
	return path.win32.parse(file).name.toLowerCase()
	}
	// On non-Windows, just take the basename and normalize to lowercase
	return path.basename(file).toLowerCase()

[Copilot]

This PR changes Windows shell selection behavior (pwsh/powershell preference and updated blacklist logic), but there are no unit tests covering Shell.preferred() / Shell.acceptable() on win32 or the interaction with call sites like Pty.create(). Adding targeted tests (with platform/env/which stubbing) would help prevent regressions like incorrect args being appended or blacklisted shells slipping through.