Summary
After #8724 (captured ArrayBuffer/DataView) is applied, the natively-compiled Claude Code cli.js 2.1.112 bundle still throws at module init on nearly every command (only --version escapes via early exit):
Uncaught (in promise) ReferenceError: identifier is not defined
Node runs the same bundle fine. The message is the nameless form (js_throw_reference_error_unresolved_get, error.rs:1013) — emitted by lower/expr_new.rs:1580 for new <X>() when X resolves to no lexical / function / class / import / native-module / reified-global-builtin binding. So some new X(...) at module-init has an X perry failed to resolve.
Lead
new $(...) appears 5× in the bundle, and $ is in the compile's "unknown identifier — assuming global" list. But $ is NOT an undefined global here — it's a pervasively-used minified local / parameter in cli.js (let $= ×1014, var $= ×240, ($)=>, function($), new $({type:"boolean"}), new $(this,h,C)). So perry's scope resolution is failing to bind $ to its definition in some new $() context and falling through to the unresolved-new throw. (Other unknown-list names — Bun/Deno/window/document/Iterator/AsyncIterator — are env/ES2025 globals; cli.js only reads them typeof-guarded or as strings, and Iterator is never used as a value, so they are not the blocker. new ReadableStream works — it's reified.)
To pin the exact identifier
Instrument the throw site and re-lower the bundle (the decision is in HIR lowering, before the slow LLVM codegen, so it can be captured in the first ~2 min):
// crates/perry-hir/src/lower/expr_new.rs, just before the NewDynamic throw return
eprintln!("[nameless-new] new {class_name}(...)");Impact
Blocks running the natively-compiled Claude Code bundle end-to-end (startup). This surfaced only now because the bundle had not been run end-to-end on current main (the #8583 acceptance validated codegen completion, not a booting binary). Likely a perry scope-resolution gap for a class of minified identifiers, not a single-line fix.
Found while verifying #8707/#8726 against a freshly-built cc binary.
Summary
After #8724 (captured ArrayBuffer/DataView) is applied, the natively-compiled Claude Code cli.js 2.1.112 bundle still throws at module init on nearly every command (only
--versionescapes via early exit):Node runs the same bundle fine. The message is the nameless form (
js_throw_reference_error_unresolved_get, error.rs:1013) — emitted bylower/expr_new.rs:1580fornew <X>()whenXresolves to no lexical / function / class / import / native-module / reified-global-builtin binding. So somenew X(...)at module-init has anXperry failed to resolve.Lead
new $(...)appears 5× in the bundle, and$is in the compile's "unknown identifier — assuming global" list. But$is NOT an undefined global here — it's a pervasively-used minified local / parameter in cli.js (let $=×1014,var $=×240,($)=>,function($),new $({type:"boolean"}),new $(this,h,C)). So perry's scope resolution is failing to bind$to its definition in somenew $()context and falling through to the unresolved-newthrow. (Other unknown-list names —Bun/Deno/window/document/Iterator/AsyncIterator— are env/ES2025 globals; cli.js only reads them typeof-guarded or as strings, andIteratoris never used as a value, so they are not the blocker.new ReadableStreamworks — it's reified.)To pin the exact identifier
Instrument the throw site and re-lower the bundle (the decision is in HIR lowering, before the slow LLVM codegen, so it can be captured in the first ~2 min):
Impact
Blocks running the natively-compiled Claude Code bundle end-to-end (startup). This surfaced only now because the bundle had not been run end-to-end on current
main(the #8583 acceptance validated codegen completion, not a booting binary). Likely a perry scope-resolution gap for a class of minified identifiers, not a single-line fix.Found while verifying #8707/#8726 against a freshly-built cc binary.