"Feature Request: Allow configuring the default shell execution environment (e.g., pwsh, bash, nu) instead of hardcoded powershell.exe on Windows."

[Shallow-dusty]

What would you like to be added?

On Windows, the CLI currently defaults to powershell.exe (v5.1) for run_shell_command. This creates a bottleneck
because:

1. Encoding Issues: Native PowerShell defaults to GBK (936), causing encoding mismatches/mojibake when modern tools
   (like eza, lsd, or git) output UTF-8.
2. Limited Modern Features: Many users have migrated to pwsh (v7+) or NuShell for better performance and
   cross-platform compatibility.
3. Environment Isolation: Users often have their dev environment set up in pwsh, but the CLI executes commands in a
   different, unconfigured environment.
   Desired outcome: Add a setting (e.g., tools.shell.executablePath) to allow users to specify their preferred shell
   executable.

Why is this needed?

Unlocks Modern Windows Tooling & Fixes Encoding by Design

1. UTF-8 First: The legacy powershell.exe defaults to legacy encodings (GBK/CP936), causing mojibake with almost
   all modern CLI tools (Rust-based tools like eza, ripgrep, or even Node/Python scripts). Configuring the shell to pwsh
   (which handles UTF-8 correctly by default) fixes this natively without hacky $PROFILE modifications.
2. User Preference & Consistency: Developers invest time configuring their shell (pwsh, nu, bash) with specific
   aliases, environment variables, and tools. Forcing execution in a raw powershell.exe environment breaks this
   consistency and limits the CLI's potential integration with the user's workflow.

Additional context

📋 原始测试日志 (Raw Test Logs)

TEST 1: PowerShell 7 (pwsh) [Profile Enabled] <<<
Active code page: 65001
.
鈹溾攢鈹€ 鍙傝€冭祫鏂
鈹溾攢鈹€ 瀹炰範鏂囨。
鈹溾攢鈹€ 宸ョ▼鏂囦欢
鈹斺攢鈹€ 杞欢宸ュ叿

TEST 2: Windows PowerShell (powershell) [Profile Enabled] <<<
Active code page: 65001
.
鈹溾攢鈹€ 鍙傝€冭祫鏂
鈹溾攢鈹€ 瀹炰範鏂囨。
鈹溾攢鈹€ 宸ョ▼鏂囦欢
鈹斺攢鈹€ 杞欢宸ュ叿

TEST 3: NuShell (nu) <<<
.
鈹溾攢鈹€ 鍙傝€冭祫鏂
鈹溾攢鈹€ 瀹炰範鏂囨。
鈹溾攢鈹€ 宸ョ▼鏂囦欢
鈹斺攢鈹€ 杞欢宸ュ叿

TEST 4: CMD (cmd) <<<
Active code page: 65001
.
鈹溾攢鈹€ 鍙傝€冭祫鏂
鈹溾攢鈹€ 瀹炰範鏂囨。
鈹溾攢鈹€ 宸ョ▼鏂囦欢
鈹斺攢鈹€ 杞欢宸ュ叿

---

Technical Observations:

1. Brittle Encoding Management: As shown in the logs, even after manually forcing the code page to 65001 (UTF-8) via
   $PROFILE modifications, modern tools like eza still produce mojibake (broken characters) when piped through the
   hardcoded powershell.exe session used by the CLI agent. This demonstrates that simply "patching" the legacy shell is
   not a robust solution.

2. Shell Inconsistency: While NuShell (Test 3) handles these characters natively and correctly, it must be manually
   invoked as a sub-process of powershell.exe, leading to unnecessary overhead and potential environment variable loss.

3. The Hidden Bottleneck: The native powershell.exe (v5.1) is an outdated execution host for AI agents. By
   hardcoding it, the CLI prevents users from leveraging the native UTF-8 handling and modern features of pwsh or nu,
   which are standard in modern Windows development workflows.

Conclusion: Allowing a configurable shell path would allow the CLI to use a modern shell host directly, eliminating
these encoding artifacts and aligning with the user's actual development environment.

[Carton]

Same requirements here. Even if I tried ComSpec="C:\\Program Files\\Git\\bin\\bash.exe" gemini, it will still prefer commands in powershell first.

[onedreamv]

Using the command $env:ComSpec = 'pwsh.exe' and adding use pwsh syntax to memory may be an effective temporary workaround.

[zbynekwinkler]

The only way the shell can be changed right now is by setting ComSpec and it only respect the setting if it ends with powershell.exe or pwsh.exe.

gemini-cli/packages/core/src/utils/shell-utils.ts

Lines 544 to 571 in 3035489

	export function getShellConfiguration(): ShellConfiguration {
	if (isWindows()) {
	const comSpec = process.env['ComSpec'];
	if (comSpec) {
	const executable = comSpec.toLowerCase();
	if (
	executable.endsWith('powershell.exe') ||
	executable.endsWith('pwsh.exe')
	) {
	return {
	executable: comSpec,
	argsPrefix: ['-NoProfile', '-Command'],
	shell: 'powershell',
	};
	}
	}
	// Default to PowerShell for all other Windows configurations.
	return {
	executable: 'powershell.exe',
	argsPrefix: ['-NoProfile', '-Command'],
	shell: 'powershell',
	};
	}
	// Unix-like systems (Linux, macOS)
	return { executable: 'bash', argsPrefix: ['-c'], shell: 'bash' };
	}

The problem with this is that the tooling run by gemini cli does not generally expect ComSpec to be set to something different than cmd (i.e. a complicated build process).

At the same time gemini models insist on chaining commands with && which is not supported by the old powershell.

Can we maybe default the shell to pwsh.exe if it exists?

Or can we have a different mechanism to configure this behavior apart from setting ComSpec which breaks unrelated things?

[zbynekwinkler]

See also

• Gemini CLI on Windows should choose pwsh over powershell by default #18374

[EzioMercer]

It is really frustrating... It should be in settings to choose the desired shell

Currently I'm using this workaround:

1. Create a pwsh script file (gemini.ps1) with next context:

   $env:ComSpec="Path\To\PowerShell\7\pwsh.exe"; Path\To\User\AppData\Roaming\npm\gemini.ps1

2. Add folder where you created the script into the Path environment variable. It allows you to just call gemini like before
   2.1. IMPORTANT!!! You have to be sure that the path to created script is located before the path to the AppData\Roaming\npm\gemini.ps1 otherwise your shell will always execute the default one

Result:

[zbynekwinkler]

Well, I even made powershell function for this. But I cannot call conan generated build based on visual studio compiler from gemini since it expects cmd in ComSpec and not pwsh. Allowing only ComSpec to change this is not enough, since it breaks all the other things that expect cmd there.

[nicriverhoo]

this workaround may be helpful.
in pwsh, notepad $PROFILE, define a function as below:

function gemini_pwsh {
    $env:ComSpec = "pwsh.exe"
    gemini @args
}

and then, use gemini_pwsh in your pwsh shell.
double check it:

!$PSVersionTable

│ ✓  Shell Command $PSVersionTable                                                                     │
│                                                                                                      │
│ Name                           Value                                                                 │
│ ---                                                                                                  │
│ PSVersion                      7.5.4                                                                 │
│ PSEdition                      Core                                                                  │
│ GitCommitId                    7.5.4                                                                 │