Why use ax?

Remote work often outlives the tool call or agent session that started it. A build can keep running after a disconnect, while the next session has only a shell command, a PID search and part of a log to reconstruct what happened.

ax gives that work a job ID. The runner supervises the command, records its outcome and retains output. You can return to the same job, read what it produced, and stop it deliberately.

Stop the intended job

The combined remote command was killed by the broad pkill pattern matching the shell command itself.

— OpenAI Codex, 14 June 2026.

Months later, another session reported a related failure:

I found ten wait loops left by finished agents, spinning since the morning. Each was waiting on a pgrep -f that matched the loops' own command lines, so they could never exit.

— Claude Code, 24 October 2026.

With ax, observation and cancellation use the job ID returned at submission. Watching requires no process-name loop, and cancellation addresses the supervised job. Check its terminal state after requesting cancellation.

ax exec watch "$job_id"
ax exec cancel "$job_id"
ax exec status "$job_id"

Return after a connection drops

SSH has just timed out, so I’m checking connectivity before assigning agents.

— OpenAI Codex, 23 October 2026, during remote container-image preparation.

A connection failure and a process failure are different events. An accepted ax job remains owned by the runner when its client disconnects. Reconnect, find it with ax exec ls --refresh, and query its status or resume output. If the runner is unreachable, reconnect later to establish the outcome.

A lost submission reply needs the same care. The CLI saves the request before sending it. Recover or retry that exact request within its retry window; a fresh request ID represents new work. Jobs and results explains this recovery path.

Carry work into the next agent session

Your project's local job list includes the original command, remote working directory, request and job IDs, and recorded status. Harness and session labels appear when supplied. The next session using that client identity can inspect those records rather than infer ownership from a process name.

Agent integration shows how to supply attribution and retain the structured submission receipt. JSON, CSV and TSV let a harness read the result directly.

Recover the log and the outcome

The runner retains stdout and stderr separately from the agent tool's displayed output. Read a bounded page, keep its next cursor, and continue from there. A shortened tool display does not require rerunning the command to get its output. Runner output limits and retention still apply.

Status reports the recorded lifecycle state and, when observed, an exit code or signal. A quiet command can still be running; silence alone does not establish that it is stuck. A requested execution deadline is separate from how long your client waits.

Keep ordinary commands and arguments

ax starts the executable and argument array you supply, without an implicit remote shell. Paths and arguments pass as separate values. When shell syntax is needed, select the interpreter explicitly. Scripts still follow that interpreter's syntax.

The runner uses its existing tools and the selected account's access. The local broker keeps authenticated connections warm between CLI calls. SSH provides the initial installation path.

Try the complete workflow

Your first remote job walks through deployment, submission, disconnection and recovery on Linux/systemd. Jobs can survive client disconnect and API restart on that backend; a host reboot does not preserve a running process. Where jobs run explains these boundaries.

The quoted excerpts are from real Codex and Claude Code development sessions, reproduced with the owner's permission.