• VSCode Version: 1.63.2
• Local OS Version: Microsoft Windows 10 Enterprise 10.0.19044
• Remote OS Version: Linux jpb.cdn-dev.ko1.os.scif.cz 4.19.0-18-amd64 #1 SMP Debian 4.19.208-1 (2021-09-29) x86_64 GNU/Linux
• Remote Extension/Connection Type: Docker over SSH

Steps to Reproduce:

1. Ensure you have two machines:

• local machine with Windows 10, VSCode, running X server (eg. VcXSrv) and ssh client configured to X forward to the remote machine
• remote machine with Linux, x11-apps, Docker, configured to accept X forwarding over SSH

2. Add this to .profile on the remote machine: (based on this SO answer: https://stackoverflow.com/a/48235281/6099426)

xauth nlist $DISPLAY | sed -e 's/^..../ffff/' | sudo xauth -f /tmp/.docker.xauth nmerge - && sudo chmod 777 /tmp/.docker.xauth
export DISPLAY=$(echo $DISPLAY | sed 's/^[^:]*\(.*\)/172.17.0.1\1/')
export XAUTHORITY=/tmp/.docker.xauth

3. From VSCode, open a folder on the remote using SSH
4. In VSCode terminal (so on the remote) run echo $DISPLAY $XAUTHORITY and ensure the output is 172.17.0.1:10.0 /tmp/.docker.xauth (number after : may be different)
5. Ensure that running xeyes displays eyes (X forwarding to remote works)
6. Ensure that running sudo docker run -ti --rm -e DISPLAY -e XAUTHORITY -v /tmp/.docker.xauth:/tmp/.docker.xauth fr3nd/xeyes displays eyes (X forwarding to remote docker works)
7. Add the following devcontainer.json configuration, equivalent to the CLI call above:

{
    "image": "fr3nd/xeyes",
    "initializeCommand": "echo $DISPLAY $XAUTHORITY",
    "runArgs": [
        "-e", "DISPLAY",
        "-e", "XAUTHORITY",
        "-v", "/tmp/.docker.xauth:/tmp/.docker.xauth"
    ],
}

8. Reopen in container and in the terminal (so now inside the container) run xeyes -- this produces error Error: Can't open display: 127.0.0.1:0.0
9. Check output of the initializeCommand (which runs on the host machine) and compare with the output of the command from step 4 (ran on the same machine using remote SSH directly) -- the value of DISPLAY will be different, probably because the container is opened through a new SSH connection, without X forwarding enabled