Before leaving a coding agent running overnight
Define the task, limit access, review what can execute and prepare a recoverable checkpoint before leaving an AI coding agent working unattended.
- Kind
- Perspective, a working note
- Published
- Filed under
- Agent security
Before leaving a coding agent working overnight, give it one bounded task, access only to what that task needs, and a clear reason to stop. Plan to review a tested change in the morning. Keep production deployment under separate approval.
These are my recommendations for preparing unattended work, informed by the sources below. They do not certify a particular agent or environment as safe.
Define the task and its limits
Write down the intended result, allowed files, checks to run and time or spending limit. For example: repair a specific failing test and explain the change. Require the agent to pause if it needs unrelated files or broader permissions.
A separate branch or checkout makes edits easier to review and undo. It does not restrict what a process can access. Use an execution environment whose actual file and network permissions match the task.
Separate development access from production access
Keep production credentials and unrelated personal files out of the agent’s environment. Provide only the credentials needed for the assigned work. Avoid placing secrets in prompts or logs.
For GitHub Actions, restrict token permissions and require review before a deployment job receives protected environment secrets. GitHub also warns that log redaction is not guaranteed and that privileged workflows must not execute untrusted pull-request code. Review workflow changes as carefully as application changes. See GitHub’s secure-use guidance.
Review what an installation can execute
Check added packages, their sources, install hooks and changes to build or test commands before an unattended run. A dependency or workflow update can change what executes even when the visible application change is small.
For npm projects, npm ci uses an existing lockfile and fails when it disagrees with package.json. It also removes an existing node_modules directory. Use it in the prepared workspace. A lockfile improves reproducibility; it does not establish that a dependency is safe.
Do not add --ignore-scripts blindly. Suppressing installation scripts can leave required setup incomplete, so check compatibility and run the project’s checks. Explicit commands such as npm test still execute their requested script with that option. Read the npm ci documentation for version 11.
Prepare recovery and stopping conditions
Save a known working revision and check that you can restore the files or data the task may change. Keep test results tied to the exact revision tested. In the morning, inspect the changes, failures and unresolved questions before merging or deploying.
Require a stop for unexpected credential requests, access outside the task, unexplained network destinations, or unrelated attempts to create startup tasks or background services. A local approval queue such as BigBoss can hold shell commands and file changes for one human reviewer and tie each decision to a hash of the proposed action, workspace and policy version, while the operator still provides host isolation. Investigate before granting more access. Preserve useful logs without copying secrets into the report.
| Control Layer | What It Catches | What Still Requires a Human |
|---|---|---|
| Task and scope definition | Unbounded edits, unclear stopping conditions, and runaway spend | Choosing the right objective and verifying the final change |
| Environment and credential separation | Accidental production writes and exposure of unrelated local secrets | Provisioning least-privilege tokens and host or OS-user isolation |
Dependency and workflow review (npm ci) |
Lockfile drift (package.json vs lockfile) and unreviewed workflow edits |
Inspecting new packages, install scripts, and untrusted pull-request code |
| Action-hash approval gate (BigBoss) | Unapproved shell commands or file changes when an adapter enforces the hash | Reviewing the proposed action and isolating the agent from the approval API |
| Tested checkpoint and recovery path | Unrecoverable working-tree corruption after a failed overnight run | Inspecting test results and approving any production deployment |
What the self-replication research establishes
On October 12, 2026, Anthropic researchers William Zhou and Daniel Freeman reported experiments on AI self-replication. They tested inference setup on varied hardware and replication in a simplified, contained lab. In the replication evaluation, targets required no authentication, the acting model ran on a separate inference server, and successful setup triggered another agent copy.
The authors say they do not yet have a full rogue replicator. Their timeline for smaller models reaching the required capability is a forecast based on a general capability trend. These experiments do not measure the risk of an ordinary overnight coding session. They are a reason to take access boundaries seriously, alongside established software-security practices.
Written by Jonathan Simone with AI research and drafting assistance. This note reports no security incident at Simone Systems Research.
Before you leave
- Specify one task, allowed files and a stopping limit.
- Check actual permissions and remove unnecessary credentials.
- Review dependency, install-script and workflow changes.
- Save a tested checkpoint and a recovery path.
- Set conditions that require the agent to stop for review.
- Review the resulting change before a separately approved deployment.