Dev Container improvements

[sgraband]

What it does

Contributes to #14294

This PR adds several new features, bug fixes, and quality improvements to the dev container support in Theia:

New features:

• Variable resolver fixes: Handle variables embedded in strings in devcontainer.json (e.g. ${localEnv:HOME}/path)
• MountsContribution fix: Pass through all mount options (source, target, type) correctly instead of silently dropping them
• SettingsContribution fix: Fix JSON quoting when injecting preferences through the shell by base64-encoding complex objects
• portsAttributes support: Implement portsAttributes from devcontainer.json, allowing port labels, protocols, and auto-forward behavior to be configured
• Attach to Running Container: Add a command to attach to an already-running Docker container without a devcontainer.json
• SSH credential injection, git identity sharing, and shell detection: Automatically set up an isolated SSH directory with key forwarding, inject host .gitconfig (with SSH signing key rewriting), configure a login shell with SSH agent, and share host credentials into the container
• Auto-reopen in last active dev container after restart: On application restart, automatically reconnect to the previously used dev container
• Suggest to reopen workspace in dev container: When opening a workspace that contains a devcontainer.json, show a notification suggesting to reopen in a container
• Rebuild Container command: Add a command to rebuild the dev container from scratch (removing the old container) while preserving the devcontainer file context
• Ports view and port labels: Expose the Ports view in the remote package and display port labels from portsAttributes

How to test

Prerequisites: Docker must be installed and running.

1. Reopen in Container

   • Open a workspace that contains a .devcontainer/devcontainer.json
   • Run Dev Container: Reopen in Container from the command palette
   • Verify Theia connects to the container and the workspace is available

2. Suggestion notification

   • Open a workspace with a devcontainer.json from a local (non-remote) session
   • Verify a notification appears suggesting to reopen in a container
   • Click "Reopen in Container" and verify it works

3. Rebuild Container

   • While connected to a dev container, run Dev Container: Rebuild Container
   • Verify the old container is removed and a new one is created
   • Verify the workspace reconnects automatically

4. Attach to Running Container

   • Start a Docker container manually (e.g. docker run -it ubuntu bash)
   • Run Dev Container: Attach to Running Container
   • Select the running container and verify Theia connects

5. SSH credentials and git identity

   • Ensure you have ~/.ssh/config and ~/.gitconfig on the host
   • Reopen in a container and verify:
     • git config user.name and user.email are inherited
     • ssh -T git@github.com works (key forwarding)
     • SSH agent is running (echo $SSH_AUTH_SOCK)

6. Port forwarding with labels

   • Use a devcontainer.json with forwardPorts and portsAttributes (e.g. label, protocol)
   • Verify ports are forwarded and labels appear in the Ports view

7. Variable resolver with embedded variables

   • Use a devcontainer.json with variables embedded in strings, e.g.:

     { "remoteEnv": { "MY_VAR": "${localEnv:HOME}/projects" } }

   • Reopen in the container and verify echo $MY_VAR resolves to the host's $HOME/projects (not the literal ${localEnv:HOME} string)

8. Mount options pass-through

   • Add a mounts entry in devcontainer.json using the string form with extra options, e.g.:

     { "mounts": ["type=bind,source=${localEnv:HOME}/.config,target=/home/vscode/.config,readonly"] }

   • Reopen in the container and verify the mount exists (mount | grep .config), is read-only, and uses the correct source/target paths

9. Settings with complex JSON values

   • Add a complex (object/array) setting in devcontainer.json, e.g.:

     { "settings": { "editor.tokenColorCustomizations": { "comments": "#FF0000" } } }

   • Reopen in the container and verify the preference is applied correctly in the running Theia instance (open Settings and search for the key)
   • Previously, object values were broken by shell quoting when passed as --set-preference CLI arguments

10. Auto-reopen after restart

    • Connect to a dev container, then close and reopen Theia
    • Verify it automatically reconnects to the same container

Follow-ups

Breaking changes

• This PR introduces breaking changes and requires careful review. If yes, the breaking changes section in the changelog has been updated.

Attribution

Contributed on behalf of STMicroelectronics and TypeFox

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines
• User-facing text is internationalized using the nls service (for details, please see the Internationalization/Localization section in the Coding Guidelines)

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[ndoschek]

Thanks a lot for this PR @sgraband!
I tested it and things work well on my end 🎉
I've added a few inline comments, please have a look.

One bit of housekeeping: the commits reference several issues this PR fixes/contributes to, but they're not linked from the PR description yet. Could you add/link them?

On the bigger picture: a natural next step would be to make "open folder in dev container" smoother by having Theia determine the correct workspace folder automatically from the devcontainer metadata (workspaceFolder, mounts...) instead of relying on the user to navigate there. But of course fine as a follow-up.

[ndoschek]

The 15-second timeout may be too short for dev container reconnection. openWorkspace() calls doOpenInContainer() → connectToContainer(), which can pull Docker images, create containers, and set up remote connections which can easily exceed 15 seconds on first run or slow networks. When the timeout fires, it falls back to a local workspace while the container creation continues in the background, leading to a confusing state. Consider increasing the timeout or making it configurable.

[sgraband]

I feel like increasing the timeout to 2 minutes should be fine. Without configuration (for now). This should only really be relevant, when the user deleted the docker image and then restarts Theia and the dev container is the most recent workspace if i am not missing something. So this does not really happen that often i believe, therefore a setting is not really necessary imho.

[ndoschek]

ensureIsolatedSshDir() silently generates a new ed25519 keypair at ~/.theia/dev-container/ssh/id_ed25519 if none exists. While it logs a message asking the user to register the public key, auto-generating cryptographic material on the user's machine could be surprising. Consider making this opt-in or using a more prominent notification (e.g., via MessageService).

[ndoschek]

Hardcodes /bin/bash as the default shell. Some container images (e.g., Alpine-based) don't include bash. If /bin/bash doesn't exist, terminal sessions will fail to start. Consider detecting the available shell inside the container (e.g., which bash || which sh) in handlePostCreate, or at least falling back to /bin/sh.