Domenic Denicola's agentic coding setup: no-approval agents in a disposable Linux VM

A setup that runs Claude Code and Codex with no approvals inside a home Linux VM reached over Tailscale, aimed at solo devs running parallel agents.

Picture an independent full-stack developer who splits her week between a Windows desktop at home and a laptop on the train. She runs Claude Code locally. Every few minutes it stops to ask permission, so she can't step away. When she closes the laptop lid, the session dies. When the agent reaches for Bash idioms in PowerShell, quoting and encoding break. If she starts a second agent on the same repo, the two edit the same working tree. She ends up babysitting one agent at a time, at one desk.

Domenic Denicola's "My Agentic Coding Setup, July 2026" (published 2026-07-23) targets that set of problems. It is a write-up of his personal setup, not a product. Coding agents run with approvals turned off inside a disposable Ubuntu Server VM on his always-on home desktop. Tailscale connects his machines. Git worktrees separate parallel tasks, and GitHub holds anything worth keeping. He reports that the result lets him "have frontier models fix production bugs from my phone, on a train." A post sharing it from @bibryam sums it up this way: "The key design choice is the blast radius, not the model."

What it is

This is one developer's account. Domenic says it is "not as a step-by-step guide," and suggests you ask your agents to handle "the fiddly parts." Here are the pieces, each matched to the pain above:

He also mentions Portless and chezmoi as "extra goodies." The excerpt we have doesn't say what he uses them for.

Alternatives. Our research gathered no sources comparing this setup with devcontainers, Codespaces, cloud agents or local Docker sandboxes, so we won't invent trade-offs. The sources do cover these options:

Who it's for

Pick this up if you are a solo or independent developer with an always-on machine (or the budget for a cloud VM). You want several agent workstreams running while you're away from the keyboard. You're willing to accept, as Domenic does, that the setup is "not really" safe in exchange for zero approval interruptions. It fits especially well if you already work from more than one machine and are tired of Windows shell friction.

Skip it if your GitHub credentials reach repos or production systems you can't afford to have an agent touch. The same applies if you work under corporate security policy, or if you need an approval gate before merges. Domenic's own anecdote shows why. That's our reading of his risk list, not a rule he states.

Before and after

Before (raw local agent, per Domenic's requirements list):

  1. Start Claude Code on the machine in front of you.
  2. Approve tool calls as they come up, which keeps you at the desk.
  3. Close the laptop and the session ends. Resume on the other machine without your session, uncommitted state or gitignored files.
  4. Run a second agent and it shares the same working tree.
  5. Review work in the harness UI or wait for a PR.

After:

  1. SSH into the VM over Tailscale (ssh agents-base in his example), or open the ChatGPT or Claude desktop app pointed at it.
  2. Start a session and tick the worktree box. Start another session for a second task in its own worktree.
  3. Walk away. Approvals are off, and the session keeps running on the VM when you close your laptop.
  4. Open VS Code over SSH to review the work in progress, or visit the agent's dev server at a Tailscale HTTPS address.
  5. The agent commits, pushes and opens PRs through gh. GitHub Actions runs CI.

Try it

Domenic's post describes the settings he uses, but not a full install procedure. These are the steps it does describe:

  1. Create a Linux VM. He used an Ubuntu Server ISO on his home desktop with nested virtualization on. He doesn't give specific RAM, disk or cost figures.
  2. Install Tailscale on the VM and on every client, then SSH in.
  3. Install Claude Code and Codex CLI on the VM. Per the Claude Code docs, most Claude Code surfaces require a Claude subscription or Anthropic Console account.
  4. Turn off approvals. His ~/.codex/config.toml:
approval_policy = "never"
sandbox_mode = "danger-full-access"

His ~/.claude/settings.json:

{
  "permissions": {
    "defaultMode": "bypassPermissions"
  },
  "skipDangerousModePermissionPrompt": true
}
  1. Optionally add your user to sudoers and log in to gh, as he does. Each step widens what an agent can do.

A cautious first step, based on his own suggestions: do steps 1–4 but hold off on step 5. Or give gh a token with restricted permissions. He names that option but doesn't walk through it.

Where it breaks

Domenic's own risk list. With these settings, he writes, an agent "could start deleting your GitHub repositories, uploading your gitignored secrets to the internet, replying to GitHub issues in your name, or accidentally wiping the VM's entire home directory," or even escape the VM. His conclusion that "in practice, it turns out fine" because agents "seem to be aligned and non-malicious, for now" is his experience, not a guarantee.

Literal-minded merges. He told ChatGPT 5.6 Sol, "Let's send a PR for this and get it merged to main." When he looked back, it had already merged to main instead of waiting for review. With a gh token that can merge, an approval-free agent can affect production.

Client quirks. In the ChatGPT app, project and session lists don't sync perfectly across clients and need "some jiggling." In the Claude app, session handoff means going back to tmux, and it has no grouping of sessions by folder.

Claude's worktree location. By default the Claude app puts worktrees inside the project at .claude/worktrees/. He reports three side effects:

Our excerpt cuts off before his fix.

The Windows premise holds up, with caveats. One developer reports 15 months of PowerShell encoding and path breakage with Claude Code on Windows. Bug reports describe agent plugin instructions that assume Unix env syntax and a hook that rewrote PowerShell calls with POSIX quoting. Anthropic is working on native PowerShell support, but that tool is still a preview without Windows sandboxing.

Unconfirmed:

Treat this as one developer's well-documented setup, not a vetted pattern.

Sources