Your Coding Agents Now Live on Someone Else's Computer: Persistent Sessions, Real Risks

On September 15, 2026, TermSquad launched an always-on cloud computer for AI coding agents. Per its announcement, it puts three things into one Linux environment: persistent sessions, shared project memory, and multi-agent orchestration. You can close your laptop, let the agents keep working, and reconnect from a desktop browser, a phone, or a compatible SSH tool. Repositories, files, and configuration stay in the remote environment rather than depending on a local device. TermSquad supplies the computer; you choose the agents and models. The direction is sound, because coding agents increasingly look like long-running workloads rather than one-shot command lines. It also drags an old question into the open: your code, your credentials, and your environment now live on a machine that never sleeps.

1. What It Offers: Moving the Dev Environment Off-Device

The pitch compresses to one sentence: sessions no longer live and die with your device. Reconnect from a phone or another laptop and the agent that was running is still in the same directory, still holding the same context. Shared project memory means multiple agents do not rebuild their understanding from scratch, and orchestration lets them collaborate on one box. For people who want to keep pushing work forward from a different device, the pain point is real. But notice the technical consequence: once a session is decoupled from a device, your dev environment becomes a server you operate. It needs authentication, a firewall, resource limits, and a machine that behaves itself while you are not watching.

# A persistent box is a server. Treat it like one from minute one.
sudo apt-get install -y openssh-server tmux
# Key-only auth, no passwords, no root login.
sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/'            /etc/ssh/sshd_config
sudo systemctl restart ssh

# Then firewall to your known hosts only - the agent host is public by default.
sudo ufw default deny incoming
sudo ufw allow from YOUR_OFFICE_IP to any port 22
sudo ufw enable

A box that never sleeps is an attack surface that never sleeps

2. Persistence Turns a Process Into a Server

Run an agent locally and closing the lid mostly stops it. Run it on an always-on host and it is a service. That difference means three things. First, authentication has to be upgraded: key-only SSH, no direct root login, and a port open only to trusted sources, because a publicly reachable dev box is a scanning target by default. Second, resources need ceilings: a runaway loop that drains your laptop battery will, in the cloud, hold CPU and memory indefinitely and can starve the other agents on the box. Third, cost accrues continuously: the agent keeps working while you sleep and tokens keep burning, so a meter that only runs when you are watching will never show you the real bill.

# Three agents, one repository: give each its own worktree and branch,
# so a refactor in one cannot rewrite files another is still reading.
git worktree add ../wt-refactor -b agent/refactor
git worktree add ../wt-tests    -b agent/tests
git worktree add ../wt-docs     -b agent/docs

# Each agent runs in its own directory while sharing one object store,
# and you merge branches the way you always do. No shared mutable state.

3. Many Agents, One Box: Isolate Before You Orchestrate

Put several agents on one machine and the most overlooked risk is file-level collision. Two agents editing the same repository, one refactoring while another reads, will eventually produce a read of a file that was rewritten mid-flight. Git worktrees are the cheapest fix: give each agent its own worktree and its own branch over a shared object store, and merge branches as usual. That converts shared mutable state into separate branches, pushing the cost of parallelism to the merge instead of into runtime chaos. Only after isolation does shared memory and agent collaboration make sense; collaboration presupposes that the parties do not corrupt each other's work.

# Do NOT bake tokens into the image or clone a .env onto the box.
# Inject per session, keep it out of shell history, and let it expire.
export ANTHROPIC_API_KEY="$(pass show agents/anthropic)"
tmux new-session -d -s refactor -c ~/wt-refactor \
  "ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY claude"

# A long-lived cloud box is a long-lived credential. Rotate on a schedule,
# and prefer short-lived tokens over keys that outlive the task.

Do not bake secrets into the image; inject them per session

4. Credentials: Inject Them, Do Not Bake Them In

The classic mistake on an always-on box is convenience: writing an API key into an image, or copying your local .env up with everything else. Both amount to leaving long-lived credentials permanently on a machine that is online around the clock. Three better habits: inject secrets per session instead of baking them into an image; keep injection out of shell history and logs; and prefer short-lived tokens over keys that never expire. Rotate on a schedule too, because a long-lived dev box is a long-lived credential. Manage it as a production server, not as disposable sandbox.

# Cap each agent's CPU, memory and IO so one runaway loop cannot take the box.
sudo systemd-run --unit=agent-refactor \
  --property=CPUQuota=200% \
  --property=MemoryMax=4G \
  --property=IOWeight=50 \
  --working-directory=/home/dev/wt-refactor \
  /usr/bin/tmux new-session -d -s refactor

# Cap the network the agent may reach, not just the CPU it may use.
# An agent that can POST your repo to any host will eventually do so.

5. In Practice: From sshd to Per-Agent Metering

The first snippet hardens the box like a server: key-only auth, no root login, a firewall scoped to trusted sources. The second uses git worktrees to give each agent its own tree and branch, so agents do not step on each other. The third shows per-session secret injection and insists on rotation and short-lived tokens. The fourth uses systemd-run to cap CPU, memory, and IO per agent, with the reminder that egress needs a ceiling too. The fifth is a per-agent session cost table, because the point of an always-on environment is that work continues while you are away, so the meter must keep running while you are away.

// Persistent sessions accrue cost in the background. Meter them on a timer.
type SessionTick = {
  session: string;
  agent: string;
  tokens: number;
  usd: number;
  ts: string;
};

export function tick(s: SessionTick) {
  db.sessions.insert(s);
}
// Report per-agent spend per day. The whole point of an always-on box
// is that work continues - so your meter has to run while you sleep too.

Isolate first, orchestrate second

6. A Checklist: Operate the Box Like a Service

Five checks. First, is the machine key-only, root-login-disabled, and firewalled to trusted sources? Second, does every agent have its own worktree and branch rather than sharing one mutable checkout? Third, are credentials injected per session, or permanently baked into an image and disk? Fourth, are CPU, memory, IO, and egress all capped? Fifth, do you have metering and alerting that runs while you are not looking at the screen? The appeal of an always-on cloud computer is that you do not have to be present. Its risk is precisely that you are not present. Read that sentence backwards and you have the checklist.