Feature Request: Allow `devcontainer.json` to pass server-side startup args (e.g. `--enable-proposed-api`) to VS Code Server

Summary

When using Dev Containers, there is currently no way to configure the VS Code Server's startup arguments from devcontainer.json. Specifically, --enable-proposed-api can only be set via the local client's argv.json, which means a team cannot distribute this configuration as part of the dev container definition.

Motivation

The Missing Link for Standardized AI-Assisted Development

Modern AI-assisted development workflows increasingly rely on:

1. Git worktrees — one worktree per feature branch, enabling isolated parallel development contexts
2. Dev containers — per-worktree devcontainers for fully reproducible, hermetic environments
3. Portless tunnel aliases (via vscode.proposed.tunnels or similar) — giving each worktree a stable, predictable, human-readable URL (e.g. my-app-feature-x.devtunnels.ms) instead of an ephemeral localhost:XXXXX port

The combination delivers: standardized environment (devcontainer) + stable/independent verification endpoint (portless alias) = consistent, automatable CI/CD and AI agent review loops.

Today, the vscode.proposed.tunnels API is the only way to programmatically create portless named tunnel aliases from inside a container. But using it requires:

• --enable-proposed-api=<extension-id> on the VS Code Server process
• Which is only configurable via the local client's argv.json

This breaks the devcontainer promise of a self-contained, shareable environment definition.

Current Workaround (Insufficient)

// devcontainer.json
{
  "postCreateCommand": "echo '⚠️  Please add {\"enable-proposed-api\":[\"my.ext\"]} to your local argv.json'"
}

This requires every developer to manually edit a local file — untenable for team setups.

Proposed Solution

Option A: New customizations.vscode.serverArgs field

{
  "customizations": {
    "vscode": {
      "extensions": ["my-publisher.my-extension"],
      "settings": { ... },
      "serverArgs": {
        "enable-proposed-api": ["my-publisher.my-extension"]
      }
    }
  }
}

The Dev Containers extension would forward these args when spawning the VS Code Server process.

Option B: Image-level metadata label

Allow a Docker image label (similar to existing devcontainer.metadata) to declare required server args:

LABEL devcontainer.metadata='[{"serverArgs": {"enable-proposed-api": ["my-publisher.my-extension"]}}]'

This would let prebuilt images carry their required server configuration.

Security Considerations

• enable-proposed-api only affects which extensions already installed in the container can call proposed APIs — it does not grant new network or filesystem permissions
• The devcontainer trust model (user explicitly opens/trusts the container) provides a natural gate

Reference

• vscode.proposed.tunnels d.ts: https://github.com/microsoft/vscode/blob/main/src/vscode-dts/vscode.proposed.tunnels.d.ts
• Server option confirmed in source: serverEnvironmentService.ts — 'enable-proposed-api': OPTIONS['enable-proposed-api']
• Related issue: https://github.com/microsoft/vscode-remote-release/issues/9981

cc @alexr00 @chrmarti @connor4312