Runs, state, and recovery

lingo push submits a run to the engine and exits — or, with --wait, waits for it and writes the outputs. Either way the run lives on the server, not in your terminal — so you can close the terminal and still collect the results later, from the same checkout. This page covers how that works and how to recover when a run fails.

Run state#

Each push records the run it submitted in a per-machine file:

~/.lingo/runs/<hash>.json

The <hash> is derived from the absolute project path, so every checkout gets its own entry. The file holds the run ID, engine, and org — enough for a later lingo pull to find the outputs.

It's per-machine state, not project state — it lives in your home directory, never in the repo, and isn't committed.

Pulling later#

Because the run lives server-side, you can push, walk away, and pull when it's done:

lingo push

# later — same machine, same checkout
lingo pull

pull fetches the outputs of the most recent run for this project. It also checks the lockfile for local edits and refuses to clobber them unless you pass --force. See lingo pull.

Run state never leaves the machine, so another machine or a CI runner can't pull a run pushed somewhere else — it fails with No saved run state for this project, or pulls that machine's own last push. To get translations made in CI onto your machine, commit them in CI and git pull. See CI/CD.

Recovering a failed run#

If a run errors out partway — a timeout, a transient engine error — use:

lingo resume

resume re-emits the outputs from the engine's cached results instead of re-translating, so a recovered run doesn't spend credits again. It reports what it recovered and what couldn't be linked back.

If resume reports targets it couldn't recover, fill them in with a normal backfill:

lingo push --backfill-missing

When to use what#