lingo push submits a run to the engine and waits for it. But the run lives on the server, not in your terminal — so you can close the terminal, switch machines, or let CI take over, and still collect the results. 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>.jsonThe <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 on another machine#
Because the run lives server-side, you can push from one place and pull from another:
# laptop
lingo push
# CI, or a second machine with the same checkout + credentials
lingo pullpull 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.
Moving the project
The run-state filename is keyed on the absolute project path. If you move the directory between push and pull, the lookup misses — the run ID is still in ~/.lingo/runs/ if you need to recover it by hand.
Recovering a failed run#
If a run errors out partway — a timeout, a transient engine error — use:
lingo resumeresume 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-missingWhen to use what#
| Situation | Command |
|---|---|
| Collect results after closing the terminal | lingo pull |
| Push on a laptop, pull in CI | lingo push then lingo pull |
| A run failed midway | lingo resume |
| Resume left gaps | lingo push --backfill-missing |
