Workspace stuck in 'Booting environment' with no error feedback

[easonLiangWorldedtech]

Workspace stuck in "Booting environment" with no error feedback

Problem

When a workspace fails to start, the UI shows "Booting environment" indefinitely with no explanation of what's going wrong. Users have zero visibility into:

• Whether the worker image exists
• Whether the container was successfully spawned
• Whether the sandbox server started inside the worker
• Why booting is stuck / failed

The only way to diagnose the issue is to manually check Docker logs on the host machine.

Reproduction

1. Start a workspace (e.g., "Set up the Zoo-Code environment")
2. UI shows "Booting environment"
3. After some time, it transitions to "Failed to start" with only:
   • A generic error message: "There was an error starting this environment:"
   • The raw docker run command that failed
   • No explanation of why the command failed

Example Error (from logs)

Unable to find image 'roomote-worker:local' locally
docker: Error response from daemon: pull access denied for roomote-worker, repository does not exist or may require 'docker login'

Or inside a spawned worker container:

❌ Job <unknown> failed: fetch failed

What the user sees vs what's happening

Layer	Actual State	User Visibility
Worker image missing	pull access denied	❌ No — only "Booting"
Controller spawns worker	✅ Success (12.5s)	❌ No feedback
Sandbox server starts	❌ fetch failed inside container	❌ User can't see this
UI state	⏳ Stuck on "Booting environment"	✅ Visible but unhelpful

Debugging requires manual Docker inspection

To find the real cause, a user needs to run:

# Check controller logs for spawn errors
docker logs roomote-controller-1 --tail 50

# Check if worker image exists
docker images | grep roomote-worker

# List stopped worker containers
docker ps -a | grep roomote-worker

# Read worker container logs
docker logs roomote-worker-XXX

# Check sandbox server process inside worker
docker exec roomote-worker-XXX ps aux

Suggested Improvements

1. Show booting progress — Display stages: "Pulling image" → "Starting container" → "Initializing sandbox" with status for each
2. Surface errors to UI — When controller detects pull access denied, fetch failed, etc., show the actual error message in the UI instead of raw docker command output
3. Timeout + retry info — If booting takes longer than X seconds, show "Still booting... (elapsed: XXs)" with a reason if available
4. One-click diagnostics — A button that runs docker logs roomote-controller-1 --tail 50 and shows the output inline

Environment

• Roomote version: v0.12.0 (self-hosted, built from source)
• Docker images: roomote-app:local-self-host, roomote-worker:local
• Platform: Windows host with WSL / Docker Desktop

[mrubens]

@roomote-roomote can you look into this?

[roomote-roomote]

I'm on it. I started a task for this issue, and I'll keep updates here.

See task

[roomote-roomote]

Opened draft PR #544 to improve boot-failure feedback:

• Docker spawn errors now lead with the real stderr/reason (env values redacted)
• Startup UI explains common failures (missing image, daemon down, port conflict, worker timeout/fetch failed) instead of only a raw docker run
• Active boot shows elapsed “Still booting…” after 10s
• Worker readiness wait increased from 15s → 60s

#544