Agentic Development Environments

A coding agent does its best work unattended: it runs the tests, reads the output, and keeps going after you close the laptop. That changes what the machine under it has to be. The AISL material gives this its own workshop, Setting Up a Remote Environment for Agentic Workloads, and the same lessons resurface wherever the material runs long-lived AI work on remote hosts.

Why agents want a different machine

An SSH connection is temporary. An agent task is not: the process should keep running while the laptop sleeps, the network switches, or you move between devices. The workshop's premise is a remote development box that gives agents a stable place to run while you disconnect, reconnect, or change devices. Repository, Git credentials, and agent share one home, so nothing splits between machines. The security boundary has three layers, each owned by a different component:

• the provider controls access to the server
• SSH controls login
• the host firewall controls network services

The base box

The base box is an Ubuntu host on AWS in the workshop, and the same setup works on any Ubuntu host reachable over SSH. Lock it down in the order you would repeat: tighten SSH access, install the runtimes and tools the agents need, and keep application ports closed. Development services bind to loopback and get reached through SSH port forwarding, so a database or a dev server never needs a public port. If a port must be public, it is opened deliberately, with the provider security group and the host firewall reviewed together.

Sessions that survive you

The persistence layer is tmux: a detached session keeps its processes running after you disconnect, and reconnecting brings back the shell, the agent, and its output. The workshop drives it through tmuxctl, which adds two things plain tmux lacks. Each project session runs in its own systemd scope with memory limits. One busy agent therefore cannot starve unrelated sessions: the kernel stops the process inside one scope instead of taking down the tmux server. The isolation doubles as a workflow: one session per project or independent task, with tmuxctl list and tmuxctl doctor to see what is running and how healthy it is.

Agents on the box, with boundaries

With the environment in place, the agents themselves — Codex, Claude Code, OpenCode, Grok Build — install like any other tool and live in the persistent sessions. The operational lessons are about autonomy, not installation:

• Aliases stay readable (c, cx, oc), so the command you run says what it starts.
• High-autonomy flags — Codex's bypass of approvals and sandboxing — are deliberate exceptions with their own alias, used inside boundaries you control, never the default.
• Each task starts bounded: look at the repository, report a plan, and wait for approval before changing files.
• Persistent sessions do not stop two agents from editing the same working tree; concurrent agents need a merge plan.

Reaching it from anywhere

One SSH alias in ~/.ssh/config becomes the interface every tool shares: the terminal, and VS Code Remote SSH, which runs the editor's server components on the box. PocketShell imports the host through a QR code — treated like a private key, generated only in private — and turns voice dictation into prompts inside the same tmux sessions. For a changing set of development ports, ssh-auto-forward discovers listening services and tunnels them locally while the public ports stay closed.

That is what makes the environment location-independent. Shipping Features From My Phone is the payoff demonstrated: a voice-dictated issue, an agent implementation, a review from a tram stop, and a merged PR — because the feedback loop (issue, agent, CI/CD) runs without a laptop in it. The workflow layer that runs inside such environments — custom slash commands, stop hooks, a persistent coding loop — is the subject of Experiments with Claude Code. Jev for LLM Evaluations shows the same dictation loop applied to real code: most of its judge implementation was dictated to an AI assistant as prompts, and the workshop includes those prompts, so the workflow reproduces with any agent.

Operations lessons from other remote boxes

The remote-environment workshop points to an earlier example of the same setup: Serving Open Models with vLLM on RunPod, which rents a GPU by the hour and runs an inference server on it. Its failure list is the standard remote-host experience: a model that does not fit the card, a full container disk, an SSH session that keeps dropping. Each failure comes with a fix to keep before you meet it on your own box.

Where to go next

• The agents that run in these environments: Building Coding Agents
• The tool landscape and daily workflow: AI Coding Tools
• Deploying what the agents build: Agent Deployment