# 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](/docs/start/cli) covers both. _Figure: persistence, on the page at /docs/learn/hand-off-from-the-terminal._ ## Start it and leave ### 1. Start a run you can come back to ```bash 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 ```bash 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 ```bash rush logs ``` `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 --summary` prints a compact list of turns and tool calls. ## Steer it ### 5. Send the next instruction ```bash rush send "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: ```bash rush stop --turn ``` ### 6. Look inside when you need to ```bash rush attach ``` `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 ```bash rush pause ``` 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 ```bash rush resume ``` 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 ```bash rush open pr ``` This opens the pull request the run produced; `rush open ` opens its console page instead. `rush artifacts --get` downloads any files it saved. ## Next [Runs and sessions](/docs/concepts/runs-and-sessions) explains statuses and parked sandboxes, and [Steer a run as a team](/docs/learn/steer-a-run-as-a-team) shows how teammates follow the same run from the console.