continue: Continue does not /edit remote VS Code files

Is your feature request related to a problem? Please describe. I use VS Code to remotely access my Linux server from my Windows PC via ssh. VS Code runs on Windows. When I use /edit <prompt> on a local Windows file, it works as expected. If I am connected remotely, Continue tries to access the file locally. For example, if I open /home/ubuntu/app.py on Linux, Continue tries to write to Windows \home\ubuntu\app.py instead.

Describe the solution you’d like Support for VS Code remote sessions.

Describe alternatives you’ve considered None.

Additional context VS Code remote is in common use by developers. In general, Linux is where a lot of code is run and debugged. But Windows (or Mac) are the general desktops.

About this issue

  • Original URL
  • State: closed
  • Created 10 months ago
  • Reactions: 1
  • Comments: 28 (17 by maintainers)

Most upvoted comments

@godimarcovr Just published an update, was a quick fix. Let me know if for some reason the problem persists

@godimarcovr definitely the path separator bug again - let me check this out today and get back with you, I think I know where to look

Hello @sestinj , thanks for this great extension! This is not solved for me even after updating and reinstalling everything. I have vscode running with the Continue extension running on my Windows laptop. When I open local folders, everything works. When I use Remote SSH on my Linux server, the /edit diff doesn’t appear, only the Question Answering works in the side chat. I get this error from the logs: Unable to read file ‘\home<myname>\code.…\name_of_current_file.py’ (Error: Unable to resolve nonexistent file).

Maybe it’s some path separator error? I see backslashes on this linux path. If it helps I have more info: I’m currently running the Continue server manually because it doesn’t start automatically for me. I’m running a llama-cpp server with my own model. Like I said everything works on local folders, but it doesn’t show a diff panel on Remote SSH, only normal QA works.

Ah this might explain a few other things. Must be a windows only issue.

Going to close this issue now that it’s resolved, but will create another for the failure to kill the old server

ok, was able to reproduce, know the source of the error. Have to attend to something else, but will have a push fixed later today

I was able to get it to work remotely finally. The issue was that the old Continue Server was still up and running, even when upgrading the plugin, even after VS Code was closed. You either have to reboot or manually kill the run.exe process that is spawned.

To get a full clean Continue uninstall/install, you need to:

  • Uninstall Continue
  • Close VS Code
  • Kill any remaining run.exe processes (on Windows) or just reboot
  • Remove the $HOME/.continue directory
  • Start VS Code
  • Install Continue clean

Thanks for the fix!

@lonestriker @A-De-Almeida Solution is ready in the latest version. I was able to setup WSL on my own Windows machine and verify that it works there, so with higher confidence the fix is for real this time.

Not having much luck. I’ve tried uninstalling Continue, exiting VS Code, starting VS Code, and installing Continue. Still get the wrong path separators for my remote file; \home\ubuntu\blah.py instead of /home/ubuntu/blah.py.

I also seem to be getting the /edit command repeated in my prompt, even though I’ve only specified it once:

/edit /edit write hello world in python

@sestinj I get this error when trying to edit the file in wsl image

@A-De-Almeida @lonestriker Finally got it!

There’s a small chance you’ll need to uninstall Continue, quit VS Code, then restart and redownload. At first, I dowloaded the new version and it was only updating in my non-SSH windows. Either something odd about how VS Code updates extensions, or I was just mistaken in thinking I had updated. Regardless, I’m now able to /edit on remote SSH

Yeah, v0.0.335 got through one layer of the problem, but this ended up slightly deeper than I originally thought. I think I have the solutions, just working on setting up an SSH env to test before pushing too many versions

Yes, that’s the error

Great! Already reproduced myself on an EC2. Def a bug : ( I’ll let you know soon when there’s a fix