microsoft / microsoft/vscode-remote-release
remote.SSH.localServerDownload ignored when opening remote Docker containers via Remote-SSH (“Open in VS Code” copies server from client)
Nobody has claimed this yet.
- Dominant language
- Dockerfile
- Stars
- 4.2k
- Forks
- 469
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 1
Description
Is there an existing issue for this bug?
- I have searched the existing open issues and found none that apply.
- If I find any issue of interest that is related or closed, I will included a link to it in this issue.
Required Troubleshooting Steps
- I have read and performed the troubleshooting steps
- I have tried both values of the
remote.SSH.useLocalServersetting - My issue was not covered in the Tips and Tricks linked from the Troubleshooting Wiki.
- I will include a complete copy of my Remote - SSH logs by running Remote-SSH: Show Log in the command palette or from View > Output in the menu bar
[Optional] Diagnose with Copilot
I did not ask the @remote-ssh participant for help
In step 2 of the troubleshooting wiki, what was the result of running the generated SSH command verbatim outside of VS Code?
I did not try step 2 of the troubleshooting steps
Remote-SSH Log
Remote-SSH Log
[14:03:58.217] Log Level: 2
[14:03:58.384] VS Code version: 1.108.2
[14:03:58.384] Remote-SSH version: remote-ssh@0.122.0
[14:03:58.384] darwin arm64
[14:03:58.409] Opening exec server for ssh-remote+container.pc-vanves.1000.local
[14:03:58.453] Initizing new exec server for ssh-remote+container.pc-vanves.1000.local
[14:03:58.455] Acquiring local install lock: /var/folders/t8/stzpb5_13fg1jwz_5k0tc1c00000gn/T/vscode-remote-ssh-6e1fc6a3-install.lock
[14:03:58.456] Looking for existing server data file at /Users/davidberichon/Library/Application Support/Code/User/globalStorage/ms-vscode-remote.remote-ssh/vscode-ssh-host-6e1fc6a3-c9d77990917f3102ada88be140d28b038d1dd7c7-0.122.0-es/data.json
[14:03:58.456] Found existing data file
[14:03:58.457] Found local server running: {"remoteListeningOn":{"port":42119},"osReleaseId":"debian","arch":"x86_64","sshAuthSock":"/tmp/ssh-cNDIyBoDrW/agent.206005","display":"","tmpDir":"/tmp","platform":"linux","execServerToken":"d54ac15d-a358-4fae-8b09-054779e784b0","pid":82124,"ipcHandlePath":"/var/folders/t8/stzpb5_13fg1jwz_5k0tc1c00000gn/T/vscode-ssh-askpass-f03649afda00a48b39eacaa6fca496857cf1d934.sock","socksPort":61136,"startupTime":1769408631379}
[14:03:58.463] Found running server - short-circuiting install
[14:03:58.466] Starting forwarding server. local port 62851 -> socksPort 61136 -> remotePort 42119
[14:03:58.466] Forwarding server listening on port 62851
[14:03:58.466] Waiting for ssh tunnel to be ready
[14:03:58.467] Tunneled port 42119 to local port 62851
[14:03:58.467] Resolved "ssh-remote+container.pc-vanves.1000.local" to "port 62851"
[14:03:58.467] Resolving exec server at port 62851
[14:03:58.468] [Forwarding server port 62851] Got connection 0
[14:03:58.468] [Forwarding server port 62851] Got connection 1
[14:03:59.133] Exec server for ssh-remote+container.pc-vanves.1000.local created and cached
[14:03:59.133] No hints found in the recent session.
Expected Behavior
Expected Behavior
• VS Code should respect remote.SSH.localServerDownload.
• When disabled, the VS Code Server should not be downloaded on the local machine and SCPed to the remote host.
• Containers running on a remote Docker daemon should be treated as remote, even if the socket is forwarded locally.
Actual Behavior
Actual Behavior
• VS Code downloads the VS Code Server on the local machine.
• The server is then copied to the remote host via SCP.
• The remote.SSH.localServerDownload setting appears to be ignored.
• VS Code seems to classify Docker as local based solely on socket locality, not on where containers actually run.
Steps To Reproduce
- Set up a remote Docker daemon on a Linux host.
- Forward the Docker socket to the local machine (e.g. SSH tunnel).
- On the local machine, export:
export DOCKER_HOST=http://localhost:23750
{
"remote.SSH.localServerDownload": "off"
}
(also tested with "never" and "always").
5. Connect to the remote machine using Remote - SSH.
6. Open a Dev Container or use Attach to Container (the container is running on the remote host).
7. Observe VS Code behavior during connection/startup.
Anything else?
-
VSCode Version: 1.108.2
1.xx.x (Stable)
(also reproduced on latest version at the time of writing) -
Local OS Version:
macOS (Apple Silicon) / Linux client -
Remote OS Version:
Linux (remote host) -
Remote Extension/Connection Type:
Remote - SSH
(with Dev Containers / Attach to Container) -
Logs:
Can be provided if requested.
The behavior is observable without verbose logs: VS Code downloads the VS Code Server locally and SCPs it to the remote host despite the configuration below.
Additional Notes
• This setup is common in remote development, CI/self‑hosted runners, and low‑bandwidth environments.
• The issue is particularly problematic on metered connections (e.g. 4G), where large server downloads are unexpected and costly.
• Other users report similar behavior:
https://github.com/microsoft/vscode-remote-release/issues/9330
⸻
Does this issue occur when you try this locally?:
No (Docker daemon is truly local)
Does this issue occur when you try this locally and all extensions are disabled?:
No
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the setup with a remote Docker daemon, a forwarded socket, DOCKER_HOST=http://localhost:23750, and remote.SSH.localServerDownload set to off. Start with the Remote-SSH: Show Log output and compare behavior for a truly local Docker daemon versus the remote container case. Done means the setting is respected and the container is classified according to where it runs, without an unexpected local download and SCP.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker
- Domain
- devops, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100