Run cloud agent tasks on your own computers with app worker

Cloud agents are great until the work needs your machine: your GPU, your checked-out monorepo, your local database, your licensed toolchain. app worker closes that gap. Run it on any computer you own and that computer becomes a private worker for your app.nz account — it polls for your agent tasks, executes them locally with the coding engine of your choice, and reports results back through the same task trace the cloud workers use.

The workflow it unlocks is the one you actually want: fire a task from your phone, have your desktop do the coding.

The remote-control story

You're away from your desk. Open app.nz/agent on your phone, type a prompt, set the provider to Your machine, hit run. The task is created with provider: "local" and sits in a queue that only your machines can see. Back home, the app worker process you left running on your desktop leases the job within a few seconds, clones or reuses the repo, runs the engine, pushes a branch, and the PR link shows up on your phone.

Nothing about the task UI changes — same board, same steps, same diff viewer, same conversation thread. The only difference is where the compute lives and who pays for it (you already own the machine, so the answer is: nobody).

Quickstart

Two commands on any computer with the app CLI installed:

app login          # authenticate this machine against your account
app worker         # start polling for your local tasks

That's it. The worker registers itself (named after the host by default — --name my-laptop to override), heartbeats every few seconds, and shows up as a green chip in the Agent Studio composer whenever you select the Local provider. Then from any device:

app agent run --prompt "add dark mode" --repo you/site --provider local

or just use the web composer with the Your machine provider selected. If no machine of yours is online, the studio tells you exactly that and shows the command to fix it.

Leasing is user-scoped, on purpose

The obvious question about running other people's prompts on your hardware is: whose prompts? The answer is strictly yours, enforced server-side:

• API-key auth, not a fleet token. Your worker authenticates every call with your own API key — the same credential app login stores. The shared fleet uses a separate join token and its workers never lease provider=local jobs, so a task aimed at your machine cannot leak to the fleet.
• Per-user queue. The lease endpoint only hands your worker jobs whose user_id matches your account. Another user's local worker polling the same endpoint sees nothing of yours, and vice versa. Worker ids are ownership-checked on every heartbeat, lease, and credential call, so a spoofed worker id gets an empty queue.
• Credential redaction. Job payloads and step logs pass through the same secret-redaction layer the CI builds use — model keys and tokens are scrubbed before anything is stored or displayed.
• Engine allowlist. The worker only executes engines from a fixed allowlist; a task can't instruct your machine to run an arbitrary binary as its "engine".

By default a local worker only takes provider=local jobs. If you want your idle desktop to also chew through your normal cloud-queued tasks, opt in with app worker --any-provider — it still only ever sees your own jobs.

The engine lineup

app worker executes tasks with whichever local coding agents you have installed, selected per task or constrained with --engines:

• codex (our fork) — the default. Our fork of Codex with the app.nz gateway wired in; if the fork isn't installed or fails to start, the worker automatically falls back to mainline codex, so a task never dies because of a missing patch set.
• claude — Claude Code, for tasks that want its long-horizon editing.
• cursor-agent — the Cursor CLI agent.
• gemini — Gemini CLI.
• grok — Grok CLI.

The worker probes what's on your PATH at startup and advertises only the engines it can actually run. Model routing still goes through the gateway, so a local run can use any model in the catalog — metered against the same account, with the same spend caps.

A worked example: a kids' game on the desktop

A real run from this week: building a small game for the edukids repo, fired from a phone, executed on a home desktop.

# on the desktop, once
app login
app worker --dir ~/agent-work --engines codex,claude

# from the phone (or the /agent composer)
app agent run \
  --prompt "Build a times-tables asteroid game: answers shoot the right asteroid. Kid-friendly, big buttons, works on tablets." \
  --repo lee101/edukids \
  --provider local \
  --model gpt-5.6-sol

The desktop leased the job in ~4 seconds, cloned lee101/edukids into ~/agent-work, and ran the codex fork with gpt-5.6-sol. Eleven minutes later: a branch with a playable asteroid-tables game, tests for the scoring logic, and a PR — reviewed and merged from the couch. The task trace on app.nz shows every step the local engine took, same as a cloud run.

Keeping an eye on it

app worker status

shows the machines registered to your account, whether each is online, and how many jobs it's running — the CLI view of the same data as the green chips in the studio. Useful flags for day-to-day use:

app worker --once        # lease at most one job, run it, exit (great for cron)
app worker --dry-run     # show what would be leased without executing
app worker --poll 5s     # poll interval
app worker --lease 2     # run up to 2 jobs concurrently

Where this fits

Cloud workers are still the right default — parallel, sandboxed, always on. Local workers are for the cases the cloud can't reach: private networks, big local checkouts, GPUs you already paid for, and the plain convenience of "my desktop is faster than a shared box." Now both are the same product: one task API, one trace, and a provider dropdown that includes the computers you own.