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)

Open
#11,460 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

ssh
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.useLocalServer setting
  • 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
  1. Set up a remote Docker daemon on a Linux host.
  2. Forward the Docker socket to the local machine (e.g. SSH tunnel).
  3. 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.