2.1.120 regression: claude --resume / --continue crash with "g9H is not a function"

Status Closed — duplicate

Reported on v2.1.119

Maintainer reply ✓ Yes — claude[bot]

Activity 11 comments · opened Apr 25, 2026 · closed Apr 27, 2026

💡 Likely answer: A maintainer (claude[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

claude --resume <session-id> and claude --continue crash immediately on 2.1.120 with a JS runtime error. The interactive workaround (claude --new, then /resume <session-id> from the REPL) works fine. Both --resume and --continue worked correctly on 2.1.119.

Repro steps

Have at least one prior session in ~/.claude/projects/.
From a shell: claude --resume <session-id>
Observe the crash. claude --continue crashes the same way.

Error output

ERROR  g9H is not a function. (In 'g9H(K)', 'g9H' is undefined)

/$bunfs/root/src/entrypoints/cli.js:9251:5663

(Full stack trace shows repeated calls through pj / fT callbacks in line 492 before reaching the crash site at line 9251.)

Environment

Platform: macOS (arm64)
Install method: native auto-updater (~/.local/share/claude/versions/)
Version that broke: 2.1.120 (auto-installed 2026-04-24)
Last working version: 2.1.119 (confirmed working after rolling back)
Shell: fish (via zsh login shell), also zsh and bash

Version timeline

| Version | Installed | Status |
|---|---|---|
| 2.1.118 | 2026-04-22 | Working |
| 2.1.119 | 2026-04-23 | Working |
| 2.1.120 | 2026-04-24 15:53 | Broken |

Workaround

Either:

Roll back the symlink: ln -sfn ~/.local/share/claude/versions/2.1.119 ~/.local/bin/claude
Or use claude --new and then type /resume <session-id> from inside the REPL (this takes a different code path that doesn't hit the bug)

Analysis (from reading obfuscated source — not verified against real source)

The REPL component at cli.js:9251 destructures an onSessionRestored callback from a hook that appears to be gated by a feature flag:

let { onSessionRestored: g9H, ... } = FXK({ enabled: S, ... })
// S = useMemo(() => false, [])  — always false

When enabled is false, the hook returns no onSessionRestored, so g9H is undefined. A useEffect on REPL mount then calls g9H(K) unconditionally when K (the initial messages array) is non-empty:

useEffect(() => {
  if (K && K.length > 0) {
    ..., g9H(K)   // 💥 crashes when undefined
  }
}, [])

The two paths diverge because:

claude --resume / --continue → REPL mounts with K = [prior session messages] → effect fires → crash
claude --new → REPL mounts with K = [] → effect is skipped → /resume uses a different internal function that doesn't reference g9H

The fix would be g9H?.(K) instead of g9H(K), or ensuring the hook always returns a safe no-op for onSessionRestored even when disabled.

View original on GitHub ↗

11 Comments

github-actions[bot] · 4 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

PopFlamingo · 4 months ago

Same here this seems to be a very recent regression, it has first happened to me around 30 minutes ago.

 ERROR  g9H is not a function. (In 'g9H(K)', 'g9H' is undefined)

Also at the end of the error message:

Error: sandbox required but unavailable: ${f_}
 9253: `+`  sandbox.failIfUnavailable is set \u2014 refusing to start without a working sandbox.
 9254:

coloradodba · 4 months ago

this occurs on Fedora 43 as well

mrbarbosa · 4 months ago

Mac OS reporting in. So much for off peak usage.

 9252: Error: sandbox required but unavailable: ${f_}n;if(y8.isSandboxRequired()){process.stderr.write(`
 9253: `+`  sandbox.failIfUnavailable is set \u2014 refusing to start without a working sandbox.
 9254:

 - <anonymous> (/$bunfs/root/src/entrypoints/cli.js:9251:5663)
 - WC (/$bunfs/root/src/entrypoints/cli.js:492:63749)

RaiAnsar · 4 months ago

Adding a bit of disassembly in case it helps narrow it down.

Repro env: macOS 25.4.0 (arm64), VS Code integrated terminal, command claude --dangerously-skip-permissions -c in a project with an existing session JSONL. Crashes immediately on REPL mount with the same g9H is not a function trace shown above.

Symbol diff between 2.1.119 (good) and 2.1.120 (bad) in the bundled cli.js:

| Source | 2.1.119 | 2.1.120 |
|---|---|---|
| useScheduledTasks | function tR3({isLoading,...}) | function XL3({isLoading,...}) |
| loop-helpers namespace | sR3=(puH(),I8(muH)) | PL3=(LmH(),E8(ZmH)) |
| call site | sR3.resolveLoopDefaultFire(w) | PL3.resolveLoopDefaultFire(w) |

Both versions structure the hook the same way — PL3 is assigned only inside the lazy module init wrapper:

var QD6, PL3, YkK=null;
var jkK=Z(()=>{ ...; Bb8(); ...; PL3=(LmH(),E8(ZmH)) });
function XL3({isLoading:H, assistantMode:_, setMessages:q}){
  ...
  useEffect(()=>{
    if(!LR()||C8()) return;
    let A=(w)=>yT({value: PL3.resolveLoopDefaultFire(w), mode:"prompt", ...});
    ...
  }, [_, q, O.getState, $]);
}

The g9H is not a function error indicates g9H itself (not a property of it) is undefined. Most plausible read: the 2.1.120 bundler/minifier hoisted PL3.resolveLoopDefaultFire into a top-level destructured/aliased reference (g9H) that was resolved before jkK() ran to populate PL3. With --resume/-c, the chat REPL mounts before any path that would have forced jkK, so the hoisted alias stays undefined and the effect throws on first call. A non-resume start tends to mount more setup screens first, which is probably why interactive /resume sometimes works (per #53064).

Workaround for anyone stuck right now: if your auto-updater hasn't deleted the previous version, the 2.1.119 binary is still on disk at ~/.local/share/claude/versions/2.1.119 and works fine — invoke it directly, or repoint ~/.local/bin/claude at it until 2.1.121.

richardrl · 4 months ago

same issue with ubuntu. UGH!

yurukusa · 4 months ago

Confirming the regression on macOS / native installer / v2.1.120. Same crash signature, same code path you traced.

Quickest path back to working — roll the symlink to v2.1.119:

ln -sfn ~/.local/share/claude/versions/2.1.119 ~/.local/bin/claude

Interactive workaround that does not require the rollback — open a fresh session and use the REPL /resume:

claude --new
# then in REPL:
/resume <session-id>

REPL mounts with empty initialMessages, which means the useEffect that fires g9H(K) when K.length > 0 is skipped on mount. Matches your onSessionRestored analysis: the disabled-hook returns no callback and the assignment lands as undefined, but the effect that calls it never runs in the --new path.

v2.1.121 status: a partial fix appears to have shipped for the cluster (some related issues are closed against it). For this exact crash signature on --resume / --continue, downgrading to 2.1.119 or using the claude --new + /resume interactive path remain the most reliable workarounds until a fix is confirmed for this specific issue in a changelog entry.

The deeper fix you describe — g9H?.(K) instead of g9H(K), or making the disabled hook return a no-op onSessionRestored — is the one I would want shipped. The latter is more defensive: it keeps the call site uniform regardless of the feature flag state.

Thanks for the binary-level analysis, the hook trace makes the workaround derivable.

yaodansheng · 4 months ago

same issue with windows i back to the2.1.119

claude[bot] contributor · 4 months ago

This is a duplicate of #53041, which was fixed as of version 2.1.119.

sgalliver · 4 months ago

"Fixed as of version 2.1.119"?? The problem was in 2.1.120!! You're hilarious, Claude! 😂

github-actions[bot] · 3 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.