Agent command execution uses WSL instead of the Windows default integrated terminal (Git Bash)

Dunky-Z · May 10, 2026, 2:20am

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When I open a workspace from a Windows path (e.g. C:\Develop\...) in Cursor, the Agent runs shell commands in WSL (Linux). It does not use my configured default integrated terminal profile on Windows, which is Git Bash.

Because of that, tools I installed for Windows (e.g. mvn, node, java) are on the Windows / Git Bash PATH, but the Agent’s shell is a Linux environment where those commands are often missing (command not found). This makes automated builds and scripts unreliable even though the same commands work in the terminal I open manually in Cursor.

Expected behavior

When the workspace is opened on Windows (local folder, not “Remote - WSL”), I expect the Agent to execute commands in an environment consistent with my Terminal › Integrated: Default Profile (Windows) setting (Git Bash), or at least to use the same PATH and toolchain as that profile, so mvn, node, java, etc. resolve the same way as in my interactive terminal.

Actual behavior

The Agent’s shell reports WSL2 Linux (uname shows microsoft-standard-WSL2), with java not found and JAVA_HOME unset, while my interactive Git Bash session on the same machine shows Java 21 and normal command resolution.

I also disabled the Remote - WSL extension and retested; the Agent environment remained WSL (no change).

Environment

Version: 3.0.16 (user setup)
VSCode Version: 1.105.1
Commit: 475871d112608994deb2e3065dfb7c6b0baa0c50
Date: 2026-04-09T05:33:51.767Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.22631

Cursor: Windows desktop app, workspace opened via local Windows path (not intentionally using Remote-WSL for this folder)
User terminal (works): Git Bash — MINGW64_NT-10.0-...
Agent terminal (problem): WSL2 — Linux ... microsoft-standard-WSL2
Integrated terminal default (Windows): Git Bash

Impact

Any Agent workflow that runs mvn, node, npm, java, or other Windows-installed CLIs fails with “not found” or wrong toolchain, even though manual runs in Git Bash succeed.

Request

Please clarify whether this is by design and, if so, document how to force Agent commands to use the Windows default terminal profile (or Windows PATH). If it is a bug, please align Agent execution with the user’s Windows integrated terminal default when the workspace is not a Remote-WSL window.

Debugging commands and results

1. In my interactive Git Bash terminal (user terminal — OK):

java -version

Example output:

openjdk version "21.0.8" 2025-07-15 LTS
OpenJDK Runtime Environment Temurin-21.0.8+9 (build 21.0.8+9-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.8+9 (build 21.0.8+9-LTS, mixed mode, sharing)

uname -a

Example output:

MINGW64_NT-10.0-22631 DESKTOP-... 3.3.5-341.x86_64 ... x86_64 Msys

2. In the environment where the Agent runs shell commands (problem):

echo "SHELL=$SHELL"
uname -a
which java 2>/dev/null || command -v java || true
java -version 2>&1 || true
echo "JAVA_HOME=${JAVA_HOME:-<unset>}"

Example output:

SHELL=/bin/zsh
Linux DESKTOP-... 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC ... x86_64 GNU/Linux
/bin/bash: line 1: java: command not found
JAVA_HOME=<unset>

3. After disabling the Remote - WSL extension, the same Agent-side probe still showed WSL2 and no java.

Steps to Reproduce

same

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 3.0.16 (user setup)
VSCode Version: 1.105.1
Commit: 475871d112608994deb2e3065dfb7c6b0baa0c50
Date: 2026-04-09T05:33:51.767Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.22631

Does this stop you from using Cursor

Yes - Cursor is unusable

deanrie · May 10, 2026, 7:51am

Hey, thanks for the detailed report. This is a known bug. On Windows, the agent’s shell detection doesn’t respect terminal.integrated.defaultProfile.windows and just picks the first shell it finds that supports shell integration. On machines with WSL enabled, WSL’s bash.exe resolves before Git Bash, which is why you see microsoft-standard-WSL2 in the agent output. We’re tracking the issue, but there’s no ETA for a fix yet.

A workaround worth trying is to disable auto-detection of WSL profiles in settings.json so the agent won’t see them:

"terminal.integrated.useWslProfiles": false

After that, restart Cursor and check that the agent starts Git Bash, you can use the same probe script from your report. If it doesn’t help, let me know and we can try other options.

Dunky-Z · May 10, 2026, 2:08pm

Thanks for the suggestion. I added this to my user settings.json:

"terminal.integrated.useWslProfiles": false

After a full Cursor restart, the Agent environment is unchanged. Probing from the same shell the Agent uses still shows WSL2:

uname -a
# Linux ... microsoft-standard-WSL2 ...

java -version
# command not found

echo "JAVA_HOME=${JAVA_HOME:-<unset>}"
# JAVA_HOME=<unset>

My interactive integrated terminal is Git Bash on Windows and java/Node/Maven work there, but the Agent continues to run in Linux/WSL, so Windows-installed CLIs are still missing.

deanrie · May 13, 2026, 1:20pm

Thanks for the update. useWslProfiles: false only hides auto-detected WSL profiles, but if C:\Windows\System32\bash.exe is available in PATH or there’s some other bash source, the agent detector can still pick it up. Let’s try explicitly limiting the profiles to just Git Bash.

Add this to settings.json (User Settings):

"terminal.integrated.useWslProfiles": false,
"terminal.integrated.defaultProfile.windows": "Git Bash",
"terminal.integrated.profiles.windows": {
    "Git Bash": {
        "path": "C:\\Program Files\\Git\\bin\\bash.exe",
        "args": []
    },
    "PowerShell": null,
    "Command Prompt": null,
    "Ubuntu (WSL)": null,
    "Debian (WSL)": null
}

Adjust the path to bash.exe if Git isn’t installed in C:\Program Files\Git. The WSL distro names in the null block should match yours. You can check what’s visible in Terminal → Select Default Profile in Cursor.

After that, fully restart Cursor (quit the app, not Reload Window) and run the same probe script. uname -a should show MINGW64_NT-..., not microsoft-standard-WSL2.

A couple more notes:

You’re on Cursor 3.0.16. The current stable is newer, so it’s worth updating and testing again since there were shell detector fixes.
If WSL still starts after the config above, paste your full terminal.integrated.* block from settings.json and I’ll take a look.

This bug is known, no ETA for a fix yet.

Dunky-Z · May 13, 2026, 3:53pm

Hi,

Thank you for the earlier guidance. Here is a concise summary of what we tried today and what we still see, so you can track the issue.

Environment

OS: Windows 10 (build 22631), x64
Workspace: Opened from a local Windows path (e.g. C:\Develop\...), not intentionally using Remote-WSL for the folder
Interactive terminal: Git Bash — uname -a shows MINGW64_NT-..., tools work (java OpenJDK Temurin 21, Node, Maven, etc.)
Cursor: Started on 3.0.16, then upgraded to 3.3.30 (VS Code 1.105.1). Fully quit and restarted the app (not only Reload Window) after changes.

Original problem

The Agent runs shell commands in WSL (Linux) instead of the Windows default terminal (Git Bash). Commands such as mvn, node, and java fail in the Agent with “not found” / wrong PATH, while the same commands succeed in Git Bash.

What we tried (in order)

Disabled the Remote - WSL extension — No change for the Agent; probes still showed WSL2.
terminal.integrated.useWslProfiles: false (User settings.json) — No change for the Agent.
Explicit Git Bash–only profiles (as you suggested), including:
- "terminal.integrated.useWslProfiles": false
- "terminal.integrated.defaultProfile.windows": "Git Bash"
- "terminal.integrated.profiles.windows" with Git Bash pointing to C:\Program Files\Git\bin\bash.exe, and other profiles set to null where applicable (WSL distro names adjusted to match Terminal → Select Default Profile).
  Result: No change for the Agent; integrated terminal behavior may be correct, but Agent probes unchanged.
Cursor upgrade 3.0.16 → 3.3.30 — No change; Agent still reports WSL2.
User shut down WSL (wsl --shutdown / all distros Stopped in wsl -l -v) — As soon as the Agent ran a shell command, Ubuntu (default *) came back to Running. So the Agent path starts WSL even when distros were stopped beforehand.
Docker Desktop closed — docker-desktop distro Stopped as expected; Ubuntu still Running when the Agent ran commands (expected if the Agent host is Ubuntu WSL).
Terminal → Select Default Profile set to Git Bash — No change for the Agent.
Several further Cursor setting tweaks (user did not paste full JSON each time) — repeated Agent probes still showed Linux / WSL2, OSTYPE=linux-gnu, no MSYSTEM, PATH prefix like /usr/local/sbin:... (Linux layout), java not in PATH, JAVA_HOME unset.

Behavioral observation

Whenever the Agent executes a shell command, the default WSL distro (Ubuntu) is started (wsl -l -v shows Running). This matches the theory that Agent command execution is hosted in WSL, independent of integrated terminal defaults.

Here is the settings.json file:

{
    // 终端 配置
    // 终端字体设置
    "terminal.integrated.fontFamily": "'Maple Mono', 'Maple Mono NF CN', Consolas, monospace",
    // Linux 系统默认终端配置文件
    // "terminal.integrated.defaultProfile.linux": "zsh",
    // Windows 系统默认终端配置文件
    "terminal.integrated.defaultProfile.windows": "Git Bash",
    // macOS 系统默认终端配置文件
    "terminal.integrated.defaultProfile.osx": "",
    // Windows 终端配置文件列表
    "terminal.integrated.profiles.windows": {
        "Git-Bash": {
            "path": "C:\\Program Files\\Git\\bin\\bash.exe",
            "args": []
        },
        "PowerShell": null,
        "Command Prompt": null,
        "Ubuntu (WSL)": null,
        "Debian (WSL)": null
    },
    // 禁用WSL终端，避免Agent使用wsl的终端
    "terminal.integrated.useWslProfiles": false,
    // Windows 终端环境变量
    "terminal.integrated.env.windows": {
        "LC_ALL": "en_US.UTF-8"
    },
    // 是否启用多行粘贴警告
    "terminal.integrated.enableMultiLinePasteWarning": false,
    // 是否启用 Windows ConPTY
    "terminal.integrated.windowsEnableConpty": false,
    // 是否启用终端图片显示
    "terminal.integrated.enableImages": true,
    // 终端 Shell 集成历史记录数量
    "terminal.integrated.shellIntegration.history": 1000,
    // 是否自动检测终端区域设置
    "terminal.integrated.detectLocale": "on",
}

Thanks again.

deanrie · May 17, 2026, 6:50pm

Thanks for the detailed log of your attempts, it really helps. I can see the screenshot and the agent’s PATH is /usr/local/sbin:/usr/local/bin:/usr/sbin:..., which is a pure Linux layout with zero Windows paths. That means the agent process is actually running inside a WSL distro, not just launching bash.exe and looking outside. So your settings.json edits won’t affect this. The issue is which bash.exe gets resolved from PATH when the agent calls it.

Send me the output of these commands from regular CMD Win+R then type cmd, not Git Bash and not PowerShell:

where bash
echo %PATH%

I’m pretty sure the first line of where bash will be C:\Windows\System32\bash.exe. That’s the WSL launcher, and the agent is picking that up.

If that’s the case, there are two options:

Option A I recommend trying this first. Change the order in the System PATH not the User PATH so that C:\Program Files\Git\bin or C:\Program Files\Git\cmd comes before C:\Windows\System32. Open sysdm.cpl then Advanced then Environment Variables then in System variables find Path then Edit then move Git to the top. Reboot after.

Option B if A doesn’t work. Temporarily disable the Windows feature Windows Subsystem for Linux via optionalfeatures.exe, reboot. After that C:\Windows\System32\bash.exe will be gone, and the agent will be forced to use Git Bash. If that helps, it confirms the diagnosis. Then you can enable WSL again and keep PATH in the right order.

After each step, fully quit Cursor not Reload Window, then run the same probe again.

Dunky-Z · May 30, 2026, 4:37am

Hi,

Thank you for the detailed diagnosis and the two options. I ran both on my machine and wanted to share the results.

`where bash` / PATH (from regular CMD, not Git Bash or PowerShell)

After Option A (reordering System PATH so Git comes before System32), where bash now resolves in this order:

C:\Program Files\Git\bin\bash.exe
C:\Windows\System32\bash.exe
C:\Users\dominic\AppData\Local\Microsoft\WindowsApps\bash.exe

So Git Bash is first, as intended. The earlier issue you suspected (System32’s WSL launcher winning) was indeed the case before the reorder.

Option A — reorder System PATH + reboot

I moved C:\Program Files\Git\bin (and related Git entries) above C:\Windows\System32 in System variables → Path, then fully rebooted.
Result: Did not fix the Agent.
The Agent still appeared to run inside a WSL distro (Linux PATH like /usr/local/sbin:..., no Windows paths, java not found), and Ubuntu was started automatically whenever the Agent ran shell commands — even though where bash in CMD already listed Git first.

So on my setup, PATH order alone was not enough once WSL was enabled and available.

Option B — temporarily disable “Windows Subsystem for Linux”

I used optionalfeatures.exe, disabled “Windows Subsystem for Linux”, rebooted, fully quit Cursor (not Reload Window), then ran the same Agent probe.
Result: Worked.
uname -a showed MINGW64_NT-..., OSTYPE=msys, MSYSTEM=MINGW64, Windows/java on PATH, Agent commands ran in Git Bash as expected.

image905×863 62 KB

image1454×893 42.5 KB

Re-enabling WSL after Option B

I re-enabled the WSL Windows feature and rebooted again, then retested the Agent without changing PATH order back.
Result: Agent still used Git Bash; it did not switch back to WSL/Linux for command execution in my follow-up probes.

So Option B seems to have broken the Agent’s habit of auto-starting WSL, at least on my machine after the disable → enable cycle — though I’m not sure if that’s stable long-term or if something else changed (e.g. WSL state, Cursor restart, or detector cache).

Summary for your tracking

Step	Agent environment	Notes
Before any fix	WSL2 Linux	Agent PATH purely Linux; auto-starts Ubuntu
Option A (Git before System32 in System PATH)	Still WSL2	`where bash` correct in CMD; Agent unchanged
Option B (disable WSL feature, reboot)	Git Bash / MINGW64	`java`, Windows tools work
Re-enable WSL feature, reboot	Still Git Bash (so far)	Did not immediately revert to WSL bash

Thanks again for the clear guidance — Option B at least gave me a working Agent on Windows tooling, and the extra data may help confirm the root cause on your side.

Best regards

deanrie · May 30, 2026, 10:39am

Hey, thanks for such a detailed run-through of both options. This is really valuable data.

Here’s what we got:

Option A reordering the System PATH didn’t help on its own. where bash in CMD became correct (Git first), but the Agent still started Ubuntu WSL. So on a machine with WSL enabled, PATH order alone isn’t enough.
Option B disabling the Windows feature Windows Subsystem for Linux and rebooting worked. uname -a shows MINGW64_NT-..., OSTYPE=msys, MSYSTEM=MINGW64, and java plus the rest of the Windows toolchain are still available.

So Option B is a solid workaround for now. It’s interesting that after re-enabling WSL, your Agent didn’t switch back to Git Bash. Maybe the detector or WSL state got reset during the disable then enable cycle. Still, I wouldn’t count on that being stable long term. If the Agent starts WSL again, repeat Option B or keep the WSL feature disabled while you’re working with the Windows toolchain.

The core bug (Agent on Windows not respecting defaultProfile.windows) is known and tracked. I can’t share an exact ETA for a fix yet. I’ll add your findings to the issue, they help confirm it’s not just a PATH order problem. If anything comes up again, post here.

Topic		Replies	Views
[Windows] Agent terminal tool: no captured output (~0ms, exit 0) — integrated CMD works; Legacy Terminal enabled; PowerShell blocked by policy Bug Reports terminal , windows	8	108	May 6, 2026
WSL workspace context lost when switching to Agents Window (still present in 3.1) Bug Reports wsl , windows , agents-window , linear-linked	13	236	May 18, 2026
WSL2: Agent terminal spawns nested bash -O extglob / cursorsandbox processes; commands never exit and exhaust the machine Bug Reports sandbox , terminal , wsl , crashes	2	58	May 7, 2026
Run terminal command hangs —interactive terminal works fine Bug Reports terminal , windows	6	72	June 3, 2026
Looking in wrong spot to discover MCP servers Bug Reports mcp , wsl	12	113	May 12, 2026

Agent command execution uses WSL instead of the Windows default integrated terminal (Git Bash)

Where does the bug appear (feature/product)?

Describe the Bug

Expected behavior

Actual behavior

Environment

Impact

Request

Debugging commands and results

Steps to Reproduce

Screenshots / Screen Recordings

Operating System

Version Information

Does this stop you from using Cursor

Environment

Original problem

What we tried (in order)

Behavioral observation

where bash / PATH (from regular CMD, not Git Bash or PowerShell)

Option A — reorder System PATH + reboot

Option B — temporarily disable “Windows Subsystem for Linux”

Re-enabling WSL after Option B

Summary for your tracking

Related topics

`where bash` / PATH (from regular CMD, not Git Bash or PowerShell)