Fresh per task is the safer default. A new environment cannot carry credentials, files, or poisoned state from the last run. Reuse can be acceptable for speed if you wipe the workspace and credentials between tasks, keep it within one repository and one trust level, and cache only content you can rebuild and verify.
Documented examples
One hosted platform says that each session gets a fresh VM, and that after a few minutes without activity a session's VM pauses with its files saved, then the next message restores the same VM. That is reuse inside one session, not across tasks. It also caches installed dependencies so they exist at the start of each new session, and states that the cache stores files only, not running processes.
Another platform recommends ephemeral, single-use runners for self-hosted setups.
So the common pattern is a fresh machine per task, with an optional cache for installed packages.
What leftover state can hold
| Item | Risk if reused |
|---|---|
| Environment variables and tokens | Next task inherits them |
| Shell history and logs | Contain commands and sometimes secrets |
| Files from earlier tasks | May include data from another repository |
| Installed packages | A bad install persists |
| Agent memory or notes | Instructions planted earlier can steer later work |
| Git config and credentials helpers | May authorize unintended pushes |
Memory deserves its own mention. If an agent keeps notes between runs, injected text from one task can influence the next. Treat any persisted agent state like untrusted input.
Rules for a reuse policy
- Reuse only within one repository and one team.
- Wipe the workspace, home directory, temporary files, and shell history between tasks.
- Rotate or remove task credentials every time.
- Cache only dependency downloads from a lockfile, and verify them.
- Rebuild the base image on a schedule and when advisories apply.
- Never share an environment between tasks of different sensitivity.
- Set a maximum lifetime, such as a day.
Cost versus safety
Fresh environments cost start time and some compute. A cache cuts most of that without keeping task state. If start time is the complaint, solve it with a prebuilt image or cache of dependencies, not by keeping the whole machine alive.
A quick test
Run two tasks back to back in the same environment. In the second, ask the agent to list the files it can see, print its environment variable names, and show recent shell history. If anything from the first task appears, your cleanup is incomplete.
Worked example: what a reused environment can leak
An illustrative sequence in a single reused environment.
Task 1. An agent works on a repository for the billing team. It reads a test fixture containing realistic customer records, and a developer pastes a temporary token into the prompt to debug an integration. The agent writes notes to a scratch file to keep its place.
Task 2. The same environment is reused for a different team's task. The agent lists the working directory, finds the scratch file, and reads the fixture path in its notes. Shell history still shows the earlier commands. The environment variables still hold the token. A planted instruction in the earlier task's content, saved in the notes, now sits in context for the new task.
None of this required an escape or an exploit. It required reuse.
With a fresh environment per task, none of those artifacts exist for Task 2.
Cleanup checklist if you must reuse
| Area | What to remove |
|---|---|
| Workspace | All files, including hidden ones, and the git directory |
| Home directory | Shell history, editor state, tool caches that hold content |
| Temp directories | Everything |
| Environment | Unset task variables, restart the process tree |
| Credentials | Revoke task tokens, clear credential helpers |
| Network state | Close connections, flush caches that retain names or tokens |
| Agent state | Clear memory, notes, and any persisted context |
| Logs | Ship out, then clear local copies |
Verify by running the quick test from earlier: ask a fresh agent to list files, variable names, and history, and confirm nothing from the last task appears.
Speed without reuse
If the issue is start time, there are options that do not keep task state.
- Prebuilt images that include the toolchain and dependencies for a given repository.
- Dependency caches keyed to the lockfile hash, rebuilt on change.
- Warm pools of clean, unused environments waiting for assignment, discarded after one use.
- Smaller base images that start faster and expose less.
These keep the benefit of speed while preserving per-task isolation.
Lifetime and idle behavior
One platform pauses an idle session's VM and restores it on the next message. That is acceptable within a single session, but set a maximum lifetime so a paused session does not become a long lived environment. End the session when the task ends, and archive or delete the record according to your retention policy.
A rule of thumb
If you cannot name every piece of state that survives from one task to the next, assume something sensitive does. Prefer designs where the list is empty.
Where Safeguard fits
Safeguard does not manage sandbox lifecycles. Its asset discovery and agent identity features help you track which agents exist, and dependency scanning covers what cached images contain.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through it and notice how state accumulates and changes over time, which is the same drift a reused environment suffers.
Quick check
Is pausing and resuming a VM the same as reuse?
Within one session it keeps that session's state, so treat it as one trust boundary and end it when the task ends.
Can I cache the whole environment?
Cache what you can rebuild and verify, such as packages. Avoid caching credentials or task files.
Is a warm pool of clean environments the same as reuse?
No. A warm pool holds environments that have never run a task, and each is used once and discarded. Reuse means running a second task in an environment that already ran one.
Sources
- Configure cloud environments (Anthropic documentation)
- Customize the Copilot cloud agent environment (GitHub Docs)
- OWASP LLM01:2025 Prompt Injection
Last reviewed: 19 October 2026.
