Loop detection is the harder problem and almost nobody solves it well at the infra layer. The pattern you're describing — write, fail, "fix," regress — is fundamentally a semantic loop, not a mechanical one. You can't catch it by diffing outputs or counting retries because each iteration looks superficially different. The agent thinks it's making progress.
What actually works in my experience: budget the agent a rolling token window per subtask, not per session. If it burns 40% of its context on a single function without a passing test, force an early return with the error context and let the orchestrator decide whether to retry with a different prompt or bail. Putting that logic in the VM host is tempting but wrong — the host doesn't have the semantic context to know "stuck" from "legitimately hard." That belongs in the agent framework or a thin supervisor shim between the framework and the execution environment.
Browser plugins have a security problem that's easy to miss: the agent runs inside your existing browser profile. That means it has access to your active sessions, stored credentials, autofill data — everything you're already logged into. A sandboxed machine is actually the safer primitive for untrusted agent tasks, not the more paranoid one. I work on Cyqle (https://cyqle.in), which uses ephemeral sessions with per-session AES keys destroyed on close, because you want agents in a cryptographically isolated context — not loose inside your personal browser where one confused-deputy mistake can reach your bank session.
The hard part here isn't checkpointing the agent's conversation state — that's just a list. It's checkpointing the world state. If step 5 wrote rows to Postgres and step 7 called a third-party API, forking from step 6 means you need the DB at its post-step-5 snapshot and some way to mock or replay the external call. Without that, you're replaying agent logic against a world that's already diverged. We ran into this enough building agent sandboxing at Cyqle (https://cyqle.in) — our approach is snapshotting the entire ephemeral environment at each checkpoint so the fork includes filesystem, DB state, everything. Curious how Time Machine handles external side effects that can't be rolled back.
The keychain-per-agent model is the right instinct, but the threat model gets complicated fast. When five agents share a keychain process, a prompt injection in agent A can exfiltrate credentials for agents B–E — one bad LLM output becomes a full company compromise.
The safer architecture is per-session credential scoping: each agent gets credentials minted for that specific task, revoked on completion. That's what we built Cyqle (https://cyqle.in) around — ephemeral sessions where the encryption key is destroyed on close, so if an agent misbehaves, the blast radius is bounded to that session.
The keychain needs the same isolation principle, but applied at the task boundary, not the agent boundary.
The macOS sandbox approach is clever, but there's an interesting philosophical split here: sandboxing constrains a local agent, whereas running agents in ephemeral cloud desktops removes the local risk surface entirely.
We built Cyqle (https://cyqle.in) partly around this idea — each session is a full Linux desktop that's cryptographically wiped on close (AES-256 key destroyed, data unrecoverable). Agents can do whatever they want inside, and the blast radius is zero by design. No residual state, no host OS exposure.
The tradeoff is latency and connectivity requirements. For teams already doing cloud-based dev work, it's a natural fit. For local-first workflows where you need offline capability or sub-50ms responsiveness, something like Agent Safehouse makes more sense.
Both approaches are worth having — the threat model differs depending on whether you're more worried about data exfiltration or local system compromise.