Give each agent its own checkout so they cannot edit the same file, then pick how much isolation the work needs.
Give every agent its own checkout, so two can never edit the same file at once. Git worktrees do this on one machine for free. Containers go further, giving each agent its own processes, ports and installed tools. Then run each on its own branch and merge one at a time, reviewing each.
Read the whole answer →Move the agent off the thing that sleeps. A detached session survives a disconnect; only another machine survives a lid close.
Run the agent somewhere that does not sleep. A multiplexer such as tmux keeps it alive when your SSH connection drops, but not when the machine suspends. To survive a closed laptop the agent has to be on a machine that stays awake: a desktop, a home server, a VPS. Everything else is a workaround.
Read the whole answer →Keep the secret out of the conversation. The agent should operate a tool that holds the credential, never read the credential itself.
Keep the credential out of the model's context. The agent should run a tool that already holds the secret, not be told the secret and asked to use it. That means a secret store the process reads, credentials scoped to the narrowest rights the job needs, and separate keys per task.
Read the whole answer →Read the diff, not the summary. Make the agent's work land somewhere that requires a decision to merge.
Make the agent's work land somewhere that cannot merge itself, then read the diff rather than the agent's description of it. That means a branch per agent, every hunk reviewed before merge, and tests on the branch. The summary is a claim about the change; the diff is the change.
Read the whole answer →Two questions decide it: whose machine holds the checkout, and whose account holds the keys.
It depends on where the agent runs, and there are two questions: whose machine holds the checkout, and whose account holds the credentials. A cloud service clones your repository onto its infrastructure and holds tokens for you. A local agent keeps both on your machine and sends only the conversation to the model provider.
Read the whole answer →The container becomes the permission boundary. Decide what it can see, reach and hold before you turn the prompts off.
Run Claude Code in a container that sees only the repository you mount, holds only the credentials the task needs, and can reach only the hosts you allow. The container then becomes the boundary, which is what makes --dangerously-skip-permissions reasonable. Anthropic publishes a reference devcontainer with a default-deny firewall; Docker Sandboxes and managed workspaces package the same idea.
Read the whole answer →Keep the agent and the checkout on a machine you run, then add a way in from the browser. Uptime becomes your job.
Yes. Run the same agent CLI on a machine you control and add a way to reach it: SSH and tmux, Anthropic's Remote Control, an open-source web UI, or a self-hosted workspace. The checkout and credentials stay on your hardware, and turns still use your subscription. What you take on is the part the cloud products sell: a machine that stays on, and its environment.
Read the whole answer →Decide what wakes the agent, where it runs, and where its work lands. Choosing the model is the easy part.
Put the agent on a machine that stays on, give it a trigger (a schedule, a webhook or an event), run each job in a fresh checkout or container, and have every run end as a branch you review rather than a merge. Cap what each run may spend before the first one fires, because nobody is watching when it does.
Read the whole answer →Ten options, from plain worktrees to cloud agents, checked against each tool's own site in October 2026, with what each is best for and where it stops.
Choose by isolation first and interface second. Worktree tools such as Claude Squad, Conductor, Superset, Sculptor and Nimbalyst keep agents out of each other's files. Docker Sandboxes and intentic also separate processes, ports and credentials. Codex cloud, Claude Code on the web and Devin run on the vendor's machines. Plain git worktrees and tmux are still a valid answer.
Read the whole answer →