> ## Content Index
> Fetch the complete content index at: https://rootcauseview.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Keeping coding agents running when you leave your desk
- URL: https://rootcauseview.com/keep-coding-agents-running/
- Published: 2026-08-23T12:56:27.000Z
- Updated: 2026-08-23T13:41:56.000Z
- Description: AI coding agents can work for hours, but local sessions still depend on the developer's machine. Here are practical ways to keep them running when you leave your desk.
- Author: Ian Vale
- Tags: Coding agents, AI agents, Developer tools, Claude Code, Codex

I recently came across a joke about how developers carry their laptops before and after they start using coding agents.

![](https://storage.ghost.io/c/ef/5f/ef5fad3b-7efa-4aa7-9685-eeef289c3d90/content/images/2026/08/image-5.png)

It was funny, but it also made me curious.

**Is there really no better way to do this?** So I looked into what the practical options are

## The cleanest answer is to separate the agent from the laptop

At a company level, the most obvious architecture is to give agents persistent environments that don't depend on individual developers' machines.

- Instead of: **developer → laptop → agent → repository**
- you get something closer to: **developer → managed agent environment → repository**

This is already becoming a product category. Coder, for example, introduced Coder Agents for running AI development workflows on self-hosted infrastructure, with centralized control over models, prompts, MCP servers and network-isolated workspaces.\[1\] [Coder Agents](https://coder.com/blog/introducing-coder-agents?utm%5Fsource=chatgpt.com)

That makes sense architecturally, but it isn't necessarily simple operationally.

Once an agent moves into company infrastructure, you have to think about source-code access, credentials, secrets, private networks, package registries, MCP servers, shell permissions and audit logs. The environment has to be persistent, but it also has to be controlled.

For organizations that already have remote development infrastructure, this may be the natural direction.

For teams that don't, setting up an always-on agent environment can become a much bigger security and infrastructure decision than simply letting a developer run an agent locally.

So what can you do in the meantime?

## The simplest option: keep the computer awake

For an agent that only needs another hour to finish a task, moving the entire development environment to the cloud is probably unnecessary.

Sometimes the solution really is just: **don't let the computer sleep.**

On macOS, a small utility called Agents Never Sleep was built almost exactly around this use case. It keeps the Mac running even with the lid closed.\[2\] [Agents Never Sleep](https://agentsneversleep.app/?utm%5Fsource=chatgpt.com)

What's interesting is that the application itself is quite transparent about what it does. macOS already provides the underlying power-management capability, and the site even shows the `pmset` command that can disable sleep. The app mostly makes it easier to turn that behavior on and off without having to remember the setting yourself.\[2\]

Windows has a similar solution from Microsoft. PowerToys includes an Awake utility that can keep a Windows machine awake indefinitely, for a fixed duration, or until a specified time.\[3\] [Microsoft PowerToys Awake](https://learn.microsoft.com/en-us/windows/powertoys/awake?utm%5Fsource=chatgpt.com)

There is one useful caveat: Microsoft notes that Awake does not operate while the Windows lock screen is displayed. For persistent unattended use, Microsoft recommends configuring the Windows power plan directly instead.\[3\]

Linux users may not need an extra application at all.

On systemd-based distributions, `systemd-inhibit` can execute a command while holding an inhibitor lock against sleep or idle behavior. The lock disappears when the command finishes.\[4\]

## The next problem is not sleep — it's intervention

Keeping the computer awake solves one problem, but it doesn't mean the agent will actually keep working.

It might run for twenty minutes and then stop at something like:

> Allow this command?

Now the laptop is awake. The agent is awake. But nothing is happening. This is where remote control becomes useful.

Claude Code's Remote Control, for example, lets you continue interacting with a Claude Code session running on your computer from a phone, tablet or browser.\[5\] [Claude Code Remote Control](https://code.claude.com/docs/en/remote-control?utm%5Fsource=chatgpt.com)

The important detail is that this does **not** move the agent into the cloud.

Claude continues to run on the original machine, with access to the same filesystem, MCP servers, tools and project configuration. The browser or phone is effectively another interface into that local session.\[5\]

That creates a surprisingly practical combination:

**keep the computer awake + check the agent remotely**

You can start something at your desk, leave, and still respond if the agent needs a decision or finishes earlier than expected.

Anthropic's documentation also makes the limitation clear: if the local Claude process stops, the Remote Control session ends. If the laptop sleeps, the session has to wait until the machine comes back online.\[5\]

So this solves **distance**, not **machine dependency**.

## Or remove the laptop from the execution path

The more fundamental solution is to let the coding agent run somewhere else.

Claude Code on the web runs tasks in Anthropic-managed cloud infrastructure rather than on the local computer.\[6\] [Claude Code on the web](https://code.claude.com/docs/en/claude-code-on-the-web?utm%5Fsource=chatgpt.com)

OpenAI's Codex also supports cloud tasks running in OpenAI-managed environments, separately from local CLI and IDE workflows.\[7\] [OpenAI Codex](https://openai.com/codex/?utm%5Fsource=chatgpt.com)

Google's Jules follows a similar model. It imports a GitHub repository, clones it into a cloud VM, works on the task, runs tests and prepares changes that can be turned into a pull request.\[8\] [Google Jules](https://jules.google/?utm%5Fsource=chatgpt.com)

GitHub is moving in the same direction with Copilot cloud agent and third-party coding agents. Tasks can be assigned asynchronously, worked on remotely, and returned as pull requests for review.\[9\] [GitHub coding agents](https://docs.github.com/en/copilot/concepts/agents/about-third-party-coding-agents?utm%5Fsource=chatgpt.com)

In these cases, closing the laptop stops being particularly interesting because the laptop isn't doing the work.

- The model changes from: **my computer is running an agent**
- to: **I delegated a task to an agent and will come back for the result.**

There is a trade-off, though.

Cloud environments don't automatically inherit everything available on a developer's computer. Internal services, local databases, unusual dependencies, private network resources or locally configured tools may need additional setup.

If the work is mostly self-contained inside a Git repository, this can be a good fit. But, If the agent relies heavily on a particular internal environment, moving it elsewhere can be considerably more complicated.

## You can also give the agent another computer

There is a middle ground between a personal laptop and a fully managed cloud-agent platform.

Give the agent a persistent machine of its own. That could be a Mac mini in the office, a Linux workstation, or simply a small cloud VM. The setup is not particularly new.

**laptop / phone → SSH → remote machine → agent → repository**

Developers have been using remote Linux machines, SSH and persistent terminal sessions such as `tmux` for years. What's changing is the reason for doing it. Previously, the remote machine was somewhere for **the developer** to work.

Now it can be somewhere for **the agent** to work while the developer is somewhere else. A VPS from a provider such as DigitalOcean is one straightforward way to create that persistent environment. [DigitalOcean](https://www.digitalocean.com/?utm%5Fsource=chatgpt.com). This gives you more control than a fully managed cloud agent, but it also means maintaining another development environment yourself.

## So there are really four levels of solving the problem

| What you need                                            | A practical approach               |
| -------------------------------------------------------- | ---------------------------------- |
| The agent just needs another hour                        | Prevent the computer from sleeping |
| You want to leave but may need to intervene              | Keep awake + remote control        |
| The task can run independently of your local environment | Cloud coding agent                 |
| You need a persistent custom environment                 | Dedicated machine or VM            |
| You want this across an organization                     | Managed agent infrastructure       |

**Should an agent's lifecycle depend on a developer's laptop at all?**

For now, sometimes the answer really is just changing a sleep setting.

## References

1. Coder, *Introducing Coder Agents* — Coder Agents runs AI development workflows on self-hosted infrastructure and provides centralized control over agent environments.
2. Agents Never Sleep — the product states that agents can continue running with the Mac lid closed and documents the underlying `pmset` sleep setting.
3. Microsoft Learn, *PowerToys Awake utility* — describes indefinite and timed keep-awake modes and the lock-screen limitation.
4. freedesktop.org, *systemd-inhibit* — documents inhibitor locks for sleep, idle, shutdown and lid-switch behavior.
5. Anthropic, *Continue local sessions from any device with Remote Control* — Remote Control keeps execution on the local machine while exposing the session through web and mobile interfaces.
6. Anthropic, *Use Claude Code on the web* — web tasks execute in Anthropic-managed cloud environments.
7. OpenAI, *Codex* — Codex supports cloud environments and delegated background work; OpenAI distinguishes local workflows from cloud tasks running in OpenAI-managed environments.
8. Google, *Jules* — Jules clones repositories into cloud VMs, runs tests and prepares changes for GitHub.
9. GitHub Docs, *About third-party coding agents* — GitHub coding agents can work asynchronously on tasks and create pull requests for review.