I did some experimentation to verify the role of --id-label, and what I found is that it's not really needed when invoking @devcontainers/cli or VS Code devcontainer extension without any custom options.

For instance, "entering devcontainer" in VS Code does not specify any custom labels, these defaults will be used:

{
  "devcontainer.config_file": "/home/coder/coder/.devcontainer/devcontainer.json",
  "devcontainer.local_folder": "/home/coder/coder"
}

These are the same ones created by @devcontainers/cli. So running the following command works as expected:

cd ~/coder
devcontainer up --workspace-folder . --remove-existing-container

VS Code is also able to connect into the new container created by @devcontainers/cli.

Where things get a bit interesting is when --id-label is being manually specified.

For instance, a dev container started with:

devcontainer up --id-label coder=coder --workspace-folder . --remove-existing-container

Will not create either devcontainer.config_file nor devcontainer.local_folder labels, and instead only add the following label:

{
  "coder": "coder"
}

This devcontainer won't be detected by VS Code and will also be filtered out by our current agentcontainers implementation/usage.

We don't need to support the custom label use-case, and we can always expect that devcontainer.local_folder=[workspace_folder] will be handled implicitly. The only case where I think --id-label matters is if a non-default path is used for devcontainer.config_file.

For container re-recreation, we can specify both from the docker container label just to be sure that's the one we re-create.