How to unlock coding agents that work autonomously

A coding agent that stops to ask permission every few minutes is not autonomous. A coding agent that can’t be left alone to complete a defined plan is not autonomous.

For months that described my setup. I had Claude Code, spec-driven development, and speq-skill, a workflow that enabled me to ship features in a couple of hours. What I did not have was a way to leave the agents to do the work without me. Every session ran on my laptop, which held credentials, personal data, sensitive information and software that did not belong in an unattended environment. So I watched every step.

To break free from that, I needed a setup that would let me:

1. Run agents safely in “yolo mode”
2. Keep agent sessions persistent and organized across remote hosts
3. Edit and investigate specs, plans, and code remotely

With this article, I walk you through how I tackled those challenges.

How to run agents safely in “yolo mode”#

The solution that works best for me is a designated Linux host. Each host contains only the software I need to build and generate my projects. No personal data, sensitive data or credentials I am not willing to expose.

I currently run two machines:

1. Work-related projects: Talos. An EC2 instance on AWS of type r7i.xlarge. I chose this type because it provides 4 vCPU and 32 GB of memory, which gives enough headroom for compiling Rust in parallel and keeping several Claude Code sessions warm at the same time. I also run integration tests and end-2-end tests within Docker containers, so I need plenty of memory for those.
2. Private projects and open-source: Ferris. My old MacBook Pro 15“ Retina, which I wrote about in Why I turned my old MacBook into a server for coding agents. Specs: Intel Core i7 at 2.50 GHz, 16 GB RAM. For now, the old laptop has enough power to build and test my open source projects.

Both machines run Debian Linux with XFCE. I covered the Ferris setup in detail in the Ferris article, including how to disable lid-close sleep, install Debian, configure XRDP for remote access, and sign into Claude Code via a browser.

How to keep agent sessions persistent and organized#

tmux is how I keep multiple agent sessions organized across Ferris and Talos. Every Claude Code session runs inside tmux, so the session survives when I disconnect from SSH. I can come back any time, reattach, and can interact with the agent and follow its output.

My workflow for a new task:

# SSH into the host
ssh ferris@ferris.local

# Start a new tmux session
tmux new

# Rename the window to something meaningful (prefix + comma)
CTRL-B ,

# Start Claude in yolo mode
claude --dangerously-skip-permissions

I added a customer status bar to tmux based on a bash script. It shows me at a glance where I am and how the machine is doing. On the left: the hostname in a green pill, so I always know whether I am on Ferris or Talos. On the right: live CPU load, memory usage, and disk fill. Each active agent run appears as a named window tab in the middle.

[hostname] [window-name]                      [system-stats]

The hostname on the left comes from #H in status-left. The right-side stats are produced by a small shell script that reads /proc/stat and free on Linux, or top -l1 and vm_stat on macOS, and outputs one fixed-format line: CPU X% | Mem X/XGB X% | Disk X%. The stats refresh every 5 seconds.

I published the tmux config and the stats script as a gist on GitHub if you want to to copy the setup on your end.

How to edit and view specs, plans, and code remotely#

Agentic engineering involves plenty of reading: plans, spec requirements, and verification reports. I use speq-skill on most of my projects, so the main artifacts before, during, and after a feature are Markdown files. For most of my projects, I also check code or step through the project’s integration harness to make sure the QA layer does what it should.

I tried two approaches before landing on one that worked:

1. Samba shares on macOS. Too slow. IDEs expect file-system events that Samba does not provide. macOS also writes ._* metadata files into every folder, which cluttered the project trees. And the port needed an SSH tunnel to be reachable.
2. SSHFS. Essentially the same problems. The latency made editing feel sluggish and file-system events were unreliable.

The solution that works is the Remote - SSH extension for VS Code. It opens any folder on a remote machine directly in VS Code over SSH: full file explorer, editor, IntelliSense, and a terminal that runs on the remote host. Setup is minimal: install the extension, make sure your SSH host is in ~/.ssh/config, and pick it from the remote connection menu. After that, speq-skill’s specs, plans, and verification reports open instantly and render correctly as Markdown. The screenshot above shows Ferris’s speq-skill project open from my main Mac.

What this setup changed#

The productivity gain was bigger than I expected, and it came from a direction I did not anticipate.

Running agents unattended does not just mean the same work gets done faster. It means a different kind of work becomes possible. I now run three or four projects in parallel. While one agent works through a plan of a certain project, I am designing the next feature for a different project in another session, or writing, or doing something else entirely. Each project gets real focus, because I am not splitting attention between watching an agent and thinking about what comes next. The agent handles its tasks and I handle mine.

The bottleneck is no longer the machine or my attention. It is the quality of the intent I describe before I let the agent do the work.