It seems to support X11 forwarding but in a misconfigured state. Specifically $DISPLAY environment variable is missing. Merely setting export DISPLAY=:1 makes it work.
For comparison VSCode devcontainer extension does not have this quirk and supports X11 forwarding flawlessly.
Steps to Reproduce
Try install and run glxgears.
Expected Behavior
It should work without explicitly setting the variable like DISPLAY=:1 glxgears.
Hey, thanks for the report. You’re right, this is a bug. The devcontainer extension doesn’t pass $DISPLAY from the host into the container. A similar fix was already done for Remote SSH, but devcontainers were missed.
For now, the workaround is what you found. Set export DISPLAY=:1 inside the container. You can automate it via postStartCommand in devcontainer.json:
"postStartCommand": "export DISPLAY=:1"
Or via remoteEnv:
"remoteEnv": {
"DISPLAY": "${localEnv:DISPLAY}"
}
I’ve shared this with the team. No ETA yet, but your report helps with prioritization. Let me know if the workaround doesn’t work.
To begin with vscode, i reopen the project in container and do echo $DISPLAY and it returns nothing, doing glxgears returns Error: couldn't open display (null) .
I have XQuartz installed locally.
What am I missing ? or should i try on linux (locally) ?
Currently I’m reproducing it in WSL with Ubuntu guest & Docker Desktop on WSL2 backend. In my workplace it’s Ubuntu machine with Docker CE, but I don’t think vscode behaves differently from there. I can try on Monday (KST) if you want a full coverage.