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.
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.
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:
--keepkeeps the sandbox after the task. Without it, the sandbox is torn down when the task finishes and the run takes no follow-ups.-dprints 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.