The 5-minute timeout introduced in Remote-SSH version 1.0.43 causes server file copy operations to fail in low network speed environments, even with adjusted timeout settings

Support Bug Reports
,
1

Since version 1.0.43 of the Cursor extension’s Remote-SSH, the addition of a 5-minute timeout has caused an issue where server files cannot be copied to the remote environment under low network speed conditions. When I use Cursor to connect to CML, the Remote-SSH extension first copies the server files to CML. In versions prior to 1.0.39, this process would take 20 minutes. However, starting from version 1.0.43, due to the enforced 5-minute timeout, even after modifying "remote.SSH.connectTimeout": 30000 and "remote.SSH.serverShutdownTimeout": 30000, the connection is still forcibly terminated after 5 minutes:

2026-03-03 14:45:48.535 [info] Copying to remote… 290s elapsed

2026-03-03 14:45:58.336 [error] Copy SSH connection timed out after 300020ms without receiving any data

2026-03-03 14:45:58.541 [info] Copying to remote… 300s elapsed

2026-03-03 14:46:07.047 [info] Deleted local server file

2

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Cursor IDE
  • Cursor CLI
  • Background Agent (GitHub, Slack, Web, Linear)
  • BugBot
  • Somewhere else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)

For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

4

Hey, thanks for the report and the logs. They clearly show the issue.

I’ve already shared this with the team.

In the meantime, you can try this:

  1. Roll back the Remote SSH extension. Since everything worked on 1.0.39, you can pin that version:

    • Open the Extensions panel and search for “Remote - SSH”
    • Click the gear icon, then select “Install Another Version…”
    • Pick 1.0.39, or the latest version that worked for you

  2. Could you share your Cursor version? (Help > About Cursor > Copy) This will help the team investigate.

Let me know if rolling back unblocks you.

7

Hi Dean, thank you very much for the suggestion and the update, sure, I already did this action at yesterday, used the 1.0.39 version, it cost 20 minutes to finish the processing of copy server file to the remote. About the version of cursor, please check below. In my opinion, this issue might not be strongly related to the Cursor version itself, but rather requires adjustments to the Remote-SSH extension, such as adding a toggle option for the “copy to remote” timeout or providing an interface for timeout adjustments.

Version: 2.5.26 (user setup)
VSCode Version: 1.105.1
Commit: 7d96c2a03bb088ad367615e9da1a3fe20fbbc6a0
Date: 2026-02-26T04:57:56.825Z
Build Type: Stable
Release Track: Default
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

8

Hi Dean, is there any update about this issue? I’m looking forward to the good news, thanks in advance.

9

Hey, thanks for the version info and feedback. It’s helpful.

The bug has been logged and passed to the team. No ETA yet, but your report and logs help us prioritize it. I’ll update the thread if there’s any news.

For now, rolling back to 1.0.39 is the best workaround. Your suggestion about a configurable timeout for copy operations has been passed along too.

10

Hi Dean,

Thank you for the update and for logging the bug with the team. I’m glad to hear that my report and suggestion about a configurable timeout were helpful.

For now, rolling back to version 1.0.39 has been working as a temporary solution. I’ll continue using this version until the issue is resolved.

Please feel free to reach out if there’s anything else I can do to assist. I appreciate your efforts and look forward to any updates on this.

Best regards,

Guangyu

12

This should be fixed now @Guangyu_Hu! Give 1.0.46 a try.