Test: Dev Container sessions over SSH, Tunnels, and WSL

Refs: #336249, #336573, https://github.com/microsoft/vscode/issues/335485

- [ ] ssh
- [ ] anyOS (Dev Tunnel)
- [ ] wsl

Complexity: 4

Authors: @chrmarti

---

The Agents Window can now run Dev Container sessions from folders on SSH, Tunnel, and WSL hosts. **Test one transport; coordinate to cover all three.** WSL testing requires Windows with WSL 2; SSH and Tunnel testing can use any desktop OS and a Linux Docker host.

Below, **remote host** means the machine or environment running Docker. It can also be a Docker Sandbox or WSL distribution on your own machine.

## Set up

1. Use current Insiders on the desktop and an updated Agent Host on the remote host supporting remote Dev Containers. Updating only the desktop does not update an independently running Tunnel host. (Normally this will update automatically.)
2. Enable:
```json
{
"chat.remoteAgentHostsEnabled": true,
"chat.agentHost.devContainer.enabled": true
}
```
3. On the remote host, clone [vscode-remote-try-node](https://github.com/microsoft/vscode-remote-try-node) and verify `docker info` works.
- **No Docker host available?** [Docker Sandboxes](https://www.docker.com/products/docker-sandboxes/) is available on **macOS, Windows, and Linux** and provides a simple local Docker-enabled Linux host for **both SSH and Tunnel testing**. Use the installation instructions for your OS, then follow the sandbox creation and SSH setup in the [walkthrough](https://github.com/chrmarti/microvm-exploration/blob/main/sbx-walkthrough.sh) (its installation section is macOS-specific). The example repository is at `/home/agent/workspace/vscode-remote-try-node`.
- **SSH:** connect to your remote host, or `docker-sandbox.sbx` for the Docker Sandbox setup.
- **Tunnels:** install and start an Insiders tunnel CLI on the remote host (can be Docker Sandbox mentioned above) and use the same GitHub account on the desktop.
- **WSL:** use a WSL 2 distribution with Docker Desktop integration or Docker Engine. Clone the repository inside the distribution.
4. Leave **New Worktree disabled**. Install Dev Containers and the relevant Remote extension for the editor-opening check.
5. Open **View > Output** and locate the relevant **Agent Host** and **Dev Container** output channels. Collect their output if startup or a prompt fails; the Dev Container channel becomes available during container startup.

## Test

### Select the container

Connect to the remote host from the Agents Window and select the repository folder. Open the workspace picker, expand **Remote** if present, then open the folder's submenu and choose **Use Dev Container**.

Verify the label indicates container mode. Try switching to **Use Remote Host** and back. Check that the submenu is also keyboard-accessible.

For WSL, verify the correct distribution is selected.

### Run a prompt

Choose a non-default model and, if available, a custom agent or instruction. Submit:

> Show the current directory, hostname, and `/etc/os-release`, and check whether `/.dockerenv` exists. Create `devcontainer-session-test.txt` in the workspace containing a unique marker.

Verify:
- Startup progress is visible and the prompt runs **inside the container**, not directly on the remote host or desktop.
- The marker file appears in the remote host's repository folder, which is bind-mounted into the container.
- The selected model/customization is retained.
- A follow-up prompt can read the marker file.

Try sending promptly after selecting **Use Dev Container** to exercise startup timing.

### Open in VS Code

Use **Open in VS Code** from the session. Verify the editor opens the same container and workspace on the correct SSH host, Tunnel host, or WSL distribution, not a local folder.

For failures, include the transport, desktop and remote Agent Host versions, and relevant **Agent Host** and **Dev Container** output. Review logs for credentials or private content before sharing.

Choose one transport—SSH, Dev Tunnel, or WSL—and start by following the setup steps, cloning vscode-remote-try-node on the remote host and verifying docker info. Use the Agent Host and Dev Container output channels while selecting Use Dev Container, running the supplied prompt, and opening the session in VS Code. Done means the prompt runs inside the container, the marker persists in the remote workspace, and the editor opens the same remote container; record versions and sanitized logs for failures.

Written by the indexing model from the issue text.