Commands run as root instead of vscode in Dev Container

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Agent spawned commands run as user root. whoami says the terminal runs as root.

Steps to Reproduce

Open up Cursor in a DevContainer. I’m using mcr.microsoft.com/devcontainers/base:ubuntu-24.04 with some additions (custom certificates, preinstalled java & maven)

Expected Behavior

whoami should say vscode

Operating System

MacOS

Version Information

Version: 3.2.16 (Universal)
VSCode Version: 1.105.1
Commit: 3e548838cf824b70851dd3ef27d0c6aae371b3f0
Date: 2026-04-28T21:07:47.682Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.4.0

For AI issues: which model did you use?

composer-2

Additional Information

I’ve noticed something recently and I’m trying to understand whether this is expected behavior or a misconfiguration on my side.

Setup:
I’m using Cursor inside a Dev Container based on the official Ubuntu image, with a custom image that includes Java and Maven preinstalled.

It looks like terminal commands executed via Cursor are running as the root user instead of the expected vscode user.

This becomes particularly noticeable when working with Maven, as it then assumes different locations for configuration and repositories (e.g. using /root/.m2 instead of /home/vscode/.m2), which leads to incorrect behavior in my setup.

To validate this, I ran whoami:

When executed by the Cursor agent, it returns root
When executed manually in the Dev Container terminal, it correctly returns vscode

Another odd detail: when the agent executed whoami, it took around 3 minutes to complete, which seems unexpectedly slow for such a simple command.

Does this stop you from using Cursor

Yes - Cursor is unusable

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.

8

Hi @mohitjain,

thank you a lot for the detailed explanation and the helpful suggestions!

1. whoami timing
I ran a few more tests using time whoami. The reported execution time is negligible, but the actual wall-clock time is still extremely high.

Here’s what the output looks like:

time whoami
e]633;Caroot

real    0m0.000s
user    0m0.000s
sys     0m0.000s

Even though time reports ~0 seconds, the command still takes well over 100 seconds to complete in reality. I repeated this three times with consistent results.

So it seems like the delay is happening outside of what time is measuring, which makes this quite confusing.

What would be a sensible next step to further investigate or evaluate this unexpectedly long execution time?

2. Maven / permissions
Disabling the sandbox (even in a Dev Container) isn’t really an option for us, since we want to keep the stricter execution model.

Is there a way to configure Cursor so that certain commands (e.g. Maven) are always executed with elevated permissions (such as permissions_all) automatically?

As a temporary workaround, I’m currently using a rule that enforces required_permissions: ["all"] for mvn commands, which works, but feels more like a workaround than a proper solution.

Thanks again for your help!

9

I did a bit more experimentation and found an interesting correlation.

I created a fresh, empty project inside the Dev Container and ran whoami — execution was immediate. Then I gradually added more and more files to the project.

What I observed is that the execution time of whoami seems to increase with the number of files in the repository. The more files present in the workspace, the longer the command takes to complete.

Based on my observations so far, this seems to be related purely to the total number of files, and not to how many of them are excluded via .cursorignore. That was my initial assumption, but it doesn’t seem to have an impact on the behavior.

This suggests that the slowdown might somehow be related to the size or structure of the project/workspace rather than the command itself.

11

Thanks for the thorough follow-up. Both the time whoami result and the file count correlation are really useful.

On the timing: The delay is happening in the sandbox setup that runs before and after each command, not in the command itself. That’s why time reports 0 seconds. The sandbox scans the workspace to set up file protections for every command, and that currently scales with the total number of files. This is a known performance limitation that our engineering team is aware of, and it’s being tracked internally.

Your finding that .cursorignore doesn’t help is consistent with how the scan works. The file discovery phase bypasses ignore files, so adding entries to .cursorignore won’t reduce the scan time.

On Maven permissions: There isn’t a built-in per-command elevated permissions mechanism beyond what you’re doing. Your rule-based approach with required_permissions: ["all"] for mvn commands is the best available option right now.

Reducing the delay: Since the delay scales with file count, reducing the number of files visible in the workspace can help significantly:

  • If your project generates build artifacts (target/, compiled .class files, downloaded .jar dependencies), keeping those in a directory outside the workspace root would reduce the file count the sandbox processes.

  • Alternatively, if possible, open Cursor in a narrower workspace root (e.g., the specific module you’re working on rather than the entire monorepo).

We appreciate you digging into this and isolating the file count correlation — it’s a clear data point that helps prioritize this.