The agent finished. Who turns off the VM?

Suppose a coding agent opens a pull request at 6 p.m. The tests pass, a preview is running, and the reviewer has already logged off.

The agent's task is complete. The machine still has something to do: serve that preview until someone looks at it. Or perhaps it doesn't. Perhaps the preview can be rebuilt tomorrow and the workspace should shut down now.

Either choice is reasonable. Leaving it undecided is how a short coding task turns into a machine nobody remembers starting.

Web Dev Cody's Coder walkthrough shows agents working in remote environments, including an AWS EC2 workspace, with changes and previews available for review. The video is sponsored by Coder. It prompted a narrower question for me: what should stop when an agent finishes?

There are three separate answers: the command, the agent session, and the workspace. A limit on one doesn't automatically control the others.

A test timeout only covers the test

Here is a small guardrail for a Node.js project. It requires Bash, GNU timeout, installed dependencies, and a working npm test script. Run it from the project directory:

#!/usr/bin/env bash
set -u

if timeout --kill-after=30s 10m npm test >test.log 2>&1; then
  printf 'Tests passed. Output: test.log\n'
else
  status=$?
  printf 'Tests failed or timed out (exit %s). Output: test.log\n' \
    "$status" >&2
  exit "$status"
fi

At ten minutes, timeout sends a termination signal. If the command still hasn't exited thirty seconds later, it sends a kill signal. A timeout normally returns 124; a forced kill can return 137. Otherwise, the command's exit status is preserved. GNU documentation

Now imagine the agent reads the failure, changes something, and runs the tests again. Each attempt has a limit. The task as a whole can still continue indefinitely.

That needs a separate deadline or retry budget, enforced by whatever launches and supervises the agent. Putting a timeout inside a script the agent can rewrite is useful for ordinary failures, but it isn't a reliable boundary for the agent itself.

An active workspace may never become idle

An inactivity timer sounds like an answer to the overnight-machine problem. Its usefulness depends on what counts as activity.

Coder's scheduling documentation says that a working agent can extend the workspace's shutdown deadline. This prevents a legitimate task from being interrupted. It also means that an agent stuck doing work may keep its environment alive.

For the hypothetical 6 p.m. pull request, my policy would be: end the agent session when it hands over the result, save the review evidence, and retain the preview only until an explicit expiry time. A longer review window should be a deliberate extension.

The supervisor should also handle the less tidy cases: the agent crashes, loses its connection, or keeps retrying without producing a result. A deadline that depends on the agent successfully reporting completion won't cover those failures.

This is a policy to implement and test, not a claim that every agent platform provides the same controls.

Keep the evidence before removing the workspace

Shutdown is awkward when the only copy of a change or its test output lives on the machine being stopped.

For a task using a Git worktree, the setup might look like this. Run it from an existing checkout, with a new branch name and an unused destination:

task_id="issue-142"
task_dir="../agent-${task_id}"

git worktree add -b "agent/${task_id}" "$task_dir" HEAD

This starts from committed HEAD; it doesn't copy uncommitted edits. A worktree separates working files while sharing repository data. It doesn't isolate credentials, processes, or cloud resources. Git documentation

Before cleanup, preserve the commit remotely and attach the test result to the pull request. Include the command that ran and any failures. If a reviewer needs the preview, record which commit it serves and when it expires.

After review, inspect the worktree from the original checkout. Only remove it once its work and useful logs are preserved:

git -C ../agent-issue-142 status --short

# Run only after checking the status and preserving the work.
git worktree remove ../agent-issue-142

Without --force, Git refuses removal if uncommitted changes or untracked files remain. That includes the test.log from our earlier example. A clean status doesn't prove the commits were pushed, so check that separately.

Removing the worktree leaves the branch and cloud resources in place. Even stopping an EC2 instance is different from terminating it. The infrastructure needs its own cleanup step and retention rules. EC2 documentation

Try one failed task before running ten agents

Before expanding this setup, deliberately run a task that cannot finish. Let its deadline expire. Then check whether the agent stopped, whether the logs survived, and which resources remain active.

Repeat with a successful task whose reviewer is unavailable until the next day. The preview should remain available for the promised window without requiring the agent to keep working.

Those two cases would tell me more about readiness than another successful demo. I want to be able to close the laptop knowing what will still be running tomorrow—and why.