main.js · part 222

60 text occurrences from desktop/Cursor.app/Contents/Resources/app/extensions/cursor-agent-host/dist/main.js, part 222. Every entry preserves the shipped literal and its saved verdict or selection reason.

File contents and all parts · All files

Replaced environment successfully.

Setup logs:
${t}

Replaced environment successfully.

Failed to replace environment: ${r}

Setup logs:
${t}

Failed to replace environment: ${r}

Failed to replace environment: unknown error

Unknown replace env error

Object expected.

Symbol.asyncDispose is not defined.

Symbol.dispose is not defined.

Object not disposable.

An error was suppressed during disposal.

The update script that will be run on VM startup (after pulling the latest changes from the repository) before every cloud agent session to keep the development environment up to date. This is a command string, NOT a bash script file. Treat this as reliability-critical infrastructure: if this script breaks, future cloud agent pods may fail to start. Keep it super minimal and low-risk. For many simple codebases, the update script will simply be something like `npm install`, `pip install -r requirements.txt`, `uv sync`, etc. For more complex cases requiring multiple steps, use a multiline script with each command on its own line (do NOT use && to chain commands - use newlines instead). This should not include system dependencies that aren't part of the codebase, and it should NOT include service startup logic, migrations, test commands, build commands, or other brittle steps. Examples that MUST NOT be in the update script include `docker compose up`, `docker-compose up`, `pnpm dev`, `npm run dev`, and `python manage.py runserver`. Avoid shell-profile edits and ad-hoc environment-variable setup in the update script (for example `echo ... >> ~/.bashrc`, `source ~/.bashrc`, or `export FOO=bar`). If persistent shell customization is truly required, do it once during setup outside the update script (for example in the agent's `~/.bashrc`) and document it in AGENTS.md. If unsure, prefer fewer commands. Treat this as the "automatic startup layer" only; AGENTS.md is the place for durable human/agent operating guidance. The update script MUST be idempotent. It MUST also be robust when users do not merge your previous code changes. Do not assume files introduced only in your unmerged PR will exist on future runs (for example a newly added `package.json`); choose commands that are valid for the repository's current state or guard file-dependent commands accordingly. It will be executed from the /workspace directory (the root of the repository), so you should not need to specify the full path to the commands. Example multiline format:
npm install
pnpm run build:deps
pip install -r requirements.txt

Optional inline Dockerfile contents used to build the environment's base image. When provided, the environment is built from this Dockerfile (mapped to environment.json `build.dockerfileContents`) and the update script runs on top of it. Leave unset to use the default base image.

Suggest the update script to run on VM startup (after pulling the latest changes from the repository) before every cloud agent session to refresh dependencies for the user's project. Treat this as reliability-critical infrastructure: if this script breaks, future cloud agent pods may fail to start. Keep it super minimal and low-risk. For many simple codebases, the update script will simply be something like `npm install`, `pip install -r requirements.txt`, or `uv sync`. For more complex cases requiring multiple steps, provide a multiline script with each command on its own line (do NOT use && to chain commands - use newlines instead). The script should NOT include system dependencies that aren't part of the codebase, service startup logic, migrations, test commands, build commands, or other brittle steps (examples that MUST NOT be in the update script: `docker compose up`, `pnpm dev`, `npm run dev`, `python manage.py runserver`). Avoid shell-profile edits and ad-hoc environment-variable setup; put durable human/agent operating guidance in AGENTS.md instead. The update script MUST be idempotent and MUST be robust when users do not merge your previous code changes (do not assume files introduced only in an unmerged PR will exist on future runs). If unsure, prefer fewer commands. The user will be prompted to approve, edit, or reject this script before it is executed.

${i} Optionally, supply inline Dockerfile contents to build the environment's base image from a custom Dockerfile before the update script runs.

Environment setup commands suggested successfully. The user will review them.

Object expected.

Symbol.asyncDispose is not defined.

Symbol.dispose is not defined.

Object not disposable.

An error was suppressed during disposal.

You should NOT wait for subagents to complete. End your turn instead; completions are queued, or do parallel work.

timed out

aborted by the user

no running background subagent found

no background subagent found for id

Permission denied reading ${r}

Read rejected for ${r}

Invalid file: ${r}

Read failed for ${r}

Unknown read result for ${r}

Unhandled read result case: ${e}

shell or subagent

task id

shell id

When waiting further, avoid round 5-minute waits: prefer slices of 60–270s (keeps prompt cache warm) or 1200s+ (one cache miss buys a long wait).

When waiting further, avoid round 1-minute waits: prefer slices of up to ${t-30}s (keeps prompt cache warm) or ${4*t}s+ (one cache miss buys a long wait).

When waiting further, avoid round ${r}-minute waits: prefer slices of 60–${t-30}s (keeps prompt cache warm) or ${4*t}s+ (one cache miss buys a long wait).

When waiting further, avoid waiting ${function(e){const t=e/60;return Number.isInteger(t)?`${t}`:t.toFixed(1)}(r)}h or more: prefer slices of 60s-${r-1}m (keeps prompt cache warm). Size slices based on expected progress; when progress is unclear, exponential backoff is useful.

When waiting further, size slices based on expected progress. When progress is unclear, exponential backoff is useful.

Check or poll a backgrounded ${i} job. For work that does not have a ${a}, you can omit the ${c} arg to sleep for the full `block_until_ms` duration (prefer this over sleeping in the shell, because it renders nicely to the user). At the end of your turn, you will be notified about any unawaited jobs that completed. If you think a job completed (e.g. because you killed it), observe it with ${n} to skip the notification, because stale notifications can confuse the user.${r?`\n\nPrefer NOT to poll reflexively with ${n}. Multitask on independent work while backgrounded jobs run, or finish your turn and rely on the end-of-turn completion notification. Poll with ${n} only when one of the following is true:\n- Your very next step is blocked on this specific job's result and you have no other productive work to do${t?" (shell jobs only — never wait on a subagent)":""}, OR\n- The task requires close monitoring (see shell guidance below).${t?" Subagents are never a candidate for close monitoring.":""}`:`\n\nPrefer NOT to poll reflexively with ${n}. Multitask on independent work while backgrounded jobs run, or finish your turn and rely on the end-of-turn completion notification.`}
- Never poll a task whose tool result says it was "manually backgrounded by the user".${void 0===s||t?"":`\n- NEVER USE THIS TO POLL OR WAIT VACUOUSLY FOR A SUBAGENT LAUNCHED WITH THE ${s} TOOL — rely on the end-of-turn completion notification instead (it is delivered as soon as the subagent finishes; guessing a wait time is inefficient).`}${t?`\n- Subagents: never wait on a subagent with ${n}. Subagents are always notify-on-completion — multitask on independent work (or respond to the user if there is nothing else productive to do) and wait to be woken up. The only valid use of ${n} on a subagent is a non-blocking status check (\`block_until_ms: 0\`); never use it to block on the subagent finishing.`:""}${r?`\n- Shell: only poll with ${n} when the command requires close monitoring. Close monitoring means a long-running job that can silently hang, degrade, or need a course correction before it completes — e.g. training runs, eval runs, deployments, long builds, datagen pipelines, DB migrations, large data transfers. For fire-and-forget commands (tests, installs, dev servers/watchers, short scripts, etc.) the completion notification is enough — start them, keep working, and only poll with ${n} later if you end up blocked on the result.\n- Shell sanity check (regardless of close monitoring): when you spawn a command directly into the background (\`block_until_ms: 0\`), do a single status check by reading the output file to confirm the command didn't fail to start. This is a one-shot smoke check, not a polling loop.\n- Shell close-monitoring guidance (only applies in the close-monitoring case above):\n  - HARD STOPPING CONSTRAINT: once you've decided to actively poll, don't stop until (a) the job terminates, (b) the command reaches a healthy steady state (only for non-terminating commands, e.g. dev server/watcher), or (c) the command is hung — follow the hang guidance below.\n  - Waiting until a regex matches the output can be useful for e.g. known startup/status/error logs.\n  - Size \`block_until_ms\` to the command's expected runtime. ${u}\n  - Output file header has \`pid\` and \`running_for_ms\` (updated every 5000ms).\n  - When finished, footer with \`exit_code\` and \`elapsed_ms\` appears (regex only matches the body, not header/footer).\n  - If the command is taking longer than expected and appears hung (use judgment based on command type), kill the process if safe to do so using the pid in the header. If possible, fix the hang and proceed.`:""}

Prefer NOT to poll reflexively with ${n}. Multitask on independent work while backgrounded jobs run, or finish your turn and rely on the end-of-turn completion notification. Poll with ${n} only when one of the following is true:
- Your very next step is blocked on this specific job's result and you have no other productive work to do${t?" (shell jobs only — never wait on a subagent)":""}, OR
- The task requires close monitoring (see shell guidance below).${t?" Subagents are never a candidate for close monitoring.":""}

 (shell jobs only — never wait on a subagent)

 Subagents are never a candidate for close monitoring.

Prefer NOT to poll reflexively with ${n}. Multitask on independent work while backgrounded jobs run, or finish your turn and rely on the end-of-turn completion notification.

- NEVER USE THIS TO POLL OR WAIT VACUOUSLY FOR A SUBAGENT LAUNCHED WITH THE ${s} TOOL — rely on the end-of-turn completion notification instead (it is delivered as soon as the subagent finishes; guessing a wait time is inefficient).

- Subagents: never wait on a subagent with ${n}. Subagents are always notify-on-completion — multitask on independent work (or respond to the user if there is nothing else productive to do) and wait to be woken up. The only valid use of ${n} on a subagent is a non-blocking status check (`block_until_ms: 0`); never use it to block on the subagent finishing.

- Shell: only poll with ${n} when the command requires close monitoring. Close monitoring means a long-running job that can silently hang, degrade, or need a course correction before it completes — e.g. training runs, eval runs, deployments, long builds, datagen pipelines, DB migrations, large data transfers. For fire-and-forget commands (tests, installs, dev servers/watchers, short scripts, etc.) the completion notification is enough — start them, keep working, and only poll with ${n} later if you end up blocked on the result.
- Shell sanity check (regardless of close monitoring): when you spawn a command directly into the background (`block_until_ms: 0`), do a single status check by reading the output file to confirm the command didn't fail to start. This is a one-shot smoke check, not a polling loop.
- Shell close-monitoring guidance (only applies in the close-monitoring case above):
  - HARD STOPPING CONSTRAINT: once you've decided to actively poll, don't stop until (a) the job terminates, (b) the command reaches a healthy steady state (only for non-terminating commands, e.g. dev server/watcher), or (c) the command is hung — follow the hang guidance below.
  - Waiting until a regex matches the output can be useful for e.g. known startup/status/error logs.
  - Size `block_until_ms` to the command's expected runtime. ${u}
  - Output file header has `pid` and `running_for_ms` (updated every 5000ms).
  - When finished, footer with `exit_code` and `elapsed_ms` appears (regex only matches the body, not header/footer).
  - If the command is taking longer than expected and appears hung (use judgment based on command type), kill the process if safe to do so using the pid in the header. If possible, fix the hang and proceed.

Max sleep time to block before returning (in milliseconds). Required. Set to 0 for non-blocking status check. Must not exceed 7140000 (${i} minutes).

Max sleep time to block before returning (in milliseconds). Defaults to ${r}ms. Set to 0 for non-blocking status check. Must not exceed 7140000 (${i} minutes).

block_until_ms must be at most 7140000 (${i} minutes)

Optional shell id to poll. If omitted, this tool sleeps for the full block_until_ms duration and then returns. Required when block_until_ms is 0.

Optional shell or subagent id to poll. If omitted, this tool sleeps for the full block_until_ms duration and then returns. Required when block_until_ms is 0.

Optional shell id to poll. If omitted, this tool sleeps for the full block_until_ms duration and then returns. Required when block_until_ms is 0.

Block until the regex matches stdout/stderr stream (or task completes). Matches anywhere in the shell output, not just new output. Will not match terminal file headers or footers, e.g. exit_code. Accepts JavaScript regex patterns (compiled with the multiline `m` flag). Not supported for awaiting subagents: you MUST leave this argument unset.

Block until the regex matches stdout/stderr stream (or task completes). Matches anywhere in the shell output, not just new output. Will not match terminal file headers or footers, e.g. exit_code. Accepts JavaScript regex patterns (compiled with the multiline `m` flag).

Set this to true if you are waiting for subagent(s) to complete. Remember you should NOT be doing this and instead end your turn or do parallel work.

path must be a path to a terminal file

path must be a path to a terminal file

Use to sleep and check shell progress. Never sleep using shell.