When the Bash terminal unexpectedly switches to Windows Subsystem for Linux (WSL) mode, it usually stems from a default shell configuration override in Windows Terminal or an environment variable conflict. This behavior disrupts local script execution by routing commands through the WSL instance instead of the native Windows command prompt. You can resolve this by adjusting the default profile settings in your terminal application or correcting system path variables.
Understanding the Root Cause
The transition from a standard Windows Command Prompt or PowerShell session to a WSL environment is rarely accidental. It typically occurs because the operating system or the terminal emulator has been configured to treat Linux distributions as the primary execution environment. In many modern setups, especially those involving development tools like Git Bash, VS Code, or custom user profiles, the system prioritizes the WSL kernel for specific file types or command invocations. This shift can be particularly problematic for users running legacy scripts that expect native Windows utilities rather than their Linux counterparts. For instance, a script relying ondir might fail if the context switches to a shell where ls is the expected command. Additionally, environment variables such as PATH may change dynamically, causing local executables to become inaccessible while inside the WSL context. Understanding whether the switch originates from the terminal emulator itself or the system-wide default handler is the first step toward stabilization.
Checking Windows Terminal Default Profiles
If you are using Windows Terminal, which is the default terminal application for Windows 10 and 11, the most common culprit is thedefaultProfile setting. This JSON-based configuration file determines which shell launches when you open a new tab or window without specifying a particular profile. If this value is set to a UUID associated with a WSL distribution, every new session will start in Linux mode.
To verify this, locate your Windows Terminal settings file. On most systems, this is found at %LOCALAPPDATA%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json. Open this file and look for the defaultProfile key. Ensure that the GUID assigned to this key matches your desired Windows shell, such as PowerShell or Command Prompt, rather than a WSL distribution. If the GUID is incorrect, update it to point to the correct profile and save the file. Restarting the terminal should then respect the new default.
For more granular control, you can also check the profiles` section within the same JSON file. Each profile has its own launch command and working directory settings. Ensuring that the Windows-specific profiles have the correct commandLine arguments prevents unintended fallbacks to WSL.
Adjusting System Environment Variables
Sometimes the issue lies deeper within the operating system configuration, specifically in how the PATH environment variable is constructed. If the WSL binary paths are prepended to the system PATH, any invocation of bash or related commands might trigger a transition to the WSL subsystem. This often happens after installing certain developer toolkits or updating WSL components.
To diagnose this, open a standard Command Prompt and run echo %PATH%. Review the output for any entries pointing to \wsl$\ or directories within C:\Users\YourName\AppData\Local\Microsoft\WindowsApps that relate to Linux binaries. If these paths appear before the standard Windows system directories, they may be intercepting commands intended for native execution.
You can modify these variables through the System Properties dialog. Access this by searching for "Environment Variables" in the Start menu. Under "System Variables," edit the PATH entry and ensure that Windows system paths take precedence over any WSL-related entries. Removing or reordering these paths can prevent the terminal from automatically switching contexts during script execution.
Verifying File Associations and Handlers
Another potential source of confusion involves file associations. If you have configured .sh files or other script types to open with a WSL-compatible handler, double-clicking or invoking them via the terminal may initiate a WSL session. This is distinct from the shell itself switching but can feel identical to the user experience.
Check the default applications for script files by right-clicking a .sh file and selecting "Open with." Ensure it is not set to use a WSL distribution unless explicitly intended. Similarly, inspect the registry keys associated with file handlers if you suspect a deeper integration issue. Correcting these associations ensures that script execution remains within the expected environment.
Frequently Asked Questions
How do I revert to CMD if WSL starts automatically?
You can force a specific shell by launching Windows Terminal with a command-line argument specifying the desired profile. Alternatively, check the defaultProfile in the settings.json file to ensure it points to the Command Prompt or PowerShell UUID rather than a WSL distribution.
Why does my script fail after switching to WSL?
Scripts fail because the environment changes from Windows to Linux, altering available commands and environment variables. Native Windows utilities like dir or netstat are replaced by their Linux equivalents, causing syntax errors in scripts expecting Windows-style outputs.
Can I disable WSL entirely to fix this?
While you can disable the WSL feature via PowerShell using Disable-WindowsOptionalFeature, this is generally not recommended. Disabling WSL breaks compatibility with tools that rely on it, and troubleshooting the configuration is usually safer and more effective.
What causes PATH issues leading to WSL switches?
Prepending WSL binary paths to the system PATH allows the OS to intercept commands like bash and route them to the subsystem. Reordering the PATH variable so Windows system directories appear first resolves the ambiguity.
How do I check my current Windows Terminal profiles?
Navigate to the settings.json file in your Windows Terminal data folder. Look under the profiles` list to see all available shells and their corresponding GUIDs, which helps identify if the wrong profile is selected as the default.