Skip to content

fix: detect Git Bash/WSL/MSYS2 shell on Windows (non-interactive-env hook)#3370

Open
Zireael wants to merge 1 commit intocode-yeongyu:devfrom
Zireael:fix/git-bash-shell-detection-on-windows
Open

fix: detect Git Bash/WSL/MSYS2 shell on Windows (non-interactive-env hook)#3370
Zireael wants to merge 1 commit intocode-yeongyu:devfrom
Zireael:fix/git-bash-shell-detection-on-windows

Conversation

@Zireael
Copy link
Copy Markdown

@Zireael Zireael commented Apr 12, 2026

Summary

  • Fixes detectShellType() generating PowerShell : syntax when the active shell is Git Bash, WSL, or MSYS2 on Windows
  • Adds detection of Unix shell indicators (TERM, BASH_VERSION, MSYSTEM, WSL_DISTRO_NAME) before the PSModulePath check, which is always set on Windows regardless of the active shell
  • Updates the docstring to reflect the new 4-level detection priority

Problem

On Windows, PSModulePath is always set by the system — even when the active shell is Git Bash. The previous logic checked PSModulePath before any Unix indicators, causing the non-interactive-env hook to prepend PowerShell :VAR='value'; syntax to every bash command. Git Bash interprets these as 15 separate command not found errors per invocation.

Root Cause

src/shared/shell-env.ts line 24: detectShellType() returned "powershell" on Windows because PSModulePath check preceded any Unix shell detection.

Fix

Inserted a check for Unix-compatible shell env vars between the SHELL and PSModulePath checks:

if (
  process.env.TERM ||           // Git Bash, WSL, MSYS2 set this (e.g. "xterm-256color")
  process.env.BASH_VERSION ||   // definitive bash indicator
  process.env.MSYSTEM ||        // MSYS2-specific ("MINGW64", "UCRT64", etc.)
  process.env.WSL_DISTRO_NAME   // WSL-specific ("Ubuntu", "Debian")
) {
  return "unix"
}

This ensures Git Bash users get export VAR=value; (Unix syntax) instead of :VAR='value'; (PowerShell syntax).

Fixes #3366


Summary by cubic

Fixes shell detection on Windows so Git Bash, WSL, and MSYS2 are treated as Unix shells. The non-interactive-env hook now uses Unix export syntax and avoids bash errors.

Written for commit 998dbde. Summary will update on new commits.

@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Apr 12, 2026

All contributors have signed the CLA. Thank you! ✅
Posted by the CLA Assistant Lite bot.

@Zireael
Copy link
Copy Markdown
Author

Zireael commented Apr 12, 2026

I have read the CLA Document and I hereby sign the CLA

Copy link
Copy Markdown

@cubic-dev-ai cubic-dev-ai bot left a comment

Choose a reason for hiding this comment

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

2 issues found across 1 file

Confidence score: 3/5

  • There is a concrete user-impacting risk in src/shared/shell-env.ts: using TERM as a broad Unix-shell signal can misclassify Windows PowerShell sessions and produce invalid env-prefix syntax.
  • Both findings are medium severity (6/10) with high confidence (8/10), so this looks like a real behavior regression risk rather than a minor style issue.
  • Pay close attention to src/shared/shell-env.ts - shell detection order/guards should avoid TERM preempting PowerShell logic, especially across Windows vs non-Windows environments.
Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/shared/shell-env.ts">

<violation number="1" location="src/shared/shell-env.ts:27">
P2: Scope the Unix-indicator override to Windows; otherwise it can preempt the PowerShell detection on non-Windows environments when `TERM` is set.</violation>

<violation number="2" location="src/shared/shell-env.ts:28">
P2: TERM is too broad a Unix-shell indicator here; on Windows PowerShell sessions where TERM is set, this branch misclassifies the shell as unix and generates invalid env-prefix syntax.</violation>
</file>

Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.

github-actions bot added a commit that referenced this pull request Apr 12, 2026
Copy link
Copy Markdown

@cubic-dev-ai cubic-dev-ai bot left a comment

Choose a reason for hiding this comment

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

0 issues found across 1 file (changes from recent commits).

Auto-approved: Fixes incorrect PowerShell detection for Git Bash/WSL/MSYS2 on Windows. Safe as markers used are specific to Unix-like environments and the previous logic already defaulted to PowerShell.

@Zireael Zireael force-pushed the fix/git-bash-shell-detection-on-windows branch from 23b1014 to 71adad1 Compare April 12, 2026 22:59
@Zireael
Copy link
Copy Markdown
Author

Zireael commented Apr 12, 2026

recheck

On Windows, PSModulePath is always set by the system even when the
active shell is Git Bash, WSL, or MSYS2. detectShellType() returned
'powershell' in these cases, causing the non-interactive-env hook to
prepend PowerShell $env: syntax which Git Bash cannot parse.

Adds checks for TERM, BASH_VERSION, MSYSTEM, and WSL_DISTRO_NAME
before the PSModulePath check to correctly identify Unix shells.

Fixes code-yeongyu#3366
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: non-interactive-env hook generates PowerShell $env: syntax on Git Bash (Windows)

1 participant