Flow
Five pieces and where each stands
1Merge into the settings file
Done. Only one key changes, and the file is locked to its owner.
2Copy into the project
Done, but nothing checks that it worked, and it replaces any settings the project had.
3Stage only the output folder
Done. A leftover copy shouldn't reach the pull request.
4Delete in a finally block
Done for most failures, not for steps before the block or a killed run.
5Sweep old sandboxes
Not added in this commit.
Every run of my repo agent used to leave its sandbox running when it was done. The line that deleted the sandbox was commented out. The cleanup step ran each time, logged that it was cleaning up, and did nothing.
That's sloppy. It got worse in the commit that turned the delete back on, because that same commit also told the agent to stop asking for permission.
The job clones a repo into a fresh cloud sandbox, has a coding agent write skill files (notes that help other coding agents work in that repo), and opens a pull request. Nobody is around to approve each command, so the prompts only stall the run. This commit turned them off.
How the setting gets in and out
The sandbox image writes the no-prompts mode into the agent's user settings. It merges that one key into any file that's already there instead of replacing the file, and it locks the file to its owner. If you do this yourself, merge. Overwriting throws away other settings and you won't see it happen.
Before the agent starts, the runner copies that file into the cloned repo's settings folder. Probably that's to make sure the agent picks it up, but the commit doesn't say. Right before staging, the runner deletes the copy.
The end of the run matters most.
The sandbox gets destroyed last, in a cleanup that runs no matter what happened before it, and that was the step someone had commented out.
Why the delete matters so much
With prompts off, the sandbox is the only wall left. A sandbox that never dies is a machine nobody watches, holding a copy of private code. I had been leaving those behind. The same commit that stopped it also gave the agent more freedom, and if those two had landed in the other order, I'd have had prompt-free agents in boxes that never went away.
Two things hold up. The runner stages only the folder the agent writes into, so a leftover settings copy shouldn't reach the pull request. And the delete sits in a finally block, so failed runs reach it too, except for a couple of small steps that run before that block starts.
Gaps in the copy, the modes and the cleanup
There are no tests for any of this. The copy and the delete don't check whether they worked. If the repo had its own settings file, my copy replaces it for the run. The settings file and the agent's startup options name different modes, and it's unclear which wins. A failed sandbox delete is only a log line. The commit also checked some raw run logs into my repo, which I haven't read yet.
I'd bet a run killed at its time limit never reaches the cleanup at all. A sweeper that deletes any sandbox older than the longest run would catch those, and this commit doesn't add one.