Cannot read properties of undefined (reading 'toString') against Docker 29.x — extension fails before container start

The Dev Containers extension crashes with TypeError: Cannot read properties of undefined (reading 'toString') immediately after probing docker version against a Docker Engine 29.x host. The crash happens before any container build is attempted. The standalone @devcontainers/cli (v0.87.0) handles the same workspace and same Docker daemon without issue, so the spec implementation is fine — only the extension's parsing of docker version --format json output appears broken.

This looks like the same crash family as #11030 (reported against Podman 5.2.2), but reproduces independently with Docker 29 — suggesting the root cause is the extension's tolerance of variation in docker version output, not anything Podman-specific.

Environment

• VS Code: stable, on Windows 10/11 (client)
• Dev Containers extension: 0.459.0 (also reproduces on the matching pre-release)
• Remote: Remote-SSH into Linux host
• Host OS: RHEL 8.10 aarch64 (4.18.0-553.120.1.el8_10.aarch64)
• Docker: 29.4.1 (client and server, API 1.54)
• @devcontainers/cli (as a comparison): 0.87.0 — works fine against the same daemon

Steps to reproduce

1. From VS Code on Windows, Remote-SSH into a Linux host running Docker 29.x.
2. Open any folder containing a minimal .devcontainer/devcontainer.json (e.g. just mcr.microsoft.com/devcontainers/python:3.12).
3. Run Dev Containers: Reopen in Container (or Open Folder in Container...).

Expected

Container builds/starts, VS Code attaches.

Actual

Extension throws and aborts before any build:

[...] Start: Run in host: docker version --format {{json .}}
[...] {"Client":{"Platform":{"Name":"Docker Engine - Community"},"Version":"29.4.1","ApiVersion":"1.54","DefaultAPIVersion":"1.54","GitCommit":"055a478","GoVersion":"go1.26.2","Os":"linux","Arch":"arm64","BuildTime":"Mon Apr 20 16:33:25 2026","Context":"default"},"Server":{ ... }}
[...] TypeError: Cannot read properties of undefined (reading 'toString')
        at d1 (c:\Users\<me>\.vscode\extensions\ms-vscode-remote.remote-containers-0.459.0\dist\extension\extension.js:341:44851)

Probable root cause

Docker 29's docker version --format json output has a flatter Client shape than 28.x and earlier — in particular, there is no Client.Components array. The Client object now exposes fields like Platform, Version, ApiVersion, Os, Arch, BuildTime directly:

{
  "Client": {
    "Platform": { "Name": "Docker Engine - Community" },
    "Version": "29.4.1",
    "ApiVersion": "1.54",
    "DefaultAPIVersion": "1.54",
    "GitCommit": "055a478",
    "GoVersion": "go1.26.2",
    "Os": "linux",
    "Arch": "arm64",
    "BuildTime": "Mon Apr 20 16:33:25 2026",
    "Context": "default"
  },
  "Server": { "...": "..." }
}

The stack trace points at d1 in the bundled extension, immediately after this JSON is logged. The most likely failure is a .toString() on a field reached via Client.Components.find(...) or similar, which is now undefined.

What works as a workaround

The standalone @devcontainers/cli succeeds on the same host:

devcontainer up --workspace-folder /path/to/workspace

After which Dev Containers: Attach to Running Container... in VS Code works (it skips the failing probe path). This confirms the bug is in the extension's pre-build probe, not in the dev container spec implementation.

Suggested fix

Treat missing Client.Components (and any other field absent in 29.x's output) defensively — fall back to top-level Client.Version / Client.ApiVersion when the Components array isn't present, since Docker 29 surfaces the same data at the top level of Client.

Related

• #11030 — same crash signature against Podman 5.2.2 on RHEL 9, extension 0.417.0. Likely the same underlying brittleness in docker version parsing.
• #10027 — earlier example of fragile Docker version parsing (Docker 24.0.7 misidentified as <17.12).