Summary
On Windows, machine/Group Policy Set-ExecutionPolicy makes CodeWhale's PowerShell shell tool refuse to run: shell_dispatcher.rs writes a temp .ps1 and launches powershell -File <temp>, which is blocked by policy with a localized refusal ("running scripts is disabled on this system" / 中文 / 日本語 variants). The shell surface is effectively dead on those machines even though CodeWhale itself is properly installed.
Evidence
Current main: crates/tui/src/shell_dispatcher.rs builds the temp .ps1 + -File invocation (preferring pwsh when present) but never passes -ExecutionPolicy, and the only upstream Bypass hits are installer NSI scripts and the computer-use plugin — not the shell tool.
Proposal (from the Pinvou fork, Pinvou/CodeWhale #66)
We fixed this in our fork and would like to upstream it — but it deliberately circumvents machine script policy for CodeWhale's own scripts, which is trust-boundary adjacent, so we're asking for sign-off here before opening a PR:
- Launch both the
-File and -EncodedCommand forms with process-scoped -ExecutionPolicy Bypass (scoped to the CodeWhale child process only; machine policy is untouched and the scripts are CodeWhale-generated temp files, not user content).
- Bound the
-EncodedCommand UTF-16LE base64 payload by the 32767-character Windows command-line limit.
- Retry only our own temp script's refusal — exact
-File path match, with en-US/zh-CN/ja-JP refusal fingerprints; nested powershell -File inner.ps1 refusals inside script output are NOT retried; only Failed results are retried (never Killed/TimedOut).
- Key the UTF-8 output prefix handling on the PowerShell family including
ShellKind::Custom{pwsh}.
About half the fork diff is tests (behavior tests + refusal-fingerprint fixtures). We'd re-validate on upstream's Windows CI and drop the fork-specific test prefixes. Happy to adjust the approach (e.g., a config opt-in instead of default-on) however maintainers prefer — we're looking for a direction call before writing the PR.
Linked fork work
- Fork commit: Pinvou/CodeWhale
c4e6caf94 (author zhuowp) — happy to re-author/co-author on the upstream PR.
Summary
On Windows, machine/Group Policy
Set-ExecutionPolicymakes CodeWhale's PowerShell shell tool refuse to run:shell_dispatcher.rswrites a temp.ps1and launchespowershell -File <temp>, which is blocked by policy with a localized refusal ("running scripts is disabled on this system" / 中文 / 日本語 variants). The shell surface is effectively dead on those machines even though CodeWhale itself is properly installed.Evidence
Current
main:crates/tui/src/shell_dispatcher.rsbuilds the temp.ps1+-Fileinvocation (preferring pwsh when present) but never passes-ExecutionPolicy, and the only upstreamBypasshits are installer NSI scripts and the computer-use plugin — not the shell tool.Proposal (from the Pinvou fork, Pinvou/CodeWhale #66)
We fixed this in our fork and would like to upstream it — but it deliberately circumvents machine script policy for CodeWhale's own scripts, which is trust-boundary adjacent, so we're asking for sign-off here before opening a PR:
-Fileand-EncodedCommandforms with process-scoped-ExecutionPolicy Bypass(scoped to the CodeWhale child process only; machine policy is untouched and the scripts are CodeWhale-generated temp files, not user content).-EncodedCommandUTF-16LE base64 payload by the 32767-character Windows command-line limit.-Filepath match, with en-US/zh-CN/ja-JP refusal fingerprints; nestedpowershell -File inner.ps1refusals inside script output are NOT retried; onlyFailedresults are retried (neverKilled/TimedOut).ShellKind::Custom{pwsh}.About half the fork diff is tests (behavior tests + refusal-fingerprint fixtures). We'd re-validate on upstream's Windows CI and drop the fork-specific test prefixes. Happy to adjust the approach (e.g., a config opt-in instead of default-on) however maintainers prefer — we're looking for a direction call before writing the PR.
Linked fork work
c4e6caf94(author zhuowp) — happy to re-author/co-author on the upstream PR.