🤖 fix: support Docker images with non-root default users

[ethanndickson]

Problem

Docker images like codercom/enterprise-base and codercom/example-base run as a non-root user by default (e.g., coder with uid 1000). Previously, DockerRuntime failed with "Permission denied" errors:

During workspace creation:

Preparing workspace directory...
Failed to create workspace directory: mkdir: cannot create directory '/src': Permission denied
mkdir: cannot create directory '/var/mux': Permission denied

During streaming (after workspace created):

Error: Failed to stream message: Failed to create temp directory /root/.mux-tmp/...: exit code 1

Root Cause

1. mkdir /src and mkdir /var/mux/plans ran as the container's default user, which doesn't have permission to create top-level directories
2. ~ was hardcoded to resolve to /root, but non-root users can't write there

Solution

• Detect container's default user (uid/gid/home) after container creation via id -u, id -g, echo $HOME
• Create workspace directories using docker exec --user root, then chown to the container user
• Resolve ~ paths using the detected home directory instead of hardcoded /root

Images That Now Work

Image	Default User	Previously	Now
codercom/enterprise-base	coder (1000)	❌ Permission denied	✅ Works
codercom/example-base	coder (1000)	❌ Permission denied	✅ Works
node:20, ubuntu, etc.	root (0)	✅ Works	✅ Works (unchanged)

Why This Is Safe (No Migration Required)

• Workspace config entries unchanged - same structure, same container name derivation
• Existing containers not modified - we don't retroactively chown or restructure existing containers
• Root-based images behave identically - uid=0 detected, home=/root, same as before
• User detection runs lazily - ensureReady() detects user info when container starts, so existing workspaces automatically get correct ~ resolution on next use

Testing

Tested with codercom/example-base:latest:

• ✅ Workspace creation succeeds
• ✅ Streaming works (temp dirs created in /home/coder/.mux-tmp/...)
• ✅ VS Code Dev Containers can attach and edit /src

---

Generated with mux • Model: anthropic:claude-opus-4-5 • Thinking: high • Cost: $3.77

[chatgpt-codex-connector]

💡 Codex Review

mux/src/node/runtime/DockerRuntime.ts

Lines 1003 to 1006 in 1d83d09

	initLogger.logStep("Cloning repository in destination...");
	const cloneResult = await runDockerCommand(
	`docker exec ${destContainerName} git clone ${containerBundlePath} ${CONTAINER_SRC_DIR}`,
	300000

Create /src before cloning for non-root images

In forkWorkspace, the destination container is only prepared for /var/mux, then git clone is executed into /src as the container’s default user. On images that default to a non-root user (the newly supported scenario), /src typically doesn’t exist and the user can’t create top-level directories, so the clone fails with Permission denied. createWorkspace now fixes this by creating /src as root and chowning it, but the fork path doesn’t mirror that, so forks of non-root images will still fail.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[ethanndickson]

@codex review

Fixed the forkWorkspace issue: now creating /src as root before git clone, matching the createWorkspace behavior.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Keep it up!

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".