Summary

After an OpenClaw auto-update, the running gateway process can continue using cached modules that reference old hashed bundle filenames. New files are present on disk, but the old in-memory module graph still tries to import filenames that were removed by the update.

Observed

• OpenClaw version after update: 2026.5.20.
• The Codex plugin package on disk contained the new run-attempt chunk, while existing scheduled turns failed with:
  • Cannot find module './run-attempt-<old-hash>.js'
  • require/import stack rooted in the Codex harness bundle.
• A gateway restart loaded the new harness and resolved the failures.
• A similar stale-hash import warning appeared during shutdown for another internal maintenance chunk, also resolved by the restarted process loading the updated bundle graph.

Expected

Auto-update should not leave a live gateway process with cached modules that reference removed hashed chunks. Possible fixes:

• Restart/reexec the gateway after updating code chunks.
• Keep previous hashed chunks until the old process exits.
• Avoid dynamic imports that point at content-hashed filenames from long-lived cached modules without compatibility shims.
• Add an update integrity check that verifies all dynamic import targets referenced by loaded entrypoints exist before continuing.

Local mitigation

A compatibility shim was added for the missing Codex run-attempt chunk name, then the gateway was restarted so the process loaded the updated module graph. A smoke Codex run and a lightweight affected cron completed successfully afterward.