Safe agent loops: a practical control checklist

A coding agent can misunderstand requirements, alter the wrong file, or propose a command with unintended effects. Keyword warnings alone cannot understand arbitrary shell behavior, and a sandbox does not prove that a change is correct. A practical safety model therefore combines several independent controls: constrained permissions, external proof, budgets, stop rules, human approval, and audit artifacts.

LoopLatch separates browser validation from local enforcement. The website blocks missing structural inputs and warns about risky terms, but it never executes a command or claims to validate shell safety. The locally generated harness is responsible for capability checks, worktree rules, typed worker results, timeouts, approvals, and stop semantics.

The task, done condition, verifier command, repository content, and model output can all influence local execution. Treat each as untrusted data. The browser must render and serialize user text without evaluating it. The local harness must parse structured output as real JSON, reject malformed results, and avoid interpolating model text directly into shell execution.

The website also has a privacy boundary: it should not receive repositories, secrets, task analytics, or hosted execution traffic. Static public content and templates can be delivered normally, while task content and generated archives stay in the loaded document until the user chooses to copy or download them.

The verifier is the loop's independent success authority. Run it before each worker to avoid unnecessary edits and after each worker to prove the new state. Preserve complete logs for both runs. A zero exit code can end the loop; a worker statement such as “all tests pass” cannot.

A strong verifier measures the requested behavior and produces a stable exit result. If the task is a UI regression, a type check alone is insufficient. If the task is a formatting failure, a full browser suite may be wasteful. Match proof to the acceptance criterion, then add repository-required gates.

A local coding loop normally needs to inspect the repository and write files in its workspace. It does not need a standing bypass of the Codex sandbox. LoopLatch fixes the worker at workspace-write and keeps auto-commit and auto-push off. Those values are constraints, not website preferences.

A sandbox limits capability; it does not make every allowed edit correct. Keep the repository itself isolated from unrelated credentials and production access, review the generated harness, and use a separate disposable environment when the task has unusual operational risk.

No single budget covers every unproductive state. Maximum iterations limits worker turns. A total timeout limits wall-clock exposure, including slow verifiers. A repeated-failure limit catches a stable error that is not improving. A no-diff stop catches an iteration that changed nothing. Capability, collision, dirty-worktree, invalid-result, and approval stops close other unsafe paths.

Use one total deadline for the complete loop rather than resetting the clock for every subprocess. On expiry, terminate the active child, allow a short cleanup grace period, record the timeout, and return a non-zero result. An exhausted budget is a stop, not evidence that the task succeeded.

A risky action should never inherit permission from a template, a website warning, or a prior approval. When a worker needs approval, it should return a structured request containing an action ID, category, reason, and exact action. The harness displays those fields and asks a default-No question on an interactive terminal.

Approval applies to one exact subsequent worker turn and is cleared immediately, whether the action succeeds or fails. Decline, end-of-file, missing TTY, an action mismatch, or a second unapproved risky action stops the loop. This is deliberately inconvenient compared with a persistent allow-list because the decision remains specific and reviewable.

A clean worktree is the safest default because each patch can be attributed to the loop. If reviewed dirty work is allowed, confirmation should be explicit and interactive. The harness can capture a synthetic Git tree before and after the iteration without changing the real index, refs, branch, or commits, then write a binary patch for the delta.

Per-iteration artifacts should retain the worker prompt, Codex JSONL, typed result, verifier logs before and after, and the patch. Aggregate progress and decision files are useful summaries, but they should not replace immutable records. Auditability helps a reviewer understand what happened; it does not approve the change automatically.

Use the checklist as a preflight, then inspect the generated repository-specific implementation. The correct commands and file boundaries depend on the target repository, so a generic website cannot perform the final review for you.