Change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.72.0 (also happens on Codespaces) OS Version: Windows 11; Version 10.0. Build (also happens on Codespaces) I was trying to get a development VS Code OSS build running with dev containers. After following the steps from , I only got the following error when trying to execute : My / command beforehand runs without errors. The noVNC web interface shows this: !
Maybe Christoph could advice how to setup the container to allow to run VS Code given his work in this field.
I was going to setup my dev environment the "normal" way, but then I noticed the dev container config and thought it would be cool to try that out :) Thanks in advance for helping!
Not sure how to debug this, there is an empty event object coming from for many or all script files.
Hi! I have the same issue OS VERSION: Edition Windows 11 Pro Version 22H2 Installed on ‎07/‎05/‎2022 OS build .900 Experience Windows Feature Experience Pack 1000..1000.0 VS CODE: commit (grafted, HEAD -main, origin/main, origin/HEAD) [EDIT] Updated OS build to .963 and the issue still persist. Docker version: Docker Desktop 4.15.0 ()
Is there anything that can be done about this or is there an ETA for when? I'd love to get started with solving issues for the VSCode project :D Otherwise, I can also try to get the "usual" way to develop it locally to run but I'd love to use dev containers :)
Needs further investigation. We will also add a simpler configuration that should hopefully be more robust as part of
The following is burried in all the other log messages, could this be the root cause? Interestingly the Insiders build works in the container.
I am not sure I follow, isnt this about running VSCode out of sources in a container? How is insiders related?
I don't know if it is relevant, but the problem when running out of sources doesn't reproduce with Insiders when run in the same container.
I have run Git bisect on this: is the first bad commit Date: Mon Mar 21 02:36:00 2022 +0900 chore: bump electron
Still encountering this from devcontainer via vscode remote ssh using windows desktop client: See following stdout, however for X11 forwarding, the window never even renders on the local running Xserver. <details<summarystdout</summary</detailsUsing the prebuilt devcontainer produces the same result for me as already reported. Not being able to open the file descriptor wouldn't be related to docker's changing default for LimitNOFILE would it? My system info if at all helpful: VS Code version: Code 1.77.1 (, 2023-04-04T23:21:11.906Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: No Remote OS version: Linux x64 5.19.0-38-generic Remote OS version: Linux x64 5.19.0-38-generic <details<summarySystem Info</summary </details<details<summaryExtensions (11)</summaryExtensionVersion ------ vscode-empy0.1.1 jupyter-keymap1.1.0 remote-containers0.288.0 remote-ssh0.100.0 remote-ssh-edit0.84.0 remote-wsl0.77.0 vscode-remote-extensionpack0.24.0 remote-explorer0.4.0 remote-server1.0.0 vscode-eslint2.4.0 resourcemonitor1.0.7 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Upstream issue: Please start with as a workaround.

Discussion:
code-wsl "$@" elif [ -f /mnt/wslg/versions.txt ]; then code --disable-gpu "$@" <ins> elif [ -f /.dockerenv ]; then # Workaround for https://bugs.chromium.org/p/chromium/issues/detail?id=1263267 # Chromium does not release shared memory when streaming scripts # which might exhaust the available resources in the container environment # leading to failed script loading. code --disable-dev-shm-usage "$@" </ins> else code "$@" fi