[Fix] Workspace stuck in Booting environment with no failure reason

[roomote-roomote]

Opened on behalf of Matt Rubens. View the task or mention @roomote-roomote for follow-up asks.

Related issue

Fixes #538

Why this PR exists

• A maintainer explicitly invited this PR in the linked issue or discussion
• I am a maintainer / this is internal Roomote work

What changed

Failed environment boots no longer leave users staring at Booting environment and then a raw docker run command.

• Docker spawn failures now lead with the real stderr/stdout reason (with env values redacted in the command trailer).
• Startup UI maps common self-host failures (missing worker image, Docker daemon down, port conflicts, worker start timeout, worker fetch failed) to clear guidance while keeping details when useful.
• Active boot shows Still booting… (elapsed) after 10s.
• Docker worker readiness wait increased from 15s to 60s with clearer timeout/log messages.

How it was tested

• Vitest: @roomote/web task-run-errors + StartupMessage; @roomote/controller docker-sandbox-security + BaseController
• tsc for web and controller
• Pre-push suite (oxlint, residual eslint, check-types:fast, knip)
• Product screenshot of failed startup with friendly Docker image copy

Screenshots

Checklist

• The PR title follows the repo convention: [Fix], [Feat], [Improve], [Refactor], [Docs], or [Chore] followed by a user-facing description
• This PR is small and scoped to one change
• pnpm lint and pnpm check-types pass locally
• I added tests or included a clear manual validation note above
• I removed secrets, tokens, private keys, and customer data from code, logs, and screenshots
• If this change should appear in the changelog, I ran pnpm changeset

Linked work items

Closes #538

[roomote-roomote]

1 issue outstanding. See task

• apps/controller/src/compute-providers/docker-sandbox-security.ts:155-159: reason falls back to the raw execFile error.message without redaction. For a docker exec failure with no stdout/stderr, Node includes the full command there; the worker launch command contains -e AUTH_TOKEN=<run token>, so this stores and displays the token in the task failure. Sanitize that fallback or use the sanitized argv before persisting it.

_{Reviewed 9d3cff7}

[easonLiangWorldedtech]

@roomote-roomote @mrubens Hi! I've been testing this on my self-hosted setup and can confirm it resolves the issue.

Test Results

Environment:

• Version: v0.12.0 (self-host, commit 3e28c5d9)
• Image: roomote-app:local-self-host
• Setup: Docker Compose from source at /tmp/roomote-setup-latest

Before Fix (v0.12.0)

Workspace got stuck in "Booting environment" with no useful error feedback. Screenshot shows the raw failure without explanation.

After Fix (PR #544)

The fix works! The improved error handling now:

• Shows real stderr/stdout reason for Docker spawn failures ✅
• Maps common self-host failures to clear guidance ✅
• Shows "Still booting… (elapsed)" after 10s ✅
• Increased worker readiness wait from 15s to 60s ✅

Additional Finding: CRLF Issue on Windows/MSYS

While testing, I also discovered that several .sh files in the repo have CRLF line endings which cause Docker build failures on Windows:

/sandbox/install-worker.sh: line 2: $'\r': command not found

Files affected (copied into Docker image):

• .docker/run-with-dotenvx.sh
• .docker/app/entrypoint.sh
• .docker/sandbox/install-worker.sh
• .docker/sandbox/install-browser-agent.sh
• scripts/build-worker-release.sh
• apps/preview-proxy/entrypoint.sh

Fix: find . -name '*.sh' -exec sed -i 's/\r$//' {} \; before Docker build.

Summary

✅ PR #544 fix confirmed working for the "Booting environment" stuck issue
⚠️ Separate CRLF issue exists for Windows/MSYS environments (not related to this PR)

Thanks for the quick fix! 🎯

[roomote-roomote]

I saw the mention, but I need your GitHub account linked to Roomote before issue and PR comments can start work here. Link it from Settings -> Linked Accounts and then mention me again.