According to Anthropic's documentation, a Claude Code cloud session's VM pauses with its files saved after a few minutes of inactivity, and your next message restores the same VM. After a longer inactivity period the VM is reclaimed. Reopening the session provisions a fresh VM and restores conversation history, but not background work such as running subagents or shell commands.
The lifecycle in three stages
- Active. The VM runs your session. Commands execute, files change, the agent works.
- Paused. After a few minutes without activity, the VM pauses with its files saved. The next message restores the same VM and starts Claude Code again.
- Expired. Cloud sessions stop after a period of inactivity and the VM is reclaimed. Reopening the session from the web interface provisions a fresh VM.
The documentation adds that a session counts as inactive while it waits for you to approve an MCP connector tool call or to sign in to an MCP server, and it can expire during that wait. So a session blocked on a human approval can lose its VM.
What is restored and what is not
| Item | After pause | After expiry and reopen |
|---|---|---|
| Files in the VM | Kept | A fresh VM, not the old files |
| Conversation history | Kept | Restored |
| Running shell commands | Resumed with the VM state, per restore | Not restored |
| Background subagents | Not documented for pause | Not restored |
| Scheduled loop wakeups | Not documented for pause | Not restored, rerun the loop |
| Permission mode | Kept | Session resumes in the mode it was in |
| Environment variables | Defined by the environment | Defined by the environment |
The expiry rows come directly from the documentation's list of what is and is not restored. The pause rows rely on the documented statement that files are saved and the same VM is restored.
Why this matters for security
Fresh VM means a clean slate for files. If an agent left credentials or data in files, expiry removes them with the VM. That is a useful property, but do not rely on it as your only cleanup, since a paused VM keeps files until reclaimed.
Pause keeps whatever is in the VM. If a token was written to a file during the session, it sits there while the session is idle. A shared or forgotten session is a place for that to hide.
History persists separately. Conversation history is restored even after expiry, and the documentation notes shared sessions may contain code and credentials. Anything printed into the conversation outlives the VM.
Long approvals can expire the session. If your policy requires human approval for tool calls, plan for the possibility that the VM is gone by the time someone answers. Design tasks so they can be resumed from a branch and conversation, not from in-VM state.
Setup caching has its own rule. The documentation says an environment cache stores files only, not running processes, and a setup script is cached only when it finishes in roughly five minutes. A slow setup script is rerun more often, which is a cost and a consistency issue.
A worked example: an overnight task with an approval gate
An illustrative scenario. A team starts a long refactoring task late in the day. Their policy requires approval before the agent calls an MCP connector that writes to the ticket system.
- At 6 pm the agent works and pushes a branch every hour.
- At 8 pm it reaches the connector call and waits for approval.
- Nobody answers. The session sits idle, pauses, and later expires.
- At 9 am a developer opens the session. The conversation is there. The VM is fresh. A background test run is gone.
- The developer checks the pushed branch, which holds the earlier work, and asks the agent to continue from it.
Lessons: push progress to a branch regularly, keep approvals in a window when someone is available, and do not store task state only in the VM.
Practices that follow
- Commit and push to the task branch at natural checkpoints, so expiry loses nothing important.
- Never write credentials to files in the VM. Use a network secret or proxy.
- End sessions when the work is done instead of leaving them paused.
- Archive or delete finished sessions according to your retention policy.
- Keep setup scripts under about five minutes so caching applies.
- Document the idle behavior in your runbook, so reviewers know what to expect.
- Treat the session link as sensitive for as long as the session exists.
Questions for your own vendor review
| Question | Why |
|---|---|
| How long until a paused VM is reclaimed? | Sets how long files sit |
| Are files encrypted at rest while paused? | Affects stored data risk |
| Who can restore a paused session? | Access control on state |
| What persists after deletion? | Retention |
| Are approval waits counted as inactivity? | Planning for human gates |
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how monitoring keeps checking after the first scan, which is the habit you want for long lived agent sessions and cached environments.
Where Safeguard fits
Safeguard does not manage Claude Code sessions. Its agent identity and compliance and evidence automation help you attribute and record agent activity, and dependency scanning covers what cached environments contain.
Quick check
Is a paused cloud session safe to leave overnight?
Files stay saved while it is paused, so anything sensitive in the VM stays there. Remove credentials from files and end sessions you no longer need.
Is a background test run restored after expiry?
No. The documentation says background work, such as subagents and shell commands, is not restored when a fresh VM is provisioned.
Does expiry delete the conversation?
No. Conversation history is restored on reopen. Treat anything printed in it as long lived.
Sources
- Configure cloud environments (Anthropic documentation)
- Use Claude Code in the cloud (Anthropic documentation)
Last reviewed: 19 October 2026.
