codemod agent lost its progress file when the sandbox was recycled - how to resume a 400-file transform without...

TL;DR: Rebuild the remaining file list from git instead of from memory. Every file the transform already touched shows up as modified, so the untouched files are simply the full target list minus the modified ones. Re-run the transform on the untouched files only, then prove the resume worked with a dry run that reports zero changes.

The problem as reported:

codemod agent lost its progress file when the sandbox was recycled - how to resume a 400-file transform without redoing everything

1. List what the transform already changed: git diff --name-only | sort | tee converted.txt. Expected: a list of files, roughly the number the agent converted before dying.
2. Rebuild the full target list the same way the original run did, e.g. find src -name '*.ts' -o -name '*.tsx' | sort | tee all.txt. Expected: every file the transform was supposed to touch, around 400.
3. Subtract to get the remainder: comm -23 all.txt converted.txt | tee remaining.txt. Expected: only files with no transform output yet. Sanity check: wc -l remaining.txt plus wc -l converted.txt should roughly equal wc -l all.txt.
4. Re-run the transform on the remainder only: cat remaining.txt | xargs jscodeshift -t transforms/rename.js. Expected: the transform reports changes only in those files, and git diff --name-only now covers the full target list.
5. Verify nothing was missed or double-applied: run the project's test suite, and grep the target list for the old pattern. Expected: zero matches for the old pattern, tests pass.
6. Prevent a repeat: commit after each batch (every 50-100 files) and write the progress file inside the repo or to a durable artifact store, never to /tmp. Expected: a recycled sandbox loses at most one batch of work.

Use this when

• A codemod or jscodeshift transform died partway (timeout, out of memory, crash) and you need to resume.
• The sandbox or container was recycled and the progress file is gone.
• Files are under version control so git can tell converted from unconverted.

Not for this skill when

• The repo isn't in git and there's no other record of what changed - restore from backup first.
• The transform is nondeterministic - fix that before resuming, or the "remaining" run will produce different output than the first run.
• You're resuming a database migration, not a file transform - different state tracking applies.

Variant phrasings

• resume codemod after crash without redoing files
• jscodeshift died halfway how to continue
• codemod sandbox recycled lost progress
• re-run transform only on unconverted files

Why it happens

The agent kept its progress in memory or in an ephemeral file, and the sandbox recycle wiped it. But the transform's real output - the modified files - is durable in git. The modified set IS the progress record; the remaining work is just the set difference.

Edge cases

• Someone edited files after the crash: git diff mixes transform output with human edits - review the diff before resuming.
• Partial writes: a file the transform was mid-write on when it died may be syntactically broken - run the parser or linter over converted files first.
• The original file list can't be reconstructed: fall back to the transform's own predicate - a file is "done" when running the transform on it is a no-op.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_rFEXN8BgBCHnmrmodikLtg