Skip to content

feat: support PowerShell 7 for Windows local shell - #9622

Merged
Soulter merged 10 commits into
AstrBotDevs:masterfrom
wcqqq1214:feat/windows-shell-config
Aug 12, 2026
Merged

feat: support PowerShell 7 for Windows local shell#9622
Soulter merged 10 commits into
AstrBotDevs:masterfrom
wcqqq1214:feat/windows-shell-config

Conversation

@wcqqq1214

@wcqqq1214 wcqqq1214 commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

Fixes #9614

On Windows, the Local runtime hardcodes powershell.exe (Windows PowerShell 5.1) when executing shell commands, so users who have PowerShell 7 installed cannot use its syntax features (such as && and ??). This PR makes the runtime auto-detect the shell on Windows: prefer PowerShell 7 (pwsh.exe) when it is on PATH, falling back to Windows PowerShell 5.1 (powershell.exe) otherwise — no config required.

Modifications / 改动点

  • astrbot/core/computer/booters/local.py: adds resolve_windows_shell(), used by the win32 branches of exec() and exec_managed() to prefer PowerShell 7 (pwsh.exe) when on PATH, else Windows PowerShell 5.1 (powershell.exe).
  • astrbot/core/astr_main_agent.py: the Local mode system prompt now hints at the resolved shell (PowerShell 7 / Windows PowerShell 5.1 / non-Windows), so the model does not emit syntax the target shell cannot parse.
  • astrbot/core/tools/computer_tools/shell.py: removed the config read; tool-driven commands follow the same auto-detection.
  • astrbot/core/config/default.py + dashboard/src/i18n/locales/{en-US,ru-RU,zh-CN}: removed the windows_shell config option and its dashboard metadata/translations.
  • tests/: cases covering pwsh preference, fallback to powershell.exe, non-Windows being unaffected, and the system prompt branches.

No new dependencies. Non-Windows code paths are untouched.

  • This is NOT a breaking change. / 这不是一个破坏性变更。

Screenshots or Test Results / 运行截图或测试结果

Local unit tests

The win32 branches are covered on macOS by faking sys.platform / os.name
via monkeypatch.

$ uv run python -m pytest tests/test_local_shell_component.py tests/unit/test_astr_main_agent.py tests/unit/test_func_tool_manager.py -q
148 passed, 3 warnings

Full project suite

$ uv run pytest tests -q
2117 passed, 15 warnings in 82.15s (0:01:22)

Windows end-to-end validation

Manual validation was performed by @Donoym on:

  • Windows 11 Pro 64-bit
  • DisplayVersion: 25H2
  • Build: 26200
  • Python: 3.12.13
  • PowerShell 7: 7.6.4

Configuration:

  • computer_use_runtime = local
  • PowerShell 7 installed and on PATH

Results:

  • PowerShell 7 on PATH: runtime launches pwsh.exe (PowerShell 7.6.4)
  • PowerShell 7 not on PATH: runtime launches powershell.exe (Windows PowerShell 5.1.26100.8972)
  • Write-Output 'a' && Write-Output 'b': output was a, b

Cross-platform test findings

The initial Windows pytest run, before the portability fixes, reported:

  • 142 passed
  • 7 failed
  • 3 warnings

The failures were caused by platform-specific test assumptions involving Windows CRLF output, Windows path separators, and incomplete platform simulation.

Local verification after the test fixes:

  • Focused tests: 148 passed, 3 warnings
  • Full project tests: 2117 passed, 15 warnings

Checklist / 检查清单

  • 😊 If there are new features added in the PR, I have discussed it with the authors through issues/emails, etc.
    / 如果 PR 中有新加入的功能,已经通过 Issue / 邮件等方式和作者讨论过。

  • 👀 My changes have been well-tested, and "Verification Steps" and "Screenshots" have been provided above.
    / 我的更改经过了良好的测试,并已在上方提供了“验证步骤”和“运行截图”

  • 🤓 I have ensured that no new dependencies are introduced, OR if new dependencies are introduced, they have been added to the appropriate locations in requirements.txt and pyproject.toml.
    / 我确保没有引入新依赖库,或者引入了新依赖库的同时将其添加到 requirements.txtpyproject.toml 文件相应位置。

  • 😮 My changes do not introduce malicious code.
    / 我的更改没有引入恶意代码。

Summary by Sourcery

Auto-detect and prefer PowerShell 7 for Windows local shell execution while keeping non-Windows behavior unchanged.

New Features:

  • Support PowerShell 7 (pwsh.exe) as the preferred Windows shell when available, falling back to Windows PowerShell 5.1 for local and managed command execution.

Enhancements:

  • Update the local mode system prompt to reflect the resolved Windows shell and guide the model toward compatible command syntax.
  • Clarify tool-driven shell command descriptions to reference PowerShell on Windows instead of cmd.exe.

Tests:

  • Add and adjust unit tests to cover PowerShell 7 preference, fallback to Windows PowerShell 5.1, non-Windows behavior, and updated prompt and output handling.

@wcqqq1214 wcqqq1214 changed the title feat: make Windows local runtime PowerShell configurable feat: support PowerShell 7 for Windows local shell Aug 10, 2026
@C10H14N2O5

Copy link
Copy Markdown

好快的写(`ヮ´)

Comment thread astrbot/core/config/default.py Outdated
@wcqqq1214
wcqqq1214 force-pushed the feat/windows-shell-config branch from 51c12bd to b5129fc Compare August 12, 2026 04:02
@C10H14N2O5

C10H14N2O5 commented Aug 12, 2026

Copy link
Copy Markdown

Thank you very much for the quick response and contributions from both you and the maintainers! I also deployed and tested this PR locally. It is working properly, and I confirmed that the Local Runtime correctly invokes pwsh.exe.

Test environment

  • Windows 11 Home 64-bit
  • DisplayVersion: 25H2
  • Build: 26200.9168
  • Python: 3.14.0
  • PowerShell 7: 7.6.4

Feedback on the current approach

I fully understand and agree with the current approach of preferring PowerShell 7 and falling back to Windows PowerShell 5.1 when it is unavailable, as this reduces configuration complexity and cognitive overhead for users.

However, would it be possible to consider adding a read-only effective shell status where the previous PowerShell selector was located, or logging the PowerShell executable and version actually selected by the Local Runtime?

For example:

Effective shell: PowerShell 7.6.4 (pwsh.exe)

or, when falling back:

Effective shell: Windows PowerShell 5.1 (powershell.exe)

Why this could be useful

This would allow users to clearly confirm whether the Local Runtime is currently using pwsh.exe or powershell.exe.

Especially now that automatic PowerShell 7 / 5.1 selection and fallback have been introduced, this kind of observability could also make it easier to diagnose environment-related issues in the future, such as:

  • the Launcher process inheriting a different PATH from the user's terminal environment;
  • pwsh.exe not being detected correctly;
  • unexpected fallback to Windows PowerShell 5.1;
  • other PowerShell invocation issues.

This would preserve the simplicity of the current automatic selection strategy while making the effective runtime environment more transparent and easier to diagnose.

This is just a non-blocking suggestion and should not hold up this PR.

@dosubot dosubot Bot added the lgtm This PR has been approved by a maintainer label Aug 12, 2026
@Soulter

Soulter commented Aug 12, 2026

Copy link
Copy Markdown
Member

LGTM, I'll merge this PR after you marking to ready for review :)

@wcqqq1214
wcqqq1214 marked this pull request as ready for review August 12, 2026 12:22
@dosubot dosubot Bot added size:M This PR changes 30-99 lines, ignoring generated files. area:core The bug / feature is about astrbot's core, backend labels Aug 12, 2026

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've found 1 issue, and left some high level feedback:

  • In resolve_windows_shell, consider checking explicitly for pwsh.exe (e.g., shutil.which('pwsh.exe')) rather than pwsh to avoid potential mismatches with non-EXE shims or aliases and align with the actual executable name being returned.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- In `resolve_windows_shell`, consider checking explicitly for `pwsh.exe` (e.g., `shutil.which('pwsh.exe')`) rather than `pwsh` to avoid potential mismatches with non-EXE shims or aliases and align with the actual executable name being returned.

## Individual Comments

### Comment 1
<location path="astrbot/core/astr_main_agent.py" line_range="455-460" />
<code_context>
-        if system_name.lower() == "windows"
-        else "The runtime shell is Unix-like. Use POSIX-compatible shell commands."
-    )
+    if system_name.lower() != "windows":
+        shell_hint = (
+            "The runtime shell is Unix-like. Use POSIX-compatible shell commands."
+        )
+    elif resolve_windows_shell() == "pwsh.exe":
+        shell_hint = (
+            "The runtime shell is PowerShell 7 (pwsh.exe). "
+            "Use PowerShell 7-compatible syntax and cmdlets; do not "
+            "assume Unix commands like cat/ls/grep are available."
+        )
+    else:
+        shell_hint = (
+            "The runtime shell is Windows PowerShell 5.1 (powershell.exe). "
</code_context>
<issue_to_address>
**suggestion:** Align the prompt wording with the fact that PowerShell provides some Unix-like command aliases.

The PowerShell 7 hint currently says Unix commands like `cat/ls/grep` are not available, but these names do exist as aliases to cmdlets. To avoid misleading guidance, consider rephrasing to something like “do not assume a full Unix userland or GNU utilities are available,” while still encouraging PowerShell-native syntax and cmdlets.

```suggestion
    elif resolve_windows_shell() == "pwsh.exe":
        shell_hint = (
            "The runtime shell is PowerShell 7 (pwsh.exe). "
            "Use PowerShell 7-compatible syntax and cmdlets, and do not "
            "assume a full Unix userland or GNU utilities are available."
        )
```
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Comment thread astrbot/core/astr_main_agent.py
Co-authored-by: sourcery-ai[bot] <58596630+sourcery-ai[bot]@users.noreply.github.com>
@Soulter
Soulter merged commit 123439d into AstrBotDevs:master Aug 12, 2026
20 checks passed
@wcqqq1214
wcqqq1214 deleted the feat/windows-shell-config branch August 12, 2026 13:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:core The bug / feature is about astrbot's core, backend lgtm This PR has been approved by a maintainer size:M This PR changes 30-99 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Feature] 希望 Windows 本地 Shell 在保留默认使用 PowerShell 5.1 的前提下支持配置 PowerShell 7

3 participants