Learn

Hand off from the terminal

Start a long run from your terminal, close the laptop, and pick it back up later to read what happened, steer it, park it and wake it.

View .md

A run works in its own sandbox in Rush Cloud, not on your machine, so it does not need your terminal to stay open. In this lesson you start a long task with rush, walk away, and come back to it: read what it did, send it the next instruction, park its sandbox and wake it again. You need the CLI installed and signed in; The CLI in two minutes covers both.

08Kept 7 days after it last parks

YouRush APISandboxPOST /o/{org}/sessionsallocateeventstool_usetool_resultthinkingdone$0 parked…/messageswakedone7 days, thenexpiredstatuspausedcompute$0 while parkedturn 2
Scene. One session across two turns: who sends what, what the sandbox does, and when compute is billed.

Start it and leave

1. Start a run you can come back to

rush run claude -r acme/web --keep -d "Upgrade the app to the new router, fix what breaks, and open a PR"

Two flags matter here:

  • --keep keeps the sandbox after the task. Without it, the sandbox is torn down when the task finishes and the run takes no follow-ups.
  • -d prints the run id and returns at once, instead of following the run in your terminal.

Note the id it prints; the commands below take it. Leave it out in a terminal and each one offers a picker instead.

2. Close the laptop

Nothing on your machine is part of the run. Close the terminal, lose the network, shut the lid. The agent keeps working, and the run's page in the console shows the same live transcript to anyone in your org.

Pick it back up

3. See where it is

rush runs --status running

rush runs lists your runs with their status. A run that is waiting on you shows input_required; one whose turn ended shows completed, needs_review or paused.

4. Read what happened

rush logs <run>

rush logs follows a running run live, the same view rush run gives without -d. To read only what changed since you last looked, add --new; it prints the new output and exits. For the whole record afterwards, rush transcript <run> --summary prints a compact list of turns and tool calls.

Steer it

5. Send the next instruction

rush send <run> "Keep the old routes working behind a redirect, and add a test for each."

If the turn has ended, the message starts the next one in the same sandbox, with the same files and branch. If the agent is still mid-turn, a text-only message queues: rush prints Message queued with its position, and the agent gets it when the turn ends. A run holds up to 20 queued messages.

To deliver it sooner, stop the current turn without ending the run:

rush stop <run> --turn

6. Look inside when you need to

rush attach <run>

rush attach opens an interactive shell in the run's sandbox, for checking a log file or running a command yourself.

Park it and wake it

7. Pause the sandbox

rush pause <run>

The sandbox parks with its disk and its memory, including running processes, and costs nothing while parked. rush pause prints an operation id and waits until the pause succeeds; --no-wait returns at once. A sandbox also parks by itself when a turn ends and it sits idle.

8. Resume it

rush resume <run>

The sandbox wakes where it left off. A rush send wakes a parked sandbox too, so you rarely need resume before a follow-up.

9. Mind the 7 days

A parked sandbox is kept for 7 days after it last parked. Each time it parks, the clock starts again, so a run you keep using never expires. After 7 idle days the sandbox is removed and the run ends expired; its record and transcript stay readable, but it cannot be resumed.

Finish

10. Open the pull request

rush open <run> pr

This opens the pull request the run produced; rush open <run> opens its console page instead. rush artifacts <run> --get downloads any files it saved.

Next

Runs and sessions explains statuses and parked sandboxes, and Steer a run as a team shows how teammates follow the same run from the console.