Remote commands you can return to

Start a build or test on another machine. Close your client, return in another agent session, and recover the same job's status and output. Send signed messages between agents on your machines and follow each one to acceptance and pickup.

Run ordinary commands on a Linux or WSL runner from your existing agent harness. Each command gets a job ID, retained stdout and stderr, and a recorded outcome.

Run your first job → Documentation overview Use it from your agent

Aster Exec Leave a job and return to it Submit an ordinary command and get a job ID back. The runner supervises the process and keeps its status and output while your client is gone.

ax exec run --node buildbox -- /bin/hostname
ax exec ls --refresh
ax exec watch "$job_id"

AgentXchange messaging Send messages that reach the agent Signed messages move between agents on your machines, with host acceptance and agent pickup recorded separately.

ax agent setup --name assistant --workspace "$PWD"
ax send buildbox/assistant "Hello"
ax messages fetch "$message_id" --workspace "$PWD" --agent assistant

Keep control when a session ends

RecoveryReturn to the same jobRead status and retained output after a tool timeout or client disconnect. Resume at an output cursor. CancellationStop the intended workCancel a job by ID and confirm its final state. Keep other sessions’ jobs out of the cleanup. Command inputDeliver arguments and scripts intactSend executable arguments directly. Use bounded stdin for a script instead of nesting another remote shell. Agent sessionsLeave a record the next session can useFind jobs by local project, with request IDs and harness/session labels when supplied. Read structured results through the CLI or MCP.

From real agent sessions

Two leftover shells from my own waiting loop 36 hours ago are stuck because their pgrep -f matches their own command — I'll kill those, leaving the other two untouched since they belong to a different session.

— Claude Code, 23 October 2026, from an actual development session.

This is one of the repeated wait-loop and cleanup failures that led to ax. Read more excerpts from Codex and Claude Code →

Start a job and recover its output

With a configured runner and a project already on that machine, submit your ordinary build or test command.

Submit once

The receipt identifies the request, runner, target and job. The runner continues after the client stops waiting.

ax exec run --node buildbox --cwd /srv/project \
  --format json -- bash scripts/check.sh

Return later

Find the job from the same local project. Set job_id from its receipt or job list, then inspect or watch that execution.

ax exec ls --refresh
ax exec status "$job_id"
ax exec watch "$job_id"

Follow the complete walkthrough →Understand access and accounts