My Laptop Shut Down at Midnight, But My Coding Agent Kept Working. Here's How.

It's 2am. You closed the laptop. Normally, every long-running process you forgot to background dies with your SSH session. But tonight, an agent you wrote is still awake: fetching a CI failure notification, generating a diff, running the test suite, and dropping a status message into a channel you can check on your phone when you wake up. No Kubernetes cluster, no always-on desktop under your desk. Just a cheap remote shell and an IRC bouncer.

The Problem with Local-First Development

Your laptop is a terrible server. It goes to sleep when you close the lid. WiFi drops when you walk to the kitchen. Battery runs out. Even if you keep it plugged in, a forced OS update will reboot it and murder your tmux sessions. If your workflow depends on a process that must survive the night (a long training run, a test suite that takes 45 minutes, a coding agent grinding through a backlog of chores), local-first development is a dead end.

The obvious fix is a cloud VM, but developers often overthink this. You don't need a managed CI platform or a container orchestrator. What you need is a persistent brain and a reliable notification bus. A remote shell and an IRC bouncer give you exactly that, with almost zero moving parts.

Remote Shells as Persistent Brains

A remote Linux shell that never sleeps is your agent's long-term home. SSH in, start a tmux or screen session, and launch whatever script you want to run indefinitely. That session will survive your SSH disconnect, your laptop closing, and your internet disappearing.

For example, I keep a tmux session named "agent" on a remote host. Inside it, a small Bash script loops forever, sleeping 15 minutes between actions. Each cycle it checks a file queue, picks up a task, and invokes a headless version of a coding agent (like the borg CLI from xShellz or any other agent you trust) to work on it. The agent runs tests, creates a branch, and commits if everything passes.

The remote shell doesn't care what time it is. No idle timeout, no display server needed. It's just a cheap Linux box with CPU and RAM. xShellz offers these shells pre-wired with SSH keys and no arbitrary session kills, so I don't have to install distros or fight with cloud console UIs. But you could get the same persistence from a $4 DigitalOcean droplet if you prefer total control.

IRC + Bouncer: The Control Layer That Doesn't Suck

Once your agent is running out of sight, you need a way to talk to it and a way it can reach you. Email gets buried. Slack and Discord require OAuth tokens, rate-limit webhooks, and break every time your team reorgs channels. IRC, paired with a bouncer, sidesteps all that.

A bouncer (I use ZNC) stays connected to an IRC server 24/7, holding your nickname in channels and logging every message you miss while offline. When you reconnect from your phone or desktop client, you get the full scrollback. This makes IRC an ideal notification pipe: your agent can post a message to a channel or send you a private notice, and you'll see it the next time you open your client, whether that's in five minutes or five hours.

Better still, IRC lets you send commands back. A simple bot listening for /msg agent run-tests project-x can trigger a remote job without ever touching a web UI. You write the bot in whatever language you like (Python with the irc library takes about 30 lines) and run it inside the same tmux session on the remote shell. Now you have a bidirectional, persistent control channel that works over any IRC network your bouncer is joined to. xShellz provides preconfigured bouncers, so I didn't have to set up a server, TLS certificates, or remember to patch ZNC. The bouncer just appears as a hostname and port ready to connect.

A Minimal Autonomous Loop

Let's make it concrete. Here is a sketch of the loop I run right now. All the heavy lifting happens inside a single tmux session on a remote shell.

#!/bin/bash
while true; do
  TASK=$(pop_task_from_queue)
  if [ -n "$TASK" ]; then
    echo "Agent working on: $TASK"
    borg run --headless --task "$TASK" > /tmp/agent-output.log 2>&1
    if [ $? -eq 0 ]; then
      echo "agent: $TASK completed successfully." | irc_client_privmsg "#team-dev"
    else
      echo "agent: $TASK failed. Log attached." | irc_client_privmsg "#team-dev"
    fi
  fi
  sleep 900   # 15 minutes
done

The pop_task_from_queue function might pull the oldest item from a simple text file. borg run is the AI coding agent executing a natural-language task, writing code, running the test suite, and returning a status. irc_client_privmsg is a thin wrapper around a netcat or Python script that sends a message to the IRC server through the bouncer's connection.

You don't need borg specifically. Claude Code, GPT-Engineer, or even a custom shell script glued to the OpenAI API can fill the same role. The key is that the agent runs inside a session that never dies, and it communicates over a protocol that doesn't care about firewalls or OAuth token expiry.

I set this up on a Saturday afternoon. Since then, that tmux session has stayed alive through two laptop OS updates, a router crash, and a power outage that took my apartment offline for four hours. The remote shell never noticed.

What You Give Up (And What You Get)

There are trade-offs. Storing API keys and git credentials on a remote host is a security risk if the host is not locked down. I keep the remote shell minimal, use SSH keys with a passphrase, and rotate secrets often. The agent also needs guardrails: a loop that runs unchecked with full commit rights could make a mess. I have it push to a non-default branch so no code hits main without human review.

Cost is another factor, but it is small. Basic remote shells start around the price of two coffees a month. I use xShellz because both the shell and bouncer are under one account and I can trust the uptime for something that runs 24/7, but you can piece these together from separate providers if you prefer.

What you get is a development loop that never stops. While you sleep, your agent can churn through a backlog of simple bug fixes, regenerate screenshots for UI tests, or warm up a long-lived build cache. You wake up to a digest in your IRC client, not a frantic Slack from a teammate.

You Don't Have to Be Always On, But Your Code Can Be

The "always-on" developer isn't a person who never sleeps; it's a workflow that stops being tethered to a laptop lid. A remote shell as the brain and an IRC bouncer as the nerve fiber give you a persistent, low-fuss agent that keeps working while you're away from the keyboard. The whole thing fits in a tmux session and a few lines of shell script. No dashboards, no cloud console fatigue.

If you've ever wanted to wake up to a diff that was ready before you even poured coffee, grab a remote shell, spin up a bouncer, and let your tools earn their keep overnight.