Gray Screen & Repeated Lock Errors When ui_messages.json Is Missing

[alphaDev23]

App Version

Roo Code: v3.23.16 (e07de26)

API Provider

Not Applicable / Other

Model Used

N/A

Roo Code Task Links (Optional)

No response

🔁 Steps to Reproduce

Setup• VS Code 1.90.0 on Ubuntu 22.04 (remote ~/.vscode-server)• Roo Code v3.23.16 (e07de26) enabled.

Start a long‑running Roo Code task or forcibly kill the Remote Extension Host mid‑task.

Verify the task directory now contains one or more *.lock files but no ui_messages.json.

Reload VS Code or reconnect to the workspace.

Observe Roo Code’s panel turn gray and logs fill with repeated lock‑acquisition errors.

💥 Outcome Summary

🐞 Gray Screen & Stale‑Lock Error When ui_messages.json Is Missing

Expected Roo Code to detect a missing ui_messages.json and recover; instead, the UI grays out and the log spams:

[error] Failed to acquire lock for …/ui_messages.json: Error: Lock file is already being held

---

📄 Relevant Logs or Errors (Optional)

2025‑07‑20 17:57:29.533 [info] Extension host (Remote) is unresponsive.
2025‑07‑20 17:57:32.273 [info] Extension host (Remote) is responsive.
2025‑07‑20 17:57:33.527 [error] Failed to acquire lock for …/ui_messages.json: Error: Lock file is already being held

---

Manual Workaround

Detect stale locks

#!/usr/bin/env bash
TASKS_ROOT="$HOME/.vscode-server/data/User/globalStorage/rooveterinaryinc.roo-cline/tasks"

echo "[INFO] Searching for stale lock conditions…"
for dir in "$TASKS_ROOT"/*; do
  if [ -d "$dir" ]; then
    lock_count=$(find "$dir" -name '*.lock' | wc -l)
    json_exists=$(find "$dir" -name 'ui_messages.json' | wc -l)

    if [ "$lock_count" -gt 0 ] && [ "$json_exists" -eq 0 ]; then
      echo "[⚠️  WARNING] Stale lock detected in: $dir"
    fi
  fi
done

Clean up a verified stale task (use with caution)

⚠️ NOTE: Running this cleanup may delete the task and permanently remove its history in the current workspace. Proceed only if you are certain the task is no longer needed.

#!/usr/bin/env bash
TASK_DIR="$HOME/.vscode-server/data/User/globalStorage/rooveterinaryinc.roo-cline/tasks/<task-id>"

if [ -d "$TASK_DIR" ]; then
  echo "[INFO] Cleaning stale lock files in $TASK_DIR…"
  find "$TASK_DIR" -name '*.lock' -exec rm -v {} \;
  touch "$TASK_DIR/ui_messages.json" && chmod 666 "$TASK_DIR/ui_messages.json"
  echo "[INFO] Stale lock cleared."
else
  echo "[WARNING] Task directory does not exist: $TASK_DIR"
fi

Replace <task‑id> with the folder identified by the detection script.

---

Proposed Fix

1. Startup scan: On activation, Roo Code should scan each task directory for lock && !ui_messages.json.

2. Automatic recovery:

   • If the lock file timestamp is older than n minutes (e.g., 10), treat the task as abandoned and delete the lock or recreate ui_messages.json.
   • Log a single warning instead of spamming errors.

3. Preventive guard: Ensure lock‑acquisition logic first confirms the target file exists before creating/holding a lock.

📄 Relevant Logs or Errors (Optional)

[roomote]

I have created a pull request to fix this issue: #6027

The fix includes:

1. Stale lock detection on startup - Scans task directories for orphaned locks when the extension activates
2. Automatic recovery - Removes lock files older than 10 minutes when ui_messages.json is missing and creates an empty ui_messages.json file
3. Preventive guard - Updates safeWriteJson to create the target file before lock acquisition to prevent future lock issues

The implementation has been tested with comprehensive unit tests. Most CI checks are passing, though there appears to be an unrelated integration test failure that may need attention from maintainers.

[daniel-lxs]

Hey @alphaDev23 Thank you for reporting this issue.

@KJ7LNW I think forcefully killing Roo Code will always have unintended consequences but do you think we should have some additional cleanup step for orphaned locks?

[KJ7LNW]

@KJ7LNW I think forcefully killing Roo Code will always have unintended consequences but do you think we should have some additional cleanup step for orphaned locks?

it is supposed to detect stale locks. ask the model why the lock is not being detected as stale on safeWriteJson