Security model

Loop Engineer is built around explicit boundaries: what each agent can read, what it can write, which commands can run, and what never leaves your machine.

How Loop Engineer isolates code changes

Writing roles (implementer, fixer) edit only a managed, detached Git worktree under .loop-engineer/worktrees/.
Analyst, planner, reviewer, and final judge run with read-only provider permissions.
Loop Engineer never commits, never pushes, never force-resets, and never runs a destructive clean command.
loopeng clean removes only marked managed worktrees and preserves dirty worktrees unless you pass --force.

Command execution

The local tester runs only configured allowlisted commands without a shell. It rejects chaining, pipes, redirects, command substitution, denied binaries, and destructive Git commands. The configuration schema rejects unknown keys, invalid permissions, and unsafe tester assignments.

Credentials

Provider login stays inside the official Claude Code and Codex CLIs. The local dashboard can only start those login flows; it has no password, API-key, OAuth-code, or access-token field, and the dashboard API never handles credentials. The GUI binds to loopback only, uses a CSRF token, and ships a strict Content Security Policy.

Prompt and data handling

Repository content enters prompts inside untrusted-data fences, so file contents are treated as data rather than instructions.
Logs and reports redact common key, token, and password formats before storage.
Structured role handoffs are schema-validated before they become workflow state.

Honest limitations

Redaction cannot recognize every custom secret format. Keep .loop-engineer/ private and treat run reports like build logs. The context firewall and redactor reduce risk; they cannot prove provider behavior. Review generated changes before merging them.

The complete security documentation, including the threat model and reporting process, lives in the repository: docs/security.md and SECURITY.md.