Commands run as root instead of vscode in Dev Container

Support Bug Reports
, , ,
6

Following up on your earlier sandbox thread where you got sandbox mode working in your DevContainer.

The root user behavior you’re seeing is expected when sandbox mode is active on Linux. The sandbox uses a Linux user namespace where the process appears as root (UID 0) inside the namespace, but file operations still map back to the real user’s UID on the host. This is standard Linux user namespace behavior, and it means tools that derive paths from the current user identity (like Maven using /root/.m2) will use root’s paths rather than /home/vscode/.m2.

A couple of options depending on your priorities:

  1. Disable sandbox for this DevContainer and use the Command Allowlist instead (Cursor Settings > Agents > Auto-run). This preserves the vscode user identity while still giving you control over which commands auto-run. Given your security evaluation, you may find the allowlist approach gives you comparable control without the UID side effects.

  2. Set HOME explicitly in your DevContainer environment to override the path derivation. In your devcontainer.json, you could add:

"containerEnv": {
"HOME": "/home/vscode"
}

This should cause Maven (and other tools that respect $HOME) to use /home/vscode/.m2 even inside the sandbox. Note that some Java tools derive paths from the system user database rather than $HOME, so this may not work for all tools.

  1. Set Maven’s user home directly via environment variable:

"containerEnv": {
"MAVEN_USER_HOME": "/home/vscode/.m2"
}

Regarding the 3-minute delay for whoami, that’s not expected and is worth investigating separately. Could you try running time whoami from the agent terminal a few times and share the output? Also, does your DevContainer image include any corporate identity services (LDAP, SSSD, or custom NSS modules)? The sandbox’s namespace isolation can cause timeouts if the container tries to resolve user identity via network services.