devcontainers
Opening interactive shells via exec subcommand is unresponsive
When attempting to open an interactive shell session via the devcontainer exec sub-command, the resulting shell becomes unresponsive after invoking the first command in that shell, as can be viewed via this screen recording:
https://github.com/devcontainers/cli/assets/2293573/01d460d3-a3d2-4f72-863b-6af03ff66631
- Dev Container CLI Version:
$ devcontainer --version
0.58.0
- VSCode Version:
Version: 1.88.0
Commit: 5c3e652f63e798a5ac2f31ffd0d863669328dc4c
Date: 2024-04-03T13:25:57.039Z
Electron: 28.2.8
ElectronBuildId: 27744544
Chromium: 120.0.6099.291
Node.js: 18.18.2
V8: 12.0.267.19-electron.0
OS: Linux x64 6.5.0-26-generic
- Local OS Version: Linux x64 6.5.0-26-generic
- Remote OS Version: Linux x64 6.5.0-26-generic
- Remote Extension/Connection Type: Containers (v0.354.0)
- Docker Version:
$ docker version
Client: Docker Engine - Community
Version: 26.0.0
API version: 1.45
Go version: go1.21.8
Git commit: 2ae903e
Built: Wed Mar 20 15:17:48 2024
OS/Arch: linux/amd64
Context: default
Server: Docker Engine - Community
Engine:
Version: 26.0.0
API version: 1.45 (minimum version 1.24)
Go version: go1.21.8
Git commit: 8b79278
Built: Wed Mar 20 15:17:48 2024
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.28
GitCommit: ae07eda36dd25f8a1b98dfbf587313b99c0190bb
runc:
Version: 1.1.12
GitCommit: v1.1.12-0-g51d5e94
docker-init:
Version: 0.19.0
GitCommit: de40ad0
Steps to Reproduce:
- Using the minimal config file as below included in
$(pwd)/.devcontainer/devcontainer.json -
devcontainer build -
devcontainer up -
devcontainer exec whoamito test that container is running withvscodeprinted to stdout -
devcontainer exec bashor useshto spawn an interactive shell - enter any valid shell command and not that it immediately becomes unresponsive
- Choice of shell, terminal emulator, or host machine seems to make no difference
{
"name": "Ubuntu",
"image": "mcr.microsoft.com/devcontainers/base:jammy"
}
Note: when attempting to paste commands via CRTL+SHIT+V or move the cursor, one can view the raw escape sequence values for bracketed paste mode or arrow keys presses rendered on the client shell.
ruffsl@box:~/ws/devcontainer_cli_bug$ devcontainer exec bash
vscode ➜ /workspaces/devcontainer_cli_bug $ ^[[200~whoami^[[201~
^C
Hi 👋
Thanks for opening a detailed issue.
Choice of shell, terminal emulator, or host machine seems to make no difference
Interesting that I wasn't able to reproduce the issue with @devcontainers/cli 0.58.0. However, my machine configuration is different than yours which could make a difference 👇
@devcontainers/cli 0.58.0. Node.js v16.18.0. darwin 23.4.0 arm64.
Note: when attempting to paste commands via CRTL+SHIT+V or move the cursor, one can view the raw escape sequence values for bracketed paste mode or arrow keys presses rendered on the client shell.
It seems like the terminal is not interpreting the pasted command correctly, and instead is printing the raw escape sequences. This could be due to a misconfiguration in your terminal settings (especially with terminal emulator)
@ruffsl Does the issue reproduce only for mcr.microsoft.com/devcontainers/base:jammy image? Can you test with other images as well? (eg. mcr.microsoft.com/devcontainers/base:bullesye / mcr.microsoft.com/devcontainers/base:focal / ubuntu:latest etc)
I only get this issue when i use the devcontainer command found at /usr/local/bin/devcontainer on my machine. Presumably the one installed from vscode?
Meanwhile, running npx devcontainer exec --workspace-folder . zsh works just fine.
Running devcontainer --version yields 0.58.0 on both
Can you test with other images as well?
@samruddhikhandale: Yes, this issue persists for those images, as well as my own custom images from ubuntu:24.04, so I'm don't think the base image for the dev container is the common denominator here.
I only get this issue when i use the devcontainer command found at /usr/local/bin/devcontainer on my machine. Presumably the one installed from vscode?
@Restraint: Good find. Yep, this only seems to exhibit itself in the binaries provided by VSCode. If if build the main branch from source, and use that CLI binary instead, the exec sub command works as expected.
~/git/devcontainers/cli$ devcontainer exec bash
node ➜ /workspaces/cli (main) $ whoami
^C
~/git/devcontainers/cli$ node devcontainer.js --version
0.60.0
~/git/devcontainers/cli$ node devcontainer.js exec --workspace-folder . bash
node ➜ /workspaces/cli (main) $ whoami
node
node ➜ /workspaces/cli (main) $ ls
CHANGELOG.md CONTRIBUTING.md README.md azure-pipelines.yml devcontainer.js docs example-usage node_modules scripts tsconfig.base.json tsfmt.json
CODEOWNERS LICENSE.txt ThirdPartyNotices.txt build dist esbuild.js images package.json src tsconfig.json yarn.lock
Update: This issues seem to persist with with the latest CLI binaries installed with the latest version of VSCode:
$ devcontainer --version
0.59.1
Yep, this only seems to exhibit itself in the binaries provided by VSCode.
In my testing, I was using the CLI installed with https://www.npmjs.com/package/@devcontainers/cli. No wonder I wasn't able to reproduce 😅 Thanks @Restraint for pointing out that difference.
@chrmarti Do you know why the CLI behaves differently when installed with NPM versus when it is available in the VS Code library? I wonder if the binaries people are referring to are installed via the Dev Containers Extension, where there might be some special casing with VS Code.
@Restraint @ruffsl Can you both use https://www.npmjs.com/package/@devcontainers/cli to unblock yourselves? Using the CLI installed with the NPM package should ideally be the right way of consuming the CLI. Thanks!
This appears to be a bug in the wrapper we have in the Dev Containers extension.
Update: Issues still persists with with the latest CLI binaries installed with the latest version of VSCode:
$ code --version
1.90.0
89de5a8d4d6205e5b11647eb6a74844ca23d2573
x64
$ devcontainer --version
0.62.0
