feat(shell): let [tools.shell] pick the bash tool's interpreter#4131
Merged
Conversation
The shell tool auto-detected its interpreter — real bash first, Git-for-Windows bash next, PowerShell only as a last resort — with no way to override it. A Windows user who prefers PowerShell but has Git installed was stuck on Git bash. Add a [tools.shell] config block mirroring [tools.search]: prefer = auto (default, unchanged behaviour) | bash | powershell | pwsh, with an optional explicit path. A forced shell that isn't installed warns at startup and falls back to auto-detection, so a typo can't leave the tool broken. The resolved shell rides on sandbox.Spec, so it reaches both the agent's bash tool and user-invoked "!" commands (the controller stores it too). The "fell back to PowerShell" hint is suppressed once a shell is chosen explicitly. Cache-neutral by default: prefer=auto resolves exactly as before, so the bash tool's description (the only shell-dependent part of the prompt) is byte identical. Forcing a shell changes that description to match — intrinsic to switching shells, and stable per config. Part of #4114 (desktop Settings UI follows in a separate PR).
esengine
added a commit
that referenced
this pull request
Jun 12, 2026
Surfaces the [tools.shell] preference (added in #4131) in the desktop Settings panel so users don't have to hand-edit reasonix.toml. The Sandbox tab gains a "Shell interpreter" select — auto / bash / PowerShell / pwsh — wired through the existing SetSandbox apply path (snapshot → reload → resume), with en/zh strings. Closes #4114
esengine
added a commit
that referenced
this pull request
Jun 12, 2026
…#4134) Surfaces the [tools.shell] preference (added in #4131) in the desktop Settings panel so users don't have to hand-edit reasonix.toml. The Sandbox tab gains a "Shell interpreter" select — auto / bash / PowerShell / pwsh — wired through the existing SetSandbox apply path (snapshot → reload → resume), with en/zh strings. Closes #4114
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #4114. This is the backend / config-file half; the desktop Settings dropdown follows in a separate PR (it builds on this
[tools.shell]field).Problem
The shell tool auto-detects its interpreter (real bash → Git-for-Windows bash → PowerShell) with no override. A Windows user who prefers PowerShell but has Git for Windows installed is stuck on Git bash.
Change
A
[tools.shell]config block, mirroring the existing[tools.search]engine config:prefer = "auto"(default) is the exact current behaviour.bash/powershell/pwshforce that interpreter;pathoverrides the PATH lookup.[tools.search] engine="rg"), so a typo can't break the tool.sandbox.Spec, so it reaches both the agent's bash tool (viaConfineBash) and user-invoked!commands (the controller stores it). The "bash not found → using PowerShell" hint is suppressed once a shell is chosen explicitly.Cache
No impact by default:
prefer=autoresolves identically to today, so the bash tool's description (the only shell-dependent part of the prompt) is byte-for-byte the same. Forcing a shell changes that description to match the chosen interpreter — intrinsic to switching shells, and stable per config.Tests
resolveShellis dependency-injected; the existing decision table is updated and a newTestResolveShellPrefercovers force / explicit-path / missing-shell-fallback / unknown-value.go test ./internal/{sandbox,config,boot,control,tool/builtin}green;cd desktop && go build ./...green; gofmt/vet clean.