How to Keep Codex Running After You Close Your Laptop

Published August 13, 2026 · by the AQ team

Closing your laptop kills a Codex CLI session that is running on the laptop itself, and codex resume does not undo that: it reopens the saved conversation, not the interrupted work. To keep a Codex task executing while the lid is shut you have to run it somewhere that never sleeps. There are two practical shapes: keep an interactive session alive on a remote machine with tmux (or a product built on that pattern), or hand the task to Codex cloud, OpenAI's managed sandbox that runs it for you and returns a diff or pull request. Which one fits depends on whether you want a live terminal to step back into, or a finished result to review.

Why closing the lid kills the session

When you run codex in a local terminal and the laptop sleeps, the process loses its controlling terminal and is stopped or killed with everything else attached to that shell. The same applies if you SSH into a server and run codex directly in that connection: a dropped Wi-Fi handoff, a VPN reset, or a suspend takes the SSH session down, and the default SIGHUP handling terminates whatever it was running. None of this is specific to Codex; it is how terminals treat any long-running CLI.

Codex softens the blow more than most CLIs because every session is saved locally as you go. But saved is not the same as running, which is worth being precise about before picking a fix.

What codex resume actually restores (and what it does not)

As of August 2026, Codex CLI records each session on disk, and you can get a conversation back three ways: codex resume opens a picker of recent sessions from the current repository, codex resume --last jumps straight into the most recent one, and the /resume slash command does the same from inside a running session. Resuming reloads the transcript so the model regains the full context of what you were doing, and /fork lets you branch a new chat off an old one without touching the original.

What resume cannot do is finish work that was interrupted. If Codex was halfway through a refactor when the laptop slept, the process died at that point; resuming lets you tell it to continue, but the hours in between were spent, not worked. Resume is recovery, not persistence. For persistence, the process has to outlive your laptop, which is what the next options are for.

Option 1: A remote box with tmux

The baseline pattern needs no product at all: a Linux server you can SSH into, plus tmux. tmux keeps the session running on the server whether or not any client is attached, so closing your laptop only kills the SSH client; the Codex process inside keeps executing.

# On the remote server, once:
ssh dev-box

# Start a named session and run Codex inside it
tmux new -s auth-fix
codex

# Detach: Ctrl-b then d. Close your laptop, go anywhere.
# Later, from any machine:
ssh dev-box
tmux attach -t auth-fix

Reattaching drops you into the exact same scrollback, mid-conversation, with the agent still working or waiting for input. This costs only the VM and works identically for Codex, Claude Code, or a plain shell. If you are building the box from scratch, the self-hosted AI coding agent setup guide covers VM sizing, hardening, and headless CLI auth in order.

The limits arrive with teammates and scale: sharing a session means sharing SSH access, two tasks in one checkout trample each other unless you split them into git worktrees, and nobody sees what an agent is doing without SSHing in themselves.

Option 2: Add mosh for connections that actually drop

tmux solves persistence on the server; it does not make your connection to the server any better. If you work from trains or a laptop that changes networks all day, add mosh: it replaces the SSH connection layer with a UDP protocol that survives IP changes and long suspends, reconnecting the moment your machine wakes instead of forcing a fresh login. Run mosh to connect, tmux inside it, and you have both halves. The one constraint is that mosh needs UDP through the firewall; fall back to plain SSH where it is blocked.

Option 3: Delegate the task to Codex cloud

If what you want is not a terminal to reattach to but a result, Codex has a first-party answer. As of August 2026, Codex cloud runs tasks in isolated, OpenAI-managed containers preloaded with your repository: you delegate a task from the CLI, the web app, the IDE extension, or integrations like Slack and GitHub, and it executes on OpenAI's infrastructure regardless of what your laptop does. The sandbox uses a two-phase model (a setup phase with network access installs your dependencies, then the agent phase runs with internet off by default), environments are configurable per repository, and container state is cached for up to 12 hours to speed follow-ups.

Results come back as reviewable work rather than a live session: Codex can open a pull request on GitHub, or you can pull the change down locally with codex apply <task-id>, and browse or manage cloud tasks from the terminal with codex cloud. Cloud tasks are included in ChatGPT plans, with usage limits that share a five-hour rolling window with local Codex messages, so heavy delegation draws from the same budget as interactive work.

The tradeoff is interactivity. A cloud task is fire-and-forget: you write the task, it runs to completion, and you review what comes back. There is no standing terminal to step into mid-run, and the sandbox is OpenAI's infrastructure, not a machine inside your network with your staging database and private registries reachable.

Option 4: codex exec for scripted, unattended runs

For automation on infrastructure you already own, Codex CLI has a non-interactive mode: codex exec "<task>" runs a task without the interactive UI, streams progress to stderr, and prints the final message to stdout, which fits CI jobs, scheduled runs, and shell pipelines. Run it on a server and laptop lifetime stops being relevant because your laptop was never involved. It is the right shape for recurring jobs like nightly triage; it is the wrong shape for exploratory work you want to steer.

The options at a glance

Which one to actually use

One person, well-defined tasks, happy to review diffs: Codex cloud is the least setup. One person who wants the actual session back the way it was left: tmux on a small VM, with mosh if your network is unreliable. Recurring unattended jobs: codex exec under CI. The gap opens when a team wants the tmux pattern, real reattachable terminals that survive everything, without sharing SSH keys to one box. The same fork exists on the Claude side, covered in keeping Claude Code running after closing your laptop.

Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. In this guide's terms, AQ is Option 1 turned into a team product. Codex runs as the real CLI (alongside Claude Code, Cursor Agent, Kimi, Grok, or plain shells) in a persistent tmux session on your team's VM, so the session survives a closed laptop and resumes from any device, streamed live to the browser where a teammate can open the same workspace and watch the same session; if the owner approves a control request, the teammate can type into it too.

Each workspace gets its own isolated git worktree so parallel sessions never collide, you log into Codex with your own OpenAI account (AQ never marks up model usage), and commits and pull requests go out under per-user GitHub auth, tracked against the workspace. There is no shared multi-tenant execution tier: your agents run on your team's machine, with runner health visible in the product and an aq-runner doctor command for diagnosing a broken host. The Free plan is a personal sandbox for one person, created by AQ on a private machine in an isolated network with nothing to install and no time limit. The Team plan ($50 per user per month early access, standard $200, billed monthly) covers VMs you connect from your own cloud or a dedicated always-on AQ-managed VM in its own isolated network, with the rate locked for your first 12 months.

Plainly: if you are one engineer, Codex cloud or tmux on a box you already have is enough, and you should use it. AQ earns its place when a team wants those persistent sessions shared and visible from a browser without anyone owning the SSH keys.