Skip to content

fix: Windows quick start (cross-shell initializeCommand) + install the Dev Containers extension (1.8.2) - #102

Merged
terchris merged 2 commits into
mainfrom
fix/windows-quickstart
Sep 25, 2026
Merged

terchris merged 2 commits into
mainfrom
fix/windows-quickstart

Conversation

@terchris

Copy link
Copy Markdown
Collaborator

Fixes the Windows Quick Start. Terje reported on 2026-09-24 that it doesn't work on Windows.

The bug

devcontainer-user-template.json had a bash-only initializeCommand. The devcontainers CLI (the engine behind VS Code) runs a string initializeCommand with cmd.exe /c on Windows (devcontainers/cli src/spec-node/utils.ts, runInitializeCommand), and a non-zero exit stops the container from starting. It regressed in 733dd73 (2026-04-07), after the Windows-specific command from February was dropped in the single shared template (d07e842).

The fix

ver || sh -c "mkdir -p .devcontainer.secrets/env-vars && { hostname -s 2>/dev/null || hostname; } > .devcontainer.secrets/env-vars/.host-hostname; true"
  • cmd.exe: ver succeeds and || skips the rest.
  • /bin/sh: ver doesn't exist, so the capture runs and ends in true.
  • Windows gets the hostname from COMPUTERNAME via remoteEnv instead, which config-host-info.sh already checks first.

Also in this PR

  • New Host Commands workflow:
    • windows-latest runs initializeCommand through the real devcontainers CLI 0.89.0, the same cmd.exe /c path and quoting as VS Code.
    • A control step must see the old bash-only command fail.
    • Linux runs it with /bin/sh.
  • install.ps1 / install.sh install the VS Code Dev Containers extension for the user, with no admin. They find code in the user/system install folders or the macOS app bundle when it isn't on PATH. VS Code itself comes from Intune. Until PLAN-fix-windows-quickstart task 2.1 lands, a missing VS Code only prints a warning.
  • The contributor docs are corrected, and the plans are updated.
  • Version 1.8.2.

Verification

  • Measured here:
    • The new command under /bin/sh writes .host-hostname.
    • install.sh is shellcheck-clean, and its step 4b ran against a stub code (both the install and the skip case).
    • install.ps1 parses with 0 errors and has 0 PSScriptAnalyzer findings apart from PSAvoidUsingWriteHost.
    • npm run build passes.
  • Not yet measured: anything on real Windows. This PR's Host Commands run is the first time, and Terje's PC test follows after merge.

🤖 Generated with Claude Code

terchris and others added 2 commits September 25, 2026 13:58
…e Dev Containers extension

The template's initializeCommand was bash-only, but devcontainers/cli runs
it with cmd.exe /c on Windows (src/spec-node/utils.ts). The command failed
there, so VS Code could not start the container on any new Windows install
since 733dd73 (2026-04-07). The new command is valid in both shells:
cmd.exe runs `ver` and skips the rest; /bin/sh runs the hostname capture.
Windows gets the hostname from COMPUTERNAME via remoteEnv instead.

- New Host Commands workflow: runs initializeCommand through the real
  devcontainers CLI (0.89.0) on windows-latest, with a control that must
  see the old bash-only command fail, plus a /bin/sh check on Linux.
- install.ps1 / install.sh now install the VS Code Dev Containers
  extension for the user (no admin), finding `code` in the user/system
  install folders or the macOS app bundle when it is not on PATH. VS Code
  itself comes from Intune (Terje, 2026-09-25).
- Contributor docs corrected: they still showed the old command and
  claimed the hostname file is written on Windows.
- Plans: PLAN-fix-windows-quickstart moved to active; the handover
  contract agreed with client-provisioning (urb-agents #1505, #1514,
  #1533) recorded in PLAN-host-installer-handover.
- Version 1.8.2.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…atches a normal PC

GitHub's windows-latest runner has Git for Windows' usr\bin (true.exe) on PATH.
The old bash-only initializeCommand ended in that real `true` and exited 0, so
the control step could not see the bug. A normal office PC has no Unix tools on
PATH. Strip them and refuse to run if a Unix `true` is still found. Wording
corrected: the bug hits PCs without Unix tools on PATH, not literally every PC.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@terchris
terchris marked this pull request as ready for review September 25, 2026 12:11
@terchris
terchris merged commit ee12cfc into main Sep 25, 2026
8 checks passed
@terchris
terchris deleted the fix/windows-quickstart branch September 25, 2026 12:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant