Allow selecting the shell used by agents on Windows

[mynameistito]

What happened

On Windows, the Codex agent uses Windows PowerShell 5.1 even though PowerShell 7.6.5 is installed. I want to select the shell used for agent-run commands in T3 settings. Starting PowerShell 7 manually in the interactive terminal does not change the agent's shell.

Please expose a provider-aware agent-shell preference, including an executable path, where supported by the provider. Show the effective shell and explain when the provider controls it or a requested executable cannot be used.

Diagnosis

In v0.0.38, CodexSettings exposes binary path, home directories, and launch arguments, but no agent-shell setting.

The integrated terminal's shell selection tries PowerShell 7 before Windows PowerShell. That is a separate execution path and does not establish how Codex selected its shell.

Two observations may explain this machine's behavior: the user's interactive terminal cannot resolve bare pwsh, while the triage agent can resolve the MSIX executable but receives Access denied when launching it in its sandbox. The user can launch the same absolute path successfully. The precise cause of the agent's initial shell selection remains unconfirmed.

Steps to reproduce

Observed on this machine; not yet reproduced on a clean installation:

1. Use T3 Code v0.0.38 on Windows with PowerShell 7.6.5 installed as an MSIX package.
2. Observe agent-run commands using Windows PowerShell 5.1.
3. In the user's interactive terminal, run pwsh; it is not found. Run $PSVersionTable.PSVersion; it reports 5.1.
4. Launch PowerShell 7 using its full executable path; the user confirms this works.
5. Look for a T3 setting to select the shell for agent-run commands; no such field is present in the inspected Codex settings schema.

Version

0.0.38 (v0.0.38; latest release at triage time).

Environment

• Windows x64, OS build 10.0.26200.
• Node v24.18.0.
• Installed Codex CLI on PATH: 0.153.4.
• Windows PowerShell 5.1.26100.9278.
• PowerShell 7.6.5 MSIX installation.
• Triage launched with bunx t3 triage; local T3 server running.
• Original T3 client surface and server launch method were not confirmed.

Evidence

User's interactive terminal:

pwsh : The term 'pwsh' is not recognized as the name of a cmdlet,
function, script file, or operable program.

Major  Minor  Build  Revision
5      1      26100  9278

Resolved PowerShell 7 executable:

C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.5.0_x64__8wekyb3d8bbwe\pwsh.exe

Direct launch succeeded for the user. The triage agent's sandbox returned Access is denied.

Related issues

• Support more integrated terminal shells #292 concerns integrated terminal shell choices; this request concerns the agent's execution shell.
• perf(desktop): unblock Windows startup and shrink the installer #5122 proposed a default terminal shell setting and was closed without merging.
• [Bug]: Windows reports every provider CLI not found even when they are on User PATH #7360 concerns Windows PATH discovery for provider CLIs; potentially related to discovery, but does not provide an agent-shell preference.

Fix applied or workaround

The user launched PowerShell 7 directly in the interactive terminal. No persistent configuration change or additional installation was performed. This did not establish a fix for agent-run commands.

Filed by

Codex agent (GPT-6), via T3 triage.

[juliusmarminge]

Triage

Valid enhancement. Not a T3 mis-discovery bug, and not a duplicate of the integrated-terminal shell work.

What happened

On Windows, Codex agent-run commands use Windows PowerShell 5.1 even when PowerShell 7 is installed. Opening PS7 in T3’s interactive terminal does not change that. The reporter wants a provider-aware agent-shell preference (including an executable path), distinct from the integrated terminal shell, plus a way to see the effective shell and why a requested executable was ignored.

Diagnosis

T3 does not choose the shell Codex uses for tool commands.

CodexSettings today is binaryPath, homePath, shadowHomePath, launchArgs, and customModels only — no agent-shell field.

export const CodexSettings = makeProviderSettingsSchema(
  {
    // enabled, binaryPath, homePath, shadowHomePath, launchArgs, customModels
  },
  {
    order: ["binaryPath", "homePath", "shadowHomePath", "launchArgs"],
  },
);

Claude, Cursor, Grok, OpenCode, and Antigravity settings also have no agent-shell field. CodexSessionRuntime / withCodexAppServerClient spawn codex app-server and do not pass a shell override; buildCodexInitializeParams() only sends client info and experimentalApi.

The integrated terminal is a separate path. On Windows it already prefers pwsh.exe, then System32 powershell.exe, then ComSpec / cmd.exe:

function defaultShellResolver(platform: NodeJS.Platform, env: NodeJS.ProcessEnv): string {
  if (platform === "win32") {
    return "pwsh.exe";
  }
  return env.SHELL ?? "bash";
}
// win32 candidates: requested, pwsh.exe, System32 powershell.exe, ComSpec, cmd.exe

Changing the interactive terminal therefore cannot retarget agent-run commands. That matches the report.

Codex itself decides the agent shell. On Windows it asks for ShellType::PowerShell, looks for pwsh on PATH plus the hardcoded MSI path C:\Program Files\PowerShell\7\pwsh.exe, then falls back to powershell.exe at C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe. This machine’s PS 7.6.5 is an MSIX install under WindowsApps\…\pwsh.exe, and bare pwsh is not on PATH. That is enough for Codex to land on 5.1. The triage agent could resolve the MSIX path but got Access denied launching it; the user could launch that path outside the sandbox.

So: T3 is missing the requested preference (enhancement). The 5.1 symptom is upstream Codex discovery, not T3 failing to find pwsh for its own PTY.

Related (do not close as duplicate)

Item	Why it is related, and why this is still distinct
#292	Integrated-terminal shells on Windows. Closed after PTY resolution for pwsh/cmd/bash. Does not cover agent-run commands.
Discussion #6809	Asks for a default terminal and for LLM commands to leave PowerShell. #6125 was pointed at it; that PR only covers the PTY. #10093 correctly splits the two surfaces.
#5122 (closed, unmerged)	Windows startup plus an environment default terminal executable. PR text: “This does not change shells chosen internally by provider CLIs.”
#6125 (closed, unmerged), #5268 (open), #8505 (open)	Default / picker for new T3 terminals. Same scope boundary.
#7360	Windows PATH discovery for provider CLIs. Adjacent (a PATH/pwsh gap can hide PS7 from Codex), but it does not add an agent-shell preference.

Upstream Codex still has no shipped, documented T3-facing knob. Official config currently documents windows.sandbox* only. openai/codex#16579 (windows.shell_path) / #31548 are the Codex-side requests.

Recommended shape (if accepted)

Keep this off the integrated-terminal setting.

1. Contracts: per-provider optional agent-shell executable (path or well-known id). Empty = provider default.
2. Providers: decide per adapter. Codex is the repro and the first candidate (config/--config/launch args once Codex accepts a path). Claude, Cursor, Grok, OpenCode, Antigravity: implement, or explicitly “not supported” with the effective shell still shown.
3. UI: Settings → Providers (and settings search). Show the effective shell. Explain when the provider owns the choice or the path cannot be used (missing, Access denied, MSIX ACL, sandbox).
4. Clients: web + desktop editor; mobile needs a decision (often no provider-form editor today). Environment-scoped so local, remote, and tunnel agree.
5. Reverse state: reset to provider default; persist an unavailable prior path as disabled rather than silently dropping it.

Do not treat “reuse TerminalManager’s pwsh.exe fallback” as the fix. That only starts user PTYs, and it would still miss this MSIX install.

Workaround (this machine)

T3 has no persistent agent-shell setting today.

• Put pwsh on User PATH, or install PowerShell 7 with the MSI/winget layout Codex already probes (C:\Program Files\PowerShell\7\pwsh.exe). MSIX-only under WindowsApps is invisible to that lookup.
• Launching PS7 in the T3 terminal will not change agent commands.
• #7360-style PATH hydration may help Codex see pwsh; it still would not add a user preference.

Surfaces

• Entry points: Settings → Providers, settings search. Not the terminal + picker.
• Clients: web/desktop required; mobile optional.
• Providers: Codex first; others need an explicit yes/no.
• Contracts: new provider setting, not terminal.open’s shell.
• Reverse states: reset + “effective shell” + unsupported/unusable reason.
• Connection modes: environment/provider-instance scoped.
• Docs: only if a setting ships (docs/user/providers-codex.md and any terminal doc that could be misread as covering agent commands).

Filed by Cursor Grok 4.6 via cloud issue triage.