I’ve spent the first chunk of my June Cursor subscription trying to fix Cursor, which had been working for months. I have a simple WSL2 2-repo setup (two folders in a workspace). I can open it, I can edit code and do everything I normally do, I can chat with an agent – but any tool calls get a note about how the execution shell is not available.
I’ve spent the better part of yesterday and today working with Composer trying to get a solution and it’s had me redo my workspace; check extensions; check my windows shortcut, trying to point it at a WSL workspace vs. a windows workspace, but no dice. The only thing that works is a single-folder root launch of Cursor that bypasses my workspace (which more or less eliminates Cursor’s utility for me).
I don’t want to give up on Cursor but I need to get work done. Any suggestions?
Steps to Reproduce
Load my workspace (or any multi-root workspace). Run echo agent-shell-ok && pwd – get a message about how it can’t because the execution shell isn’t available.
Hey, thanks for the detailed report. This issue is tied to multi-root workspaces plus WSL2, and it showed up after a recent update. You’re on the Nightly track 3.6.33, so this looks like a regression in a recent Nightly build.
Quickest check: switch from Nightly to the Default or Stable release track Cursor Settings > Beta/Release Track, then install the stable build. If multi-root shell works again on Stable, that confirms it’s a Nightly regression and also gets you back to a working setup.
Let me know if switching to Stable fixed it. If the issue still happens, please share a Request ID from one of the failed tool calls right top corner of the chat > Copy Request ID.
Thanks for the quick reply. I noticed that myself after I posted, which is odd because I never switched to nightly. I switched back to Stable and it went through the update/install process. Still no luck though.
I have a big long-running thread where Composer tried to troubleshoot as well as a super simple ‘verify your shell and fail’:
Hey, thanks for the Request ID and for checking the rollback on Stable.
Important point: since the issue is still on Stable 3.6.33, and @ugkola is seeing the same thing on 3.6.31 (Stable, Default track), it’s not a Nightly regression like I first thought. Looks like the bug is tied to a multi-root WSL2 workspace and isn’t track-specific.
I filed an internal report with your Request ID and @ugkola’s details. If there’s an update, I’ll reply here.
For now, the only working workaround is the one you already found: open a single folder instead of the workspace. I get that this isn’t great for a two-repo setup.
@ugkola, to add to the report: are you also using a multi-root workspace (.code-workspace with multiple folders), and does single-folder open work fine for you? Also, if you hit a failed tool call, please share the Request ID (top right of the chat > Copy Request ID).
@ugkola, thanks for the Request ID and the details, they’re helpful.
Interesting point: your symptom is the opposite of what @DiscountDarcy has. For them, the multi-root workspace crashes, and single-folder works. For you it’s the other way around, opening the parent folder base/ works fine, but opening the single folder project1/ crashes. That’s an important detail. It looks like the issue isn’t strictly multi-root, but how the working directory and shell get resolved in WSL2.
I’ve added your Request ID and this data point to the internal report. I can’t share an ETA for a fix yet.
For now, the workaround for your case is to open the parent folder base/, since tool calls work there. I’ll post an update here when I have one.
@DiscountDarcy, you have the opposite situation, so your workaround stays the same, use single-folder open. I get that it’s inconvenient for a two-repo setup.