Dev Container rebuild ignores custom user and extensions on debian:trixie base

[philly706869]

Problem

When using a debian:trixie base image in a Dev Container, after running
remote-containers.rebuildContainer, the configured non-root user and all extensions defined in
devcontainer.json and features are not applied. Instead, the container falls back to the root user
with no extensions installed.

Environment

• VS Code version: 1.103.2
• VS Code Dev Container version: 0.422.1
• Host OS: Windows 24H2 (build 26100.5074)

Reproduction Steps

1. Clone the repo: repo link
2. Open in VS Code and run command remote-containers.reopenInContainer.
3. Run command remote-containers.rebuildContainer.
4. Observe the applied user and extensions.

Expected Result

• The container uses the vscode user.
• All extensions defined in src/.devcontainer/devcontainer.json and features are applied.

Actual Result

• The container uses the root user.
• All extensions defined in src/.devcontainer/devcontainer.json and features are not applied.

Additional Context

• After pulling the image for the first time and opening it in the container, it works correctly.
• The issue occurs after running the remote-containers.rebuildContainer command.
• The issue persists even after exiting vscode and restarting it, or disconnecting and reconnecting to the container.
• The issue does not occur on debian:bookworm based images.
• Reproduction image build log: log link

[Kaniska244]

Hello @philly706869 ,

Thank you for reporting this issue and for the details provided. The dev container debian trixie(13) pre-built image has just been published last night.
Would you kindly try mcr.microsoft.com/devcontainers/base:trixie or mcr.microsoft.com/devcontainers/base:debian instead of using debian:trixie as the base image here and let me know if you are still facing the problem?

Kindly let me know in case of any other concern with this.

With Regards,
Kaniska

[philly706869]

Hello @Kaniska244 ,

Thank you for your reply.

I have tested using mcr.microsoft.com/devcontainers/base:trixie as suggested, using the base/trixie branch of my repository.
Unfortunately, the issue persists: after running remote-containers.rebuildContainer, the container still falls back to the root user and the extensions defined in devcontainer.json and features are not applied.

[Kaniska244]

Hello @philly706869 ,

Is this the right place to change the base image? Because in the respective devcontainer.json, I don't see any feature or customization added. I will also try to check this in parallel.

[philly706869]

Hello @Kaniska244 ,

Just to clarify the setup:

• The common-utils feature and extensions are defined in src/.devcontainer/devcontainer.json.
• The top-level .devcontainer/devcontainer.json only pulls in the image built from src/.devcontainer (the image was built with devcontainers/ci).
• Thus, the .devcontainer is just for using that built image, while the actual configuration is in src/.devcontainer.

Observations after rebuilding the container (remote-containers.rebuildContainer):

• The feature itself is applied (e.g., zsh is available).
• The non-root user created by common-utils (in reproduction repo, vscode) is not applied — the container falls back to root.
• Extensions defined in src/.devcontainer/devcontainer.json are also not applied.
  Therefore, the issue is specifically that the non-root user and extensions do not persist after a rebuild, even though the feature itself partially applies.

As a possible cause (though I’m not certain), it may be related to loading the devcontainer.metadata LABEL from the Docker image, which could explain why the user and extensions are not retained.

[philly706869]

Additionally, I confirmed that the extensions defined in .devcontainer/devcontainer.json are applied normally, even when an issue occurs.

[Kaniska244]

Hello @philly706869 ,

Thank you for the details. I will check further and get back to you.

[Kaniska244]

Hello @philly706869 ,

I tried by forking your repo but, unfortunately it doesn't get reproduced for me, So, I would probably require some more details to investigate this:

Would you kindly share the container log and previous log captures for this if possible, perhaps for both of the bookworm base image where its successful for you and the current trixie base image where the dev container doesn't log in with the remoteUser configured and I am sure that you would be already knowing that we can get them from VSCode command palette with Dev Containers: Show Previous Log or Dev Containers: Show Container Log options.

Also with trixie where it's logging in with root user, could you please verify if vscode user has even been created or not in the container?

vscode ➜ /workspace (main) $ cat /etc/passwd | grep vscode
vscode:x:1000:1000::/home/vscode:/bin/bash
vscode ➜ /workspace (main) $ 
vscode ➜ /workspace (main) $ cat /etc/group | grep vscode
vscode:x:1000:
vscode ➜ /workspace (main) $ 

[philly706869]

Hello @Kaniska244 ,

As requested, I've uploaded the logs to release.

• bookworm-init-log.txt – Log when first opening the bookworm container
• bookworm-rebuild-log.txt – Log after rebuilding the bookworm container
• trixie-init-log.txt – Log when first opening the trixie container
• trixie-rebuild-log.txt – Log after rebuilding the trixie container
• trixie-before-log.txt – Log when first opening the trixie container (captured using Show Previous Log command; almost the same as trixie-init-log.txt)
• trixie-terminal.txt – Terminal output verifying that the vscode user exists in the trixie container

# trixie-terminal.txt
root ➜ /workspace (main) $ cat /etc/passwd | grep vscode
vscode:x:1000:1000::/home/vscode:/bin/bash
root ➜ /workspace (main) $ cat /etc/group | grep vscode
vscode:x:1000:
root ➜ /workspace (main) $ 

As you can see, even after rebuild, the trixie container still has the vscode user.

[Kaniska244]

Hello @philly706869 ,

Thank you so much for all the details provided. After carefully checking and comparing the bookworm log vs the trixie log for the rebuild case, the problem is that as you had pointed out earlier, the devcontainer.metadata attribute doesn't have the feature, extension or remoteUser details populated.

In the trixie rebuild log you shared:

while sleep 1 & wait $$!; do :; done", "-"]
    labels:
      - 'devcontainer.local_folder=d:\philly706869\devcontainer-common-utils-feature-debian-trixie-issue'
      - 'devcontainer.config_file=d:\philly706869\devcontainer-common-utils-feature-debian-trixie-issue\.devcontainer\devcontainer.json'
      - 'devcontainer.metadata=[]'

In the bookworm rebuild log you shared:

while sleep 1 & wait $$!; do :; done", "-"]
    labels:
      - 'devcontainer.local_folder=d:\philly706869\devcontainer-common-utils-feature-debian-trixie-issue'
      - 'devcontainer.config_file=d:\philly706869\devcontainer-common-utils-feature-debian-trixie-issue\.devcontainer\devcontainer.json'
      - 'devcontainer.metadata=[{"id":"ghcr.io/devcontainers/features/common-utils:2"},{"customizations":{"vscode":{"extensions":["ms-azuretools.vscode-containers"]}},"remoteUser":"vscode"}]'

However this doesn't appear to be exactly an issue with the dev container feature and its compatibility with debian trixie(13) as such, because if you see while creating and opening the container for the first time for trixie, the vscode user is indeed created by the common-utils feature and also loaded in devcontainer.metadata correctly.
I will be checking this one further and update you once some progress made.