Resume crashes with "g9H is not a function" — REPL onSessionRestored undefined in 2.1.120

Summary

On 2.1.120, opening a prior session interactively via claude -r <session-id> (or --resume) crashes on mount with:

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

Print mode (claude -p --resume <id> "…") works fine against the same session file, so the session data is healthy — the bug is purely in the interactive REPL mount path.

Environment

• Claude Code 2.1.120 (installed at ~/.local/share/claude/versions/2.1.120)
• macOS (Darwin 25.3.0)
• Session was written progressively by 2.1.108 → 2.1.112 → 2.1.113; crash appears only after upgrading to 2.1.120

Repro

claude -r <any-session-id-with-messages>
# also:
claude --dangerously-skip-permissions -r <same-id>

Reproduces with and without --channels plugin flags, so plugins are not the trigger.

Diagnosis from the minified bundle

Inside the REPL component Ub8, which receives initialMessages as K:

let S = s_.useMemo(() => !1, []);        // hardcoded false
let { onBeforeQuery: F9H,
      onTurnComplete: ZLH,
      onSessionRestored: g9H,            // <- undefined
      render: aM_,
      ownsInput: LLH }
    = FXK({ enabled: S, setMessages: F7, ... });

s_.useEffect(() => {
  if (K && K.length > 0) {
    HP_(K, K8()),
    hY8({ abortController: new AbortController, taskRegistry: YH }),
    tC8(K), UQ(K),
    sYH.current.current = xz_(K, g8),
    g9H(K);                              // <- TypeError here
  }
}, []);

FXK({enabled: false, ...}) returns an object that does not include onSessionRestored; destructuring yields undefined; the mount effect invokes it unconditionally whenever the resumed session has any messages. Appears to fire on every interactive resume of a non-empty session.

Workaround

claude -p --resume <id> "…" works — print mode does not mount the REPL, so the broken effect never runs.

Suggested fix

Either:

• FXK's enabled: false branch should return a no-op onSessionRestored, or
• The mount effect should guard the call: g9H?.(K).

Adjacent issue (lower priority)

If g9H is bypassed (e.g. by truncating the session so initialMessages is empty), a different mount effect fires and prints:

Error: sandbox required but unavailable: <reason>
  + sandbox.failIfUnavailable is set — refusing to start without a working sandbox.

sandbox.failIfUnavailable is not set in any of my settings files (user, user-local, project, project-local). It looks like --dangerously-skip-permissions implicitly sets isSandboxRequired() to true. That may be intentional defense-in-depth, but the error message blames a user setting that the user didn't set, which is misleading.