`claude -r` crashes immediately: `g9H is not a function` (onSessionRestored undefined)

Resolved 💬 2 comments Opened Apr 25, 2026 by st-dev0 Closed Apr 27, 2026

Summary

Running claude -r (resume) crashes immediately with g9H is not a function before the TUI renders. Starting claude normally and using /resume from inside the UI works fine.

Environment

  • Claude Code: 2.1.120
  • OS: macOS 15.6 (Darwin 24.6.0)
  • Shell: zsh

Repro

  1. cd into any project directory with prior sessions
  2. Run claude -r
  3. Crash before UI renders

Error

ERROR  g9H is not a function. (In 'g9H(K)', 'g9H' is undefined)
/$bunfs/root/src/entrypoints/cli.js:9251:5663

Stack (top frames)

- <anonymous> (cli.js:9251:5663)
- WC (cli.js:492:63749)
- pj (cli.js:492:76948)
- fT (cli.js:492:76827)
...

Likely cause

At cli.js:9251, the REPL destructures from FXK({ enabled: S, ... }):

let { onBeforeQuery: F9H, onTurnComplete: ZLH, onSessionRestored: g9H, render: aM_, ownsInput: LLH } = FXK({ enabled: S, ... })

S is hardcoded to false (useMemo(() => false, [])), so FXK runs the disabled path and returns an object without onSessionRestored. A subsequent effect calls g9H(K) unconditionally when initialMessages is present:

if (K && K.length > 0) {
  HP_(K, K8());
  hY8({ ... });
  tC8(K);
  UQ(K);
  sYH.current.current = xz_(K, g8);
  g9H(K);   // crashes here
}

This path is hit on claude -r because resume seeds initialMessages. The in-UI /resume flow goes through a different code path and is unaffected.

Workaround

Start claude without -r, then use /resume to pick the session.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗