DEV Community: Aviv Laufer

Close the laptop, the agent keeps working

Aviv Laufer — Thu, 15 Oct 2026 13:01:37 +0000

Part 2 of My Agentic Setup. Start from part 1

When an agent runs on my laptop, it stops when I close the laptop. That is fine for a five minute task. It is not fine for an audit that takes an hour, or a crew of agents working through a backlog.

So my long agent work runs on a cloud VM, inside tmux. The laptop is only a window into it.

The whole thing is one command:

agent-session.sh my-vm --gcloud

I'm on the VM. I start omp, give it work, and close the laptop. Tomorrow I run the same command, from the same laptop or the other one, and I'm back in the same place. The agent kept going while I was away.

The idea is simple: the agent runs on the VM inside tmux, and the laptop is only a window, so one command starts the work or brings me back to it from any machine.

Getting there was less simple. Here is what broke first.

What broke

The VM was too small

My first VM was a 1 GB e2-micro. omp got killed by the OOM killer while it was generating its shell completions. Not while running an agent, just while setting up the shell.

Small doesn't mean slow here. It means broken. I moved to a larger VM, and now the troubleshooting table in my docs has this line:

a tool is killed with exit 137    out of memory; check free -h, resize the VM

The login never finished

Every agent CLI logs in on each machine separately. My laptop's logins don't carry over to the VM, and I don't want them to.

claude login opens a browser flow and then waits for the callback on http://localhost:54545/callback. On the VM, that is the VM's localhost. The browser is on my laptop. It authorizes, redirects to port 54545 on the laptop, finds nothing there, and the login never completes. The browser just spins.

The fix is to forward the callback ports back over ssh. The script has a flag for it:

# Ports the agent CLIs listen on for their OAuth callback. Forwarded so the
# browser on this laptop can reach a login running on the VM.
AUTH_PORTS="54545 54546 8976"

if [ "$FORWARD_AUTH" -eq 1 ]; then
  for port in $AUTH_PORTS; do
    forward_args+=(-L "${port}:localhost:${port}")
  done
fi

So the first time on a new VM I connect with --forward-auth, then run claude login and cursor-agent login inside the session. When a tool has a device code flow, like gh auth login --web, I use that instead. It needs no tunnel at all.

`Unknown scope: use`

Even with the tunnel, a login can fail with Unknown scope: use.

The cause: the login URL was in a boxed TUI panel. The panel wraps the long URL, and copying the visible lines cuts off the end of the scope list. The browser gets a broken URL.

The fix: copy the link from a plain, wide terminal. Or send the output to a file and take the URL from there:

claude login 2>&1 | tee /tmp/login.txt

Quoting in `--run`

I wanted to start a job without attaching first:

agent-session.sh my-vm --gcloud --run 'omp "audit the auth module and report back"'

That command goes through three layers: ssh, the shell on the VM, and tmux. Each one has its own quoting rules. A command with quotes inside quotes doesn't survive all three.

The fix is to not quote it at all. The script base64-encodes the command on the laptop and decodes it on the VM:

# The command crosses ssh, the remote shell and tmux, each with its own
# quoting. base64 is the one encoding that survives all three unchanged.
encoded="$(printf '%s' "$RUN" | base64 | tr -d '\n')"
remote="tmux new-session -A -d -s ${session_q}; \
        tmux new-window -t ${session_q} \"sh -lc 'eval \\\"\\\$(printf %s ${encoded} | base64 -d)\\\"; exec \\\$SHELL -l'\"; \
        tmux attach -t ${session_q}"

It is not pretty, but base64 has only letters, digits, +, / and =, so none of the three layers has anything to escape.

The exec $SHELL -l at the end matters too. When the agent finishes, the window stays open with a shell in it, so the final answer is still on screen when I come back.

Running the script on the VM itself

The script is meant to run on the laptop. Run it on the VM by mistake, and gcloud compute ssh tries to ssh from the VM to itself. It generates a new SSH key there and fails on permissions the VM's own service account doesn't have.

The fix is a hostname check. If I'm already on the target machine, the script skips ssh and just attaches:

if [ "$(hostname -s 2>/dev/null)" = "${HOST%%.*}" ]; then
  exec tmux new-session -A -s "$SESSION"
fi

Now the same command does the right thing from both places.

`command not found: omp`

This one happens on a fresh VM. You connect, tmux starts, then you install the tools. Inside the session, omp is not found.

The tmux server started before the tools were installed, so it still has the old PATH, and every new window gets that old PATH too. Reconnecting doesn't help, because the server is still running.

tmux kill-server

Then connect again.

Smaller ones

Some issues came from setting up the VM, not from running agents on it:

A minimal Debian image has no make, and my setup runs make. It is in the first install step now.
Debian ships Node 18. Some of my npm tools need 22. Linux takes Node from mise instead of apt.
The ssh client forwards a locale the VM didn't generate, which prints a setlocale warning on every login. It is harmless. Installing the locale on the VM, or not forwarding it, makes it go away.

The setup

The VM comes from the same dotfiles

The VM is not special. It gets the same dotfiles as my laptops, with a Linux layer on top. This is the whole OS profile:

# profiles/os/linux.toml
# Linux defaults, targeting headless Debian and Ubuntu LTS hosts.

capabilities = ["cli", "linux"]

[shell]
ssh_use_keychain = false

[packages]
packs = ["base", "agents", "formal", "linux"]

cli without desktop keeps desktop applications off a headless machine. ssh_use_keychain = false matters because UseKeychain is a macOS-only SSH option, and on Linux it makes ssh reject the whole config file.

The agents pack

The agent tools come from a package pack. On macOS most of them are Homebrew formulas. On Linux most don't have an apt package, so each row has an upstream installer:

[[package]]
name = "can1357/tap/omp"
provider = { macos = "brew", linux = "upstream" }
binary = "omp"
install = { linux = "...curl the release binary into ~/.local/bin..." }

[[package]]
name = "claude-code"
provider = { macos = "upstream", linux = "upstream" }
install = "curl -fsSL https://claude.ai/install.sh | bash"
binary = "claude"

[[package]]
name = "node"
provider = { macos = "brew", linux = "upstream" }
min_major = 22
install = { linux = "mise use -g node@lts" }

The bootstrap script shows each upstream command and asks before running it. It also exits non-zero until everything is installed, so a half-installed VM doesn't look finished.

What runs on the VM today:

Tool	What it does there	Installed on Linux by
tmux	keeps sessions alive	apt
omp	my main agent	release binary
Claude Code	crew agent	its install script
Cursor agent	crew agent	its install script
Firstmate	runs the crew	git clone
worktrunk	worktrees	release tarball
Node	for the npm tools	mise

New machine, in order

Setting up a VM follows the same eight steps as a laptop:

Base tools: git, ssh, make, Python, chezmoi
A new SSH key for this machine, added to GitHub
Clone the dotfiles
A dry run into a fake home
Declare the machine in a profile
Install the software
Install the configuration
Log in to each tool

Configuration and software never mix. Step 7 installs no packages, and step 6 changes no configuration. Logins are always last, and always per machine. Nothing is copied from another machine.

How the script works

One tmux command does most of the work

The whole idea is one tmux flag:

remote="tmux new-session -A -s $(printf %q "$SESSION")"
exec ssh -t "$HOST" "$remote"

new-session -A attaches to the session if it exists and creates it if it doesn't. So the first connection and every connection after it are the same command.

ssh is only the transport. -t gives it a terminal, because tmux refuses to attach without one.

On GCP the script uses gcloud compute ssh with --tunnel-through-iap. My VM has no external IP, so IAP is how I reach it.

Less typing

The machine, project and zone are the same every time, so I set them once:

# ~/.zshrc.local
export AGENT_SESSION_HOST=my-vm
export AGENT_SESSION_PROJECT=my-project
export AGENT_SESSION_ZONE=my-zone

Now it is:

agent-session.sh --gcloud            # connect
agent-session.sh --gcloud --list     # what is running

--list is my dashboard:

billing: 1 windows (created Mon Sep 14 09:57:17 2026)
payments: 1 windows (created Mon Sep 14 09:56:16 2026)

Sessions, windows and tabs

These three are easy to mix up, so here is how I use each one:

A tmux window (Ctrl-b c, or fm <project>): jobs I want to watch together. Ctrl-b w picks one.
A tmux session (--session <name>): jobs I want kept apart, each one reattachable on its own.
A Ghostty tab: only a way to see two sessions at the same time. Closing it changes nothing on the VM.

One thing surprises people. Two Ghostty tabs attached to the same session show the same screen, live, with both cursors. That is nice for watching a long run on a second monitor, and useless for doing two things at once. Different work needs --session, not another tab.

What survives

Closing the laptop, losing wifi, disconnecting: keeps running.
Connecting from the other laptop: same sessions, same screens.
Two laptops connected at once: both see the same screen.
Rebooting the VM: the agents stop.

The VM is always on, so the last one almost never happens. I have tmux-resurrect and tmux-continuum installed, so if the VM does reboot, the sessions and windows come back. An agent that was in the middle of its work doesn't.

Where I am now

These days I mostly use herdr for this. It does the same job as tmux on the VM, with its own way of saving machines and reconnecting. Use one or the other, not both: herdr inside tmux makes their keyboard shortcuts fight.

The pattern is the same either way. The agent runs on a machine that stays on, and the laptop is only a window.

Try it

The companion repo has a sanitized copy of agent-session.sh and a test suite. The tests run tmux on a private socket with fake ssh and gcloud, so they don't need a VM and don't touch your own tmux server. They check the --run quoting with quotes, $ and backticks, the local attach, --forward-auth and the IAP flags.

cd 02-remote-agents
make test

golem-notes-examples/02-remote-agents

Where do your long agent runs live: your laptop, a VM, something else? Leave a comment.

This is part 2 of my series on running a real agentic dev setup. I publish each part first on Golem Notes, with the full write-up and what's coming next. Subscribe there to get the next one in your inbox: Golem Notes

I talk to one agent. It runs the others.

Aviv Laufer — Mon, 05 Oct 2026 12:49:31 +0000

The map of my setup: OMP in the middle, the tools it dispatches, and the 13 parts coming next.

Most of my coding day happens in one terminal pane. I type into OMP, and OMP does the rest.

It picks a model for each job. Planning goes to Opus. Normal turns go to Sonnet. Reviews go to a GPT model, so the reviewer is never the same model that wrote the code. When the work is big, OMP hands it to a fleet: Firstmate spawns crew agents, each one in its own worktree, and most of the time the crew is working and I'm not.

I use several coding agents, but I don't configure them separately. One repo decides which rules, skills, identities and models every agent gets, on every machine.

That repo is my dotfiles. It started in December 2016 with a tmux and vim config. In the last three months, since agents took over my workflow, it got almost as many commits as in the nine years before.

This post is the map: every tool, how they connect, what broke when I first wired them together, and the fix.

The map

                         me
                          |
                          v
   +---------------------------------------------+
   |  OMP  (my main tool, one model per role)    |
   +---------------------------------------------+
            |                        |
            | talks to models        | fm <project>
            | directly               v
            |              +----------------------+
            |              |  Firstmate           |
            |              |  (first mate on OMP) |
            |              +----------------------+
            |                 |   dispatch rules
            v                 v
   Anthropic, Cursor,     crew: OMP, Claude Code,
   OpenAI, local model    Codex, Grok
                              |
                              v
                     treehouse worktrees
                     (one per task, pooled)

   herdr on the laptop, tmux on the VM: every agent gets a pane
   dotfiles: renders the config for all of the above

It runs on two laptops and a cloud VM. My work laptop gets the company rules: our skills, our ticket conventions, our compliance rules. My personal laptop should not see any of that, and the two use different model accounts.

I'll go through each box below. First, the part that went wrong.

What broke

OMP is where I type, but it is not the only agent that runs. Firstmate starts Claude Code, Codex or Grok as crew, and Cursor agent is there too. Each of these tools reads its instructions from a different place:

~/.claude/CLAUDE.md
~/.codex/AGENTS.md
~/.pi/agent/AGENTS.md
~/.agents/AGENTS.md
~/.gemini/GEMINI.md
~/.config/opencode/AGENTS.md
~/.copilot/copilot-instructions.md

Seven files that should say the same thing. Skills have the same problem: each tool has its own skills folder.

Agents read their instructions in every session, so when those instructions drift, the agents drift with them. Nothing warns you.

Two things were wrong.

First, the files had drifted. My ~/.codex/AGENTS.md was a copy I'd made by hand in May, and it was out of date. Pi, another agent I had installed, saw only 3 of my 23 skills. Each tool was working with a different set of rules, and I had assumed they were all the same.

Second, the instructions were too long. The global file had grown to 465 lines, about 21 KB or 5,300 tokens. It loads on every turn, in Claude Code and each of its subagents, in OMP, Codex, Pi, Gemini, OpenCode and Copilot. So every one of those paid for all 465 lines, every time.

The fix

One source, compiled per machine

I split the instructions into small fragments, one topic per file:

agents/fragments/
  00-header.md
  05-no-emojis.md
  10-voice.md
  20-workflow.md
  30-git-conventions.md
  32-worktrees-stacking.md
  35-pull-requests.md
  45-core-principles.md
  ...
  50-work-skills.md     # work only
  55-compliance.md      # work only

Each machine profile is a plain list of the fragments it gets. The personal profile leaves out the work-only ones:

# agents/machines/personal.txt
00-header.md
05-no-emojis.md
20-workflow.md
35-pull-requests.md
32-worktrees-stacking.md
45-core-principles.md
30-git-conventions.md
40-languages.md
10-voice.md

make build puts them together into one flat AGENTS.md, with a marker before each fragment so I can see where a rule came from:

while IFS= read -r name; do
  case "$name" in ''|'#'*) continue ;; esac
  printf '<!-- Source: fragments/%s -->\n' "$name"
  cat "fragments/$name"
done < machines/$(PROFILE).txt

Why flat and not includes? Codex, Pi and Cursor don't expand any include syntax. So the modular part lives in the source, and every tool gets one plain file.

make deploy then symlinks that one file into all seven paths. There are no copies left to go stale. When I edit a fragment and run make build, every tool picks it up in its next session.

A check that blocks drift

A pre-commit hook runs make check. It builds again into a temp folder and diffs the result against the built file. If I edit a fragment and forget to build, the commit fails:

check: build/personal/AGENTS.md is out of date. Run: make -C agents build

One skills folder

Skills go in one place, ~/.agents/skills/. When I checked in July, Codex, Cursor, OpenCode, Gemini and Copilot all read that folder directly. Claude Code doesn't, so make skills-sync adds a symlink per skill into ~/.claude/skills/. It does the same for Pi's own folder, which is where the 3-of-23 problem was.

It never overwrites a real file. A skill installed some other way gets skipped with a warning, not deleted.

Then I could cut it in half

With one file, I could finally see everything in one place. So I cut it. 465 lines down to 215. About 5,300 tokens down to 2,500.

The biggest cut was the pull request procedure. I moved it, as is, into a skill. It loads only when an agent works on a PR. The fragment kept only the hard rules: draft only, no merge and no deploy without my approval. The rest of the fragments I trimmed down to the rules, without the explanations.

With seven copies, I never cut anything. I didn't know which copy was the real one, so I only added. With one source, cutting is safe.

Now I split instructions into two kinds. Rules every agent needs on every turn go in the global file, and I keep it short. Procedures for one kind of task go in a skill. An agent renaming a variable doesn't need my PR procedure, and it shouldn't pay for it in tokens.

The rest of the map

With that in place, here is what each box in the diagram does.

OMP

OMP (Oh My Pi) is a coding agent that talks to the model APIs directly. I log in to Anthropic, Cursor and OpenAI once, and OMP routes each kind of work to a model through roles:

modelRoles:
  default: cursor/claude-sonnet-5-5:medium
  plan:    cursor/claude-opus-5-5:medium
  task:    cursor/claude-sonnet-5-5:medium
  slow:    cursor/composer-2.5:high
  smol:    cursor/gpt-5.6-luna:medium
  commit:  cursor/gpt-5.6-luna:low
  tiny:    local/lfm2.5-230m

The reviewer is set in a separate block of the same config file:

task:
  agentModelOverrides:
    reviewer: cursor/gpt-5.6-terra:high

That's my personal laptop. It only has Claude and Cursor accounts, so almost everything goes through Cursor. The work laptop uses the same roles with different providers, and dotfiles picks the right ones per machine.

Model names change every few months, so here is the current table. I'll keep it up to date. The pattern is what matters.

Role	What it does	Current model
default	normal turns	Claude Sonnet 5.5
plan	planning	Claude Opus 5.5
task	subagent work	Claude Sonnet 5.5
slow	hard fixes	Composer 2.5
reviewer	code review, different vendor than the author	GPT-5.6 Terra
smol	cheap fan-out	GPT-5.6 Luna
commit	commit messages	GPT-5.6 Luna, low effort
tiny	throwaway calls	a 230M local model
judge	"is this actually done?"	a small model on Cloudflare Workers AI

Firstmate

Firstmate runs a fleet of agents. I'm the captain. The first mate is an OMP session that takes my ask, writes a brief and starts crew agents to do the work. fm <project> opens it for one project, and each project gets its own home, so backlogs and running tasks never mix.

The crew is OMP by default, but a few dispatch rules send work to other tools:

{
  "when": "The task is a trivial mechanical edit: rote rename, formatting sweep, targeted typo fix, dependency bump, or gathering files.",
  "use": { "harness": "claude", "model": "haiku", "effort": "low" }
},
{
  "when": "The task is a scout: investigate, audit, trace a bug, or produce a standalone report without changing code.",
  "use": { "harness": "omp", "effort": "high" }
}

My preferences for the first mate live in a markdown file it reads at the start of every session. A few lines from it:

- Never use em dashes in PR titles, PR bodies, commit messages, or comments.
- Every PR any worker opens is created in draft mode, no exceptions.
- Escalate to me on any change touching auth, tenancy boundaries, data
  retention, or migration ordering, even when the tests are green.
- Scout tasks end in a report, never a code change.

Worktrees: two tools on purpose

When I start an agent myself, I use worktrunk (wt). One alias creates a branch, a worktree and an agent session:

worktree-path = "~/worktrees/{{ repo }}/{{ branch | sanitize }}"

[aliases]
cc  = "wt switch --create {{ branch }} -x claude"
cur = "wt switch --create {{ branch }} -x wt-agent -- cursor-agent"

When Firstmate starts a crew agent, it uses treehouse. Treehouse keeps a pool of worktrees per repo and leases one out per task (treehouse get --lease, then treehouse return). Two crew agents on the same repo get slot 1 and slot 2 and never collide. Most of the worktrees on my machine come from treehouse, because most of the time the crew is the one working.

herdr and tmux

herdr is the terminal multiplexer on my laptops. Unlike tmux, it knows which pane is an agent and whether that agent is working, blocked, done or idle:

[ui]
agent_panel_sort = "spaces"     # one space per repo/worktree
status_indicators = "symbols"   # blocked/working/done/idle
show_agent_labels_on_pane_borders = true

With several crew agents running, ctrl+alt+up and ctrl+alt+down jump between them. On the cloud VM I use plain tmux, so agents keep running after I close the laptop.

Dotfiles

Everything above is rendered from the dotfiles repo, in layers:

base < os < organization < machine < local.toml

Each layer only overrides the values it names. The work laptop declares the work organization and the personal one. The personal laptop declares only personal. A repo outside every declared root has no git identity at all, so a commit fails instead of going out under the wrong name.

Try it

The companion repo has a small working version of the fragments build: four fragments (one of them work-only), two profiles, a pre-commit hook, and the Makefile with build, check and deploy. By default it deploys into a fake home folder, so it never touches your real config. When you point it at your real home, it skips any real file in the way instead of overwriting it.

make build && make deploy
ls -la fake-home/.codex   # AGENTS.md -> .../build/personal/AGENTS.md

golem-notes-examples/01-the-map

What's coming

One part every two weeks:

The map (this post)
Close the laptop, the agent keeps working: agents on a cloud VM with tmux
My agents on two laptops, controlled from one phone app
Every PR gets an agent review before a human sees it
Captain, first mate, crew: orchestrating a fleet of agents
Nine roles, not one model
Right model for the task: dispatch rules and cheaper subagents
When the credits run out: fallback chains
A cheap judge for "is this actually done?"
Teaching agents how I work: my skills library
Dotfiles an agent can't break
One laptop, many companies: identities and secrets
Testing your dotfiles like production code
What I'd do differently

If you run more than one agent tool, I'd like to know how you keep their rules in sync. Leave a comment.

This is part 1 of my series on running a real agentic dev setup. I publish each part first on Golem Notes, with the full write-up and what's coming next. Subscribe there to get the next one in your inbox: https://golemnotes.substack.com/p/i-talk-to-one-agent-it-runs-the-others?utm_source=devto&utm_medium=social&utm_campaign=agentic-setup-01

DEV Community: Aviv Laufer

Close the laptop, the agent keeps working

What broke

The VM was too small

The login never finished

Unknown scope: use

Quoting in --run

Running the script on the VM itself

command not found: omp

Smaller ones

The setup

The VM comes from the same dotfiles

The agents pack

New machine, in order

How the script works

One tmux command does most of the work

Less typing

Sessions, windows and tabs

What survives

Where I am now

Try it

I talk to one agent. It runs the others.

The map

What broke

The fix

One source, compiled per machine

A check that blocks drift

One skills folder

Then I could cut it in half

The rest of the map

OMP

Firstmate

Worktrees: two tools on purpose

herdr and tmux

Dotfiles

Try it

What's coming

`Unknown scope: use`

Quoting in `--run`

`command not found: omp`