When using Cursor IDE’s Agent window with a remote Linux workspace, commands initially execute in the correct remote environment. However, after the agent invokes a subagent, subsequent commands are executed in my local Windows PowerShell instead of the remote Linux workspace. The execution environment should remain the remote Linux environment throughout the entire agent workflow.Restarting cursor can temporarily restore the execution environment.
Steps to Reproduce
Use cursor ide, and use agent window. Workspace is a remote linux path. After agent use subagent,environment of command to execution is changed from linux to my local windows powershell.
Expected Behavior
Commands executed by the agent and any subagents should continue running in the remote Linux environment associated with the workspace.
hey @lordofpurewhite, thanks for your message, this seems like the same issue (kinda) as this thread :
So yeah, this looks like the same Remote SSH routing bug we’re tracking where shell execution flips to the local machine after a subagent runs @gus-at-fsp described the exact same parent-after-subagent pattern in this thread and a quick fix was also passed
Hey, thanks for the detailed report. I can see in the screenshot how execution jumps from bash remote to PowerShell after entering the subagent.
Yeah, this is a known class of bugs. In Remote SSH shell routing, after returning from a subagent it can flip to the local machine, in your case Windows PowerShell. Same parent-after-subagent pattern as in the thread Tom shared.
A working workaround that reliably pins routing to remote:
Explicitly set working_directory to an absolute remote path like /home/user/work/repo on every Shell call. You can bake this into a rule or prompt for subagents.
If the session drifts, quit and restart Cursor. This reliably re-anchors the remote context, like you noticed that a restart fixes it for a bit.
You’re on Nightly 3.5.38. The core fix for this class is already in recent stable builds, but the specific case where the parent flips after a subagent might not be fully covered. Please try updating to the latest stable and see if it still reproduces.
To help us debug, please turn off Privacy Mode and share the Request ID for a session where this reproduced: Chat menu top right > Copy Request ID. Also confirm if it reproduces again after a restart in a fresh session. I can’t give an ETA yet, but I’ll log the report.
