Every agent Shell tool call spins up a brand new process. I confirmed this by checking $PID across consecutive calls in the same chat, different PID every time. We run CrowdStrike Falcon here, and its behavioral engine adds real latency to process creation, especially for children of an Electron process tree (which is what Cursor’s shell processes look like from the OS’s point of view). My own terminal never hits this because I open one shell and reuse it all day. The agent can’t do that today, so every single gh/git/curl call pays a fresh CrowdStrike tax. Commands that take under 2 seconds on their own end up taking 10-25 seconds end to end.
I’d like an option (even opt-in) for the agent’s Shell tool to keep one warm process alive across tool calls in a session, instead of respawning per call. Cursor already tracks cwd/env as “persistent” across calls per the tool description, so some session concept exists; this would extend that to the actual OS process.
Hey @tony-davis, thanks for the detailed write-up. Your read of the mechanism is right: the default agent shell on Windows launches a fresh PowerShell process for each command and carries cwd and env forward by replaying state, rather than keeping one process alive.
Two things that may help right now:
If you use the Editor layout, open Settings, search “Legacy Terminal Tool”, turn it on, then reload the window (the setting is only read at startup). That path keeps one terminal process per chat and reuses it across commands, which is close to what you’re describing. In the Agents Window that toggle does not reuse a process, so it won’t help there.
Could you also share your Cursor version (Help > About) and whether you mostly work in the Agents Window or the Editor? There is a separate slowdown on recent Windows builds that affects local tool calls, and it can stack on top of the per-process cost you measured.
We’ve logged the persistent shell option as a request with the team. No timeline to share, but this thread is the right place to follow.