The Write and StrReplace tools (used by the AI to create and edit files) consistently return “Invalid arguments” when the workspace is opened via Remote-SSH from a Mac to a Windows host. The same tools work when the workspace is opened locally on either Mac or Windows. Read and terminal/shell tools work over SSH; only Write and StrReplace fail.
Steps to Reproduce
On a Mac, connect to a Windows machine using Cursor’s Remote-SSH (Remote - SSH) and open any project folder on the Windows host.
Start a new chat and ask the AI to create a file (e.g. “Create a file at test.txt in the project root with content ‘hello’”).
Ask the AI to edit that file (e.g. “Replace ‘hello’ with ‘world’ in that file”).
Observe: the AI’s Write and StrReplace tool calls return “Invalid arguments”. The same test run locally on the Mac or locally on the Windows machine succeeds.
Expected Behavior
Write and StrReplace should succeed over Remote-SSH to a Windows host, just as they do when the workspace is opened locally on Mac or Windows. File paths (relative or absolute) should be accepted and the file created/updated.
Workaround: When using Remote-SSH to Windows, use terminal commands (e.g. PowerShell Set-Content) to create/overwrite files, or open the folder locally on the Windows machine when the AI needs to use Write/StrReplace.
Hey, thanks for the detailed report. This is really helpful.
This is a known regression related to parsing Windows paths in Remote SSH sessions. The root cause is a UriError that happens when the agent tries to resolve file paths over an SSH connection to a Windows host. This has been reported a few times already, and it tends to come back in different versions.
Temporary workaround: try switching the bottom panel from Terminal to Output before running agent commands. In some cases this prevents the path parsing issue because the terminal context does not get collected.
Temporary workaround: try switching the bottom panel from Terminal to Output before running agent commands. In some cases this prevents the path parsing issue because the terminal context does not get collected.
Thanks i’m not seeing how this changes anything since i’m running into this bug in agent chats. The work around that’s worked has been setting up the following rule in cursorrules. Imperfect:
File Edits Fallback (Remote-SSH to Windows)
Why this is in place: When this workspace is opened via Remote-SSH from a Mac to a Windows host, Cursor’s Write and StrReplace tools consistently return “Invalid arguments.” The same tools work when the workspace is opened locally (Mac or Windows). This is a known Cursor limitation in the Remote-SSH (Mac to Windows) scenario. Until Cursor fixes it, use the fallback below when the tools fail.
Conditional behavior: Use Write and StrReplace as usual when they succeed (e.g. when working locally). Only when Write or StrReplace return “Invalid arguments” should you retry using PowerShell as described below.
Fallback procedure: If the Write or StrReplace tools return “Invalid arguments”:
Retry using PowerShell from the project (workspace) root.
Create/overwrite:Set-Content -Path "path\to\file" -Value "content". For multi-line content use an array of lines or a here-string (@" ... "@); prefer single quotes to avoid escaping.
Replace text:(Get-Content -Raw "path\to\file") -replace 'old','new' | Set-Content "path\to\file". When the text to replace contains regex metacharacters (e.g. .[]()*$), use [regex]::Escape('old') for the first argument: -replace [regex]::Escape('old'), 'new'. Omit -NoNewline unless you intend to strip a trailing newline (otherwise the file may lose its final newline).
Use paths relative to project root in both cases.
Alternatively, i’ve moved back to running cursor locally where needed.
To your questions:
When Write/StrReplace crashes, do you see a UriError in the devtools console (Help > Toggle Developer Tools > Console tab)?
No i don’t see UriError.
Is the Terminal panel open or visible when the error happens?
No the terminal open or visible when the error happens.
Which Remote SSH extension are you using, Anysphere or Microsoft? (CMD+Shift+X > search “Remote-SSH” > check the publisher)
Anysphere. Had issues getting microsoft to work initially.
Hi guys. Same issue — the strreplace and write tools are returning “invalid arguments.” Rolling back to version 2.2.44 fixed it. Are the developers aware of this?
Same here (mac → windows) is breaking again and again (edits not working, powershell install scripts break)… I now have to actively look for alternative workflows.
Would really appreciate if there would be a fix for this and some regression testing, at least for the basics (connect to a remote machine and edit a file).
I would like to second the previous comment. It is very unfortunate that core functionality is breaking because regression testing for Mac-to-Windows appears to be effectively nonexistent. To make matters worse, there has been no fix for weeks and no indication of when one will arrive.
This kind of situation pushes paying customers like me to look elsewhere. Reverting to a version from last year is not a real solution. When am I supposed to switch back? Am I now expected to keep monitoring these complaints, periodically retest, and then roll back again if it still does not work? With that level of effort, moving to another IDE seems like the more rational choice.
As I write this, my Cursor agent is struggling to modify my app and has left it in a broken state. I now have to roll back changes just to restore functionality.
This is genuinely disappointing. I expected Cursor to be my IDE for the long term, but that no longer seems feasible.
And consolidated them into one bug ticket on our side about Remote SSHing into a Windows machine. Hopefully this will help get some traction on a fix, and I’ll update this thread if there’s progress!
Thank you Colin. This is exactly the kind of a response I was hoping for. I am looking forward to a quick resolution so that we can all go back to enjoying Cursor again. Looking forward to hearing back on this. In the meantime, I’ll use agents outside Cursor and limit Cursor to Ask mode to apply changes manually. Thanks again.
Thanks. So far the best workaround i’ve come across has been to revert back to an older version of cursor. 2.4.27 passes Write/StrReplace testing. Every version fails in part or in whole.
instructions for how to get to this JSON for those not aware:
While in cursor
Windows/Linux:Ctrl + Shift + P -macOS:Cmd + Shift + P
Search for the file: Type “Open User Settings (JSON)” and press Enter.
Add the line: Paste the following line inside the curly braces { ... }. Ensure there is a comma after the previous line if you are adding it to the end.
“update.mode”: “manual”
Once saved, Cursor will no longer try to update itself automatically. If you ever want to turn updates back on, you can just change "manual" back to "default" or simply delete that line.
It is not, i see the exact same behaviour from osx → windows on cursor 3.0.12 really frustrating! the edit seems to work though, just the model gets feedback that the edit failed. If it understands that once it kind of still works but this seems to reduce quality of edits quite a lot.
It seems we are quite a few people impacted very negatively by this bug. I understand that there must be a ton of subjects you have to treat internally, but I think moving this to priority boarding could be beneficial for everyone
Thanks for the feedback here, and understand that this is super frusturating.
We do have a fix slated for the next release. It should hit the Nightly version soon (Cursor Settings > Beta > Update Access > Nightly). The first version with this fix should be client-3.1.0-pre.14.patch.0-nightly, which is even newer than my internal build )
really frustrating! the edit seems to work though, just the model gets feedback that the edit failed. If it understands that once it kind of still works but this seems to reduce quality of edits quite a lot.
)