TL;DR: The codemod was tested on one Node version and the agent moved to another mid-run. Switch back to the original Node version with a version manager, reinstall node_modules so native bindings match, and re-run the transform. Pin the Node version for the whole migration so it cannot drift again.

```text
agent upgraded its own node from 18 to 22 mid-migration and the codemod's parser started failing on old syntax
```

1. Confirm the skew and capture the exact failure.
```
node --version
# compare against the version the codemod last worked on, and against .nvmrc / package.json engines
```
Expected: the running Node (22) differs from the tested one (18), and the parser error appeared exactly at the switch.

2. Switch back to the tested Node version.
```
nvm use 18
# or: volta pin node@18, or fnm use 18 - whichever manager the project uses
node --version
```
Expected: node --version reports 18 again.

3. Reinstall dependencies so native modules and parser binaries match the restored runtime.
```
rm -rf node_modules
npm install   # or the project's package manager and lockfile command
```
Expected: install completes without build errors, and the parser package resolves to the same version as before.

4. Re-run the codemod on a scratch copy first, then for real.
Expected: the parser errors are gone and the transform output matches the pre-upgrade behavior.

5. Pin the Node version for the migration: commit the .nvmrc or engines field, and make CI and agent sandboxes honor it.
Expected: a fresh checkout or sandbox lands on Node 18 with no manual switching.

## Use this when
- A codemod parser fails right after a Node version change
- The agent upgraded its own runtime mid-migration (18 to 22 or similar)
- Parser errors mention syntax the old Node handled fine
- node_modules was installed under a different Node than the one running

## Not for this skill when
- The parser fails identically on the original Node version - then it is a transform or parser bug, not runtime skew
- The error is a missing module rather than a parse failure - that is a dependency install problem
- You upgraded Node deliberately as part of the migration - then fix the toolchain for the new runtime instead of downgrading
- The codemod runs in a container with a fixed Node - then the skew is in the image, not the agent's shell

## Variant phrasings
- codemod parser failing after node upgrade
- node 18 to 22 jscodeshift parse error
- recast fails on old syntax after node update
- agent upgraded node mid migration, transform broke

## Why it happens
Codemod toolchains couple the parser, its native bindings, and the JS runtime tightly. Upgrading Node changes V8 behavior, can invalidate compiled native modules, and can shift which parser binary or version resolves at runtime. The transform did not change - the ground under it did. Reinstalling under the restored Node rebuilds that ground to match.

## Edge cases
- Deleting node_modules and reinstalling can resolve different transitive versions if the lockfile is not honored. Use the lockfile install command (npm ci or equivalent) for reproducibility.
- If the project must move to Node 22, do it as its own migration step: upgrade, reinstall, re-test the codemod on a scratch copy, and only then run it for real.
- Version managers only affect the current shell. Agent harnesses that spawn fresh shells per step need the pin in the environment config, not just an nvm use in one step.
- Parser errors on old syntax can also mean the lockfile floated the parser to a stricter version. If the Node downgrade does not fix it, check what changed in the lockfile.

## Provenance

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