After updating Cursor to 3.20.17, Flutter Windows debug from F5 fails immediately with:
Launching lib\main.dart on Windows in debug mode…
Error: %PROGRAMFILES(X86)% environment variable not found.
This is not a Flutter/project issue. Visual Studio 2022 is installed. The same machine and Flutter SDK work in:
Cursor integrated terminal: flutter run -d windows succeeds
Visual Studio Code 1.137.0 F5 succeeds
Windows Explorer and the Cursor main process still have ProgramFiles(x86)=C:\Program Files (x86)
Only Cursor F5 / Dart debug adapter spawn fails. Adding dart.env in .vscode/settings.json is not an acceptable fix; Cursor should preserve standard Windows env vars.
Steps to Reproduce
Windows 11 x64 with Visual Studio 2022 (Desktop development with C++) installed.
Open a Flutter Windows desktop project in Cursor 3.20.17.
Press F5 to debug on the Windows device.
Observe ToolExit: %PROGRAMFILES(X86)% environment variable not found.
In the same Cursor window, run flutter run -d windows in the integrated terminal. It succeeds.
Open the same project in VS Code 1.137.0 and press F5. It succeeds.
Expected Behavior
F5 should inherit the full Windows environment, including ProgramFiles(x86) / PROGRAMFILES(X86), the same as VS Code and the Cursor integrated terminal, so Flutter can locate vswhere.exe and start the Windows debug session.
Flutter locates Visual Studio via %PROGRAMFILES(X86)%\Microsoft Visual Studio\Installer\vswhere.exe and throws if the env var is missing.
Cursor debug/extension-host spawn appears to use Node process.env, which drops Windows env var names containing parentheses. CreateProcess inheritance used by the integrated terminal still has the variable. Cursor 3.20.17 is based on VS Code 1.128; installed VS Code is 1.137 and does not drop this variable on F5.
Please preserve standard Windows env vars (including names with parentheses) when launching debug adapters. Do not require workspace settings workarounds.
You’ve pinned this down correctly. Starting with 3.20, the process that hosts extensions (and launches debug adapters) filters the environment it receives, and that filter is too strict: it drops Windows variables whose names contain parentheses, including ProgramFiles(x86) and CommonProgramFiles(x86).
The integrated terminal receives its environment through a different path, which is why flutter run -d windows still works there. I’ve flagged this to the team.
Until a fix ships, you can pass the variable back to the Dart tooling only \u2014 either by adding "toolEnv": {"PROGRAMFILES(X86)": "C:\\Program Files (x86)"} to your launch.json configuration, or via the dart.env setting. I know a workspace-level workaround isn’t ideal, but it’s the smallest change and it’s safe to remove once the fix lands.
Quick update: a fix for the F5 debug launch dropping PROGRAMFILES(X86) has landed and will be included in an upcoming Cursor update (3.21). Thanks again for the report!
That 3.20.21 build is dated 2026-09-13, i.e. **before** your note that the fix would ship in 3.21. Check for Updates still leaves me on 3.20.21. Other forum posts from today are also still reporting 3.20.21, so it looks like 3.21 is not on the default channel yet — or this install is not being offered it.
Retest on the same Flutter Windows project, with **no** `dart.env` / `toolEnv` / `launch.json` workaround:
Cursor F5 → Windows device: still `Error: %PROGRAMFILES(X86)% environment variable not found.`
Same Cursor window, integrated terminal `flutter run -d windows`: still succeeds
Same project, VS Code 1.137.0 F5: still succeeds
So the extension-host / debug-adapter env filter still drops `ProgramFiles(x86)` on the latest 3.20.x that actually shipped here. Please keep this open until 3.21 (or whichever stable build preserves parenthesized Windows env vars for Dart/Flutter F5) is on the default channel and F5 works without workspace settings.
