Postmortem: Desk sandbox failures and stuck conversations

We investigated reports of file and command tools returning “Sandbox is unavailable” and conversations repeatedly showing “An agent is already running on this thread.”

Affected users could not complete tasks requiring computer access. Some conversations also rejected follow-up messages.

The sandbox failure came from how we handled Desk startup. Installing the Desk’s preset Node or Python dependencies was treated as a requirement for making the entire computer available. When installation timed out or failed, that error blocked shell and file tools—even though production logs showed the computer had started and remained reachable.

Our logs did not preserve the installer’s diagnostic output, so we cannot determine the underlying reason it exited with status 1.

We also found a recovery gap in conversation admission. A Redis marker records that a thread has an active agent. If cleanup failed, that marker could continue blocking messages after the queue job had ended. The frontend then displayed the rejection as an assistant reply instead of recovering the conversation.

We have merged fixes that:

• Keep computer tools available when preset dependency installation fails.
• Bound installation timeouts and preserve useful failure diagnostics.
• Clear stale busy markers when the queue confirms a job completed or failed, while protecting active jobs and retries.
• Restore rejected messages to the composer and reconnect the frontend to the active task.

Both fixes passed their automated checks before merging. Production recovery has not yet been verified.

We’re sorry for the interruption and the misleading error messages.

The sandbox and agent is having issues.