From b02ebaafdd4551df4a0df350eac63191df4875eb Mon Sep 17 00:00:00 2001 From: hongyi-chen Date: Fri, 9 Oct 2026 17:09:57 +0000 Subject: [PATCH 1/2] docs: Explain environment setup command timeouts Co-Authored-By: Warp --- .../environments/troubleshooting-environments.mdx | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/content/docs/platform/environments/troubleshooting-environments.mdx b/src/content/docs/platform/environments/troubleshooting-environments.mdx index fcf6e5f27..cb7c9336e 100644 --- a/src/content/docs/platform/environments/troubleshooting-environments.mdx +++ b/src/content/docs/platform/environments/troubleshooting-environments.mdx @@ -13,6 +13,14 @@ Setup commands run in a new container on every cloud agent run. Commands that de 2. Use lockfile-based dependency commands such as `npm ci` when your project supports them. 3. Run the complete setup from a clean container before updating the environment. +## "Setup command #N timed out" + +A setup command that runs longer than 30 minutes fails environment setup. The error identifies the command number, command text, elapsed limit, and phase. If the phase is "resetting the working directory after the command", the timeout is 30 seconds instead. + +1. Inspect the named command and its output in the run's transcript. Check for an interactive prompt, a long-running server, or a stalled download. +2. Make the command finish without user input. For example, use `sudo apt-get install -y` for package installation, and don't start a foreground development server during setup. +3. Move lengthy dependency installation into your Docker image when possible, then test the revised setup from a fresh container and start a new run. + ## `Permission denied` or `EACCES` Cloud agents run as a non-root user by default. A command fails when it needs root access or writes to a directory that the agent user cannot modify. From bd161195d67e2c5a7da917c02c7ac3641b8f89ad Mon Sep 17 00:00:00 2001 From: hongyi-chen Date: Fri, 9 Oct 2026 17:09:57 +0000 Subject: [PATCH 2/2] docs: Clarify blocked unattended harness runs Co-Authored-By: Warp --- src/content/docs/platform/managing-cloud-agents.mdx | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/content/docs/platform/managing-cloud-agents.mdx b/src/content/docs/platform/managing-cloud-agents.mdx index 1cade7354..cf3ae4e09 100644 --- a/src/content/docs/platform/managing-cloud-agents.mdx +++ b/src/content/docs/platform/managing-cloud-agents.mdx @@ -93,7 +93,9 @@ Where the agent was launched from. Common sources include: Warp uses a small set of statuses to help you quickly identify what needs attention: -
StatusIconDescription
WorkingN/Ain progress (may include queued / running states)
Blocked🟨

(interactive only)


the conversation is waiting on user input or a required step

Canceled⬜️(interactive only)

the interactive conversation was canceled before completion
Failed / Errored🔺something went wrong (applies to both interactive and cloud agent runs)
Success✅completed successfully (applies to both interactive and cloud agent runs)
+
StatusIconDescription
WorkingN/Ain progress (may include queued / running states)
Blocked🟨waiting on user input or a required step; an unattended third-party harness run can end in this state
Canceled⬜️(interactive only)

the interactive conversation was canceled before completion
Failed / Errored🔺something went wrong (applies to both interactive and cloud agent runs)
Success✅completed successfully (applies to both interactive and cloud agent runs)
+ +When an unattended [third-party harness](/platform/harnesses/) reports that it needs user input, the run ends as **Blocked** instead of waiting indefinitely. Inspect the status message and transcript to identify the missing input, then include that information in the prompt before starting another run. **Duration (for cloud agent tasks)**