cc --help parity gate down on main: defineProperty-on-non-object at startup — window pins #9326 (indexed writes with a recorded custom array prototype)

[proggeramlug]

Symptom

The cc --help parity gate is DOWN on main: the natively-compiled claude-code bundle (cli_2.1.112.js, the standard PERRY_NO_CACHE=1 … --no-auto-optimize --enable-wasm-runtime recipe) exits rc=1 with

Uncaught (in promise) TypeError: Object.defineProperty called on non-object
    at <anonymous>

instead of printing the 9,175-byte help text. Deterministic — three independent binaries, every run:

build	SHA	cc --help
app_r5 (Aug 31)	83754818e (#9242)	PASS — byte-identical to node, rc=0
app_r6 (tonight)	9943dd95c (#9328)	FAIL — TypeError above, rc=1
fresh tip build (tonight)	a03be729c4 (#9336)	FAIL — same TypeError

All three compiled on perrymaster with the same recipe and verified against the same node cli_2.1.112.js --help output (rc=0, 9,175 bytes). The perry-runtime lib suite is green at tip (2904 passed) — the breakage is invisible to it.

Window

83754818e..9943dd95c is 28 commits, but d1bef4c (#9323, "cc --help segfault fixed, parity gate back online") re-verified the gate at its own merge point — which already contains #9300/#9302/#9315/#9316/#9317/#9318. That leaves exactly two commits between the verified-green #9323 and the failing #9328 tip:

• 1f8ad06fa1 — fix(runtime): indexed writes honour a custom array prototype (from #9297) #9326: indexed writes honour a custom array prototype (from fix(runtime): indexed writes and the generic array engine honour a custom prototype chain #9297) — runtime behavior change on indexed reads/writes/HasProperty for arrays with a recorded custom prototype (array_static_proto_recorded latch + real_array_uses_recorded_spec_path)
• 9943dd95c3 — fix(release): prime the macOS x86_64 dependency cache (from #9327) #9328: release-infra only (macOS dependency cache), cannot affect the compiled runtime

so unless #9323's gate claim was not actually run, #9326 is the culprit by elimination.

Mechanism hypothesis, consistent with the error: the bundle retargets array prototypes early (polyfill/subclass boilerplate), which arms the process latch; after that, array[k] / HasProperty on any array with a recorded prototype routes through the new array_spec_get / array_spec_has_index lanes. A read that now yields undefined (or a changed HasProperty verdict feeding an index walk) lands in Object.defineProperty(<that value>, …) → throw_object_type_error(b"Object.defineProperty called on non-object") (object_ops/define_property.rs:429).

Repro

ssh perrymaster
export HOME=/tmp/cc_home
/root/claude-shapedesc/app_base --help    # tip a03be729c4 — fails
/root/claude-arch/app_r6 --help           # 9943dd95c — fails
/root/claude-arch/app_r5 --help           # 83754818e — passes, byte-identical

Found while measuring an unrelated runtime change (shape-descriptor no-copy reads) whose A/B had to be moved back to 83754818e because neither arm can pass the gate on current main. Also note: tonight's r6 headline measurement in /root/claude-arch/measure_r6.log silently measured the BROKEN binary (its --help run does ~0.69B instructions vs node's 4.05B because it dies early) — those numbers should be discarded.

[proggeramlug]

Revert merged (#9345) — main should be back to a working cc --help.

I merged #9326, so this one is on me, and the miss is worth stating precisely because it wasn't a gap in the analysis of the change itself.

I validated #9326 against the gap fixture it targets (test_gap_9220_9221_array_proto_paths.ts, byte-identical to the pinned oracle), the perry-runtime suites, the full lint set, and a clean release build. All green. What I did not do was run the cc --help parity workload — which #9323 had restored to service three merges earlier, in a PR I had reviewed and merged myself that same evening.

That is the actual lesson here: a runtime-semantics change to indexed writes is exactly the kind of thing that primary workload exists to catch, and the fact that the gate had just come back online is what should have made me reach for it. A green gap fixture and a green unit suite were never going to see this — as #9341 notes, the runtime lib suite is green at the failing tip too.

One clarification on scope, since #9326 was #9297 plus an adjustment of mine. My part was moving array_spec_set back into indexing.rs so its seven pre-existing raw-handle sites kept their existing ceiling, plus a pub(crate) visibility bump and an import fix — a pure relocation with no semantic change, which compiled and tested clean. The behavioural change in the window is #9297's own: honouring a recorded custom array prototype on indexed writes. I mention this only so the fix-forward looks in the right place, not to move the responsibility for merging it.

Happy to help with the diagnosis when someone picks this up. Object.defineProperty called on non-object on a path that now consults a recorded array prototype suggests the new lookup is answering for a receiver the old one declined, and the defineProperty path is then handed something that isn't an object — but that's a hypothesis, not a finding, and the preserved known-good/known-bad binaries at /root/claude-shapedesc/ are a better starting point than my guess.

[proggeramlug]

A measured finding that matters beyond this issue: the gap suite cannot see this regression.

I built the pre-revert commit (6bc775d9b9, containing #9326) as a known-bad binary and ran the full 609-test gap suite against it, then the same suite against post-revert main. The two runs are indistinguishable:

	known-bad (#9326 present)	post-revert main
Parity pass	604	604
Parity fail	5	5
failing tests	same 5	same 5
verdict	Gap snapshot OK	Gap snapshot OK
exit	0	0

The 5 failures are the recorded known set in both cases. I also wrote targeted defineProperty probes — prototype index setters, Array.prototype index installation, defineProperty on values read back through a custom-prototype array, sparse reads, growth through the custom-prototype path — and every one is byte-identical to node on the known-bad build.

So the detection surface for this class is currently: perry-runtime --lib green, 609-test gap suite green, hand-written probes green, and cc --help the only thing that fails. That is a single point of detection for a path that changes indexed-write semantics.

Two consequences worth acting on:

This is why #9326 landed. I validated it against its target gap fixture, the runtime suites, the lint set and a clean build — all green, and now demonstrably all incapable of catching it. The lesson I drew earlier ("I should have run cc --help") is right but incomplete: no locally available gate would have caught it either.

A fixture for this would close a real hole. Whatever minimal shape reproduces the Object.defineProperty called on non-object failure is worth adding to test-files/ as a gap test, because the class it represents — prototype-sensitive [[Set]] routing — is exactly the kind of change that gets made often and can currently land green. The preserved binaries at /root/claude-shapedesc/ are the obvious starting point; my probes above did not find the shape, so it likely needs something structural the bundle does that a small fixture has to reproduce deliberately.

I have held #9339 back for the same reason and said so there — it reintroduces the sole call site of the reverted path, and a green gap run on it would not be evidence of anything.

[proggeramlug]

Negative result, posted so nobody repeats it: I tried to minimise this into a fixture against a purpose-built known-bad binary (6bc775d9b9, containing #9326) and could not reproduce it. Three rounds, all byte-identical to node on the broken build:

1. Direct shapes — defineProperty with a prototype index setter, installing an index on Array.prototype, defineProperty on non-objects (null, a number) to check the TypeError path itself.
2. Prototype + growth — defineProperty applied to values read back out of an array with a custom prototype, including after 40 indexed writes that grow it, and via a sparse read at index 100.
3. Bundler idioms — the esbuild/tsup __defProp / __export / __copyProps helpers over a module registry held in an array, the same with a custom-prototype registry, and the whole thing again inside a Promise.resolve().then(...) chain to match the "Uncaught (in promise)" framing.

So the trigger is something more specific than "defineProperty near a prototype-sensitive indexed write". That narrows it usefully: it is unlikely to be the plain helper shapes, and more likely to need something structural the bundle does — the wasm runtime path, a deeper prototype chain, or a receiver that only becomes non-object after a particular sequence.

Whoever picks this up is far better placed than I am: the known-good/known-bad binaries at /root/claude-shapedesc/ plus the bundle allow bisecting the input rather than guessing the shape. A --trace hir --focus on the frame that calls defineProperty in the failing binary would probably identify the receiver in one pass.

Standing conclusion from the earlier comment is unchanged: the 609-test gap suite returns an identical verdict on the known-bad and known-good builds, so this class currently has exactly one detector, and it is not one that runs locally.

[proggeramlug]

Correction: #9326 was NOT the culprit. The revert (#9345) is merged and cc --help still fails identically.

Measured on e539a6359 — which contains the revert (14fcf6b942) — freshly built and compiled on perrymaster:

=== PARITY GATE ===
perry rc=1
node rc=0
< Uncaught (in promise) TypeError: Object.defineProperty called on non-object

Same error, same rc, 5/5. So the revert removed correct work and fixed nothing, and the real culprit is still on main.

Where the attribution went wrong

The elimination rested on "#9323's fix branch was verified cc-green and contained everything through ~#9322." That premise was false, and I had already disproved it before accepting the conclusion: the #9323 work was based on d6794cf771 (#9313), which does not contain #9300, #9315 or #9317 — I checked exactly that with git merge-base --is-ancestor and recorded "window is bigger than #9326," then let a second, independently-derived elimination override my own contradicting check instead of reconciling the two.

The lesson, stated plainly because it is the reusable part: when a second line of evidence contradicts a check you have already run, the disagreement is the finding — reconcile it before acting. Two confident attributions agreeing on a wrong answer is exactly what "independent confirmation" is supposed to prevent, and it did not, because both inherited the same false premise about what the verified-good point contained.

The real window

Last verified-green: 83754818e (#9242, per the independent shapedesc build) / d6794cf771 (#9313, the #9323 base).
Broken: current main.

Candidates between them (all merged since), several of them mine:
#9312 JSON tape gate · #9314 ELF/scrypt · #9300 GC map v5 · #9315 own-keys enumeration · #9316 strided fill kernel · #9318 affine index bound · #9317 tombstone old_carrier · #9319 mysql2 · #9320/#9321/#9322 lint/green fixups · #9326 **(now exonerated by the revert)`.

On the error's own evidence, #9315 deserves first look — it changed class-member registration and own-keys enumeration, and the failure is a defineProperty receiver arriving as a non-object during help-path module init. #9300 (GC map) and #9317 (shape publish) are the other two runtime-semantics candidates.

A proper bisect over that window is starting now. #9297's content should be re-landed once the true culprit is found — the revert bought nothing and #9220/#9221 remain real bugs.

[proggeramlug]

Interim: three eliminations, one corrected artifact, and the throw site narrowed to one of two.

Posting before the attribution is finished because several of these are immediately reusable.

1. /root/claude-keep/app_D is not a reproducer of this bug

It is worth stating plainly, because it has been passed around as "the known-bad binary":

$ HOME=/tmp/cc_home /root/claude-keep/app_D --help
Segmentation fault (core dumped)   rc=139

app_D segfaults. It never prints the TypeError. Anyone differentially debugging #9341 against it is chasing the pre-#9323 longjmp segfault, not this issue.

The binaries that actually reproduce #9341 are:

binary	SHA	result
/root/claude-shapedesc/app_base	a03be729c (#9336)	rc=1, Object.defineProperty called on non-object
/root/claude-arch/app_r7	(later tip)	rc=1, same
/root/claude-shapedesc/app_base3	83754818e (#9242)	rc=0, 9175 bytes, byte-identical to node
/root/claude-keep/app_A	—	rc=0, 9175 bytes

So the confirmed bracket is green 83754818e → broken a03be729c, and a03be729c predates #9331/#9332/#9333/#9340. (measure_sd2.sh also records 9943dd95c (#9328) as already failing, which is release-only — consistent with the culprit being at or before #9326's merge point.)

2. The failure is deterministic and completely GC-independent

Five kill switches on the reproducing binary, all 5/5 identical failures:

configuration	result
default	TypeError
PERRY_GC_MOVING_LOOP_POLLS=0	TypeError
PERRY_GC_HEAP_LIMIT=4096	TypeError
PERRY_LAZY_STACK_MAPS=0	TypeError
PERRY_STACKMAP_WALKER=unwind	TypeError
PERRY_OBJECT_TOMBSTONES=0	TypeError
PERRY_LAZY_STACK_MAPS=0 + PERRY_GC_MOVING_LOOP_POLLS=0	TypeError

Turning the moving collector off and raising the heap limit does not change the failure by one byte. This is not a GC or rooting bug. That eliminates, as mechanisms:

• perf(gc): v5 GC map — find one function's records without decoding the section (index build 63.5x less work, −214 MB RSS) #9300 (GC map v5) — PERRY_LAZY_STACK_MAPS=0 restores the v4-style eager path and the failure is unchanged;
• fix(gc): tombstone shape publish arms old_carrier — deleted receivers no longer lose their keys array under evacuating GC (#9200) #9317 (tombstone publish arms old_carrier) — its entire subject is a receiver's keys array under an evacuating minor GC, and there is no evacuating GC dependence here;
• perf(runtime): tombstone deletes default-on again — the #9200 corruption that rolled them back is fixed (26x on populated delete) #9331 (tombstones default-on) — not in a03be729c at all, and the kill switch is inert.

It also says the receiver is not a corrupted object. It is a value that was never object-like on this path.

3. There are exactly two throw sites — and it is the second one

crates/perry-runtime/src/object/object_ops/define_property.rs:429
crates/perry-runtime/src/util_inherits.rs:134   (set_super_property)

Both emit the identical byte string, so the message alone cannot tell them apart. I found a genuine 4-line reproducer for the util_inherits one:

const util = require("util");
class Base2 {}
class Derived2 {}
util.inherits(Derived2, Base2);
console.log(typeof Derived2.super_, Derived2.super_ === Base2);
// node:  function true
// perry: TypeError: Object.defineProperty called on non-object   rc=1

But it fails identically on the green 83754818e build. It is a pre-existing gap, not this regression — filed separately below. Since 83754818e compiles cc --help byte-identical to node, the bundle cannot be reaching that site. The cc throw is define_property.rs:429: a receiver that is neither a registered class-ref, nor object-like, nor a small handle.

That matters for where to look. The guard is

let target_is_class_ref = super::super::class_ref_id(obj_value).is_some();
if !target_is_class_ref && !value_is_object_like(obj_value) { … throw … }

and class_ref_id returns Some only if is_class_id_registered(class_id). A class-ref whose id is not in REGISTERED_CLASS_IDS and has no vtable entry is an INT32-tagged non-pointer, so it fails value_is_object_like and throws precisely this message. That is consistent with the earlier session's gdb note that the receiver "resolves via helper to a class-ref".

4. What I could not reproduce in isolation (35 shapes, all byte-identical on the broken compiler)

So that nobody re-runs these: on the broken a03be729c compiler, all of the following are byte-identical to node — defineProperty on empty classes, static-field-only, getter-only, method-only, class expressions (named and anonymous), subclasses, classes returned from a factory, class prototypes, symbol-keyed classes, static-method-only; getOwnPropertyNames on constructors and prototypes; typeof on class refs; and the whole of #9315's changed computed-symbol lowering surface ([Symbol.iterator] generator and non-generator, [Symbol.asyncIterator], [Symbol.toPrimitive], [util.inspect.custom], static [Symbol.hasInstance], [Symbol.toStringTag] getter and method, and a mixed class where a computed member precedes static/accessor/method members). Also byte-identical: the real util.inherits shapes the bundle actually uses — delayed-stream, combined-stream, EventEmitter subclassing, zlib.Inflate as superCtor, and Ctor.prototype = {…} wiring.

A diagnostic runtime build (receiver bits, tag, class id, is_class_id_registered, and the property key at the throw) is building now; one cc compile with it should name the failing receiver and key directly.

---

Unasked finding, worth its own issue: util.inherits() with an ES class constructor throws

set_super_property handles a closure ctor and an object ctor, and throws for everything else. A class constructor reaches it as an INT32-tagged class-ref, which is neither — so util.inherits(SomeClass, X) throws Object.defineProperty called on non-object where Node sets SomeClass.super_. Reproducer is the 4 lines above; it fails on 83754818e as well as on tip, so it is long-standing and unrelated to this regression. Note the asymmetry: util.inherits(function(){}, SomeClass) is fine — only a class in the first position fails. The fix is presumably to route a class-ref ctor through the class static-property store the way define_property.rs already does via class_ref_id. Happy to file it with the fixture if nobody else has.

[proggeramlug]

Still broken on tip. #9340 did not fix it, and the revert of #9326 did not fix it.

Fresh build at 0f95fbc9f (current main — contains #9340 "preserve array prototypes across growth", #9351, #9337, the #9345 revert, and everything else):

LIBS_RC=0  BIN_RC=0  CC_RC=0
PARITY: 0/5 byte-identical (rc=0)
Uncaught (in promise) TypeError: Object.defineProperty called on non-object

State of the attribution

• Green: 83754818e (fix(release): clear field-shadow and WebAssembly parity blockers #9242) — independently confirmed byte-identical to node.
• Broken: 0f95fbc9f (tip), and every point tested in between.
• fix(runtime): indexed writes honour a custom array prototype (from #9297) #9326 exonerated — its revert (Revert #9326 — it breaks cc --help on main (defineProperty TypeError); fixes #9341 #9345) is merged and the break persists. That revert removed correct work (fix(runtime): indexed writes and the generic array engine honour a custom prototype chain #9297, fixing arr[i] = v never observes an inherited index accessor or non-writable inherited index — the strict store's fast lanes bypass array_spec_set #9220/Array.prototype.{join,indexOf,map,forEach}.call(arr) does not fill holes through a custom prototype #9221) and should be re-landed once the true culprit is known.
• fix(runtime): preserve array prototypes across growth #9340 exonerated as a fix; it remains a candidate culprit, having landed inside the window.

Remaining candidates: #9312, #9314, #9300 (GC map v5), #9315 (class own-keys enumeration), #9316, #9318, #9317 (tombstone shape publish), #9319, #9320/#9321/#9322, #9337, #9340, #9349–#9358.

A bisect over that range is running, along with fixture probes against paired green/broken builds — a minimized fixture is the higher-value deliverable and will be posted here as soon as it exists, with or without the commit attribution.

What this costs, stated plainly

cc --help is the project's primary real-application parity workload. It has now been broken on main for the better part of a day, which means every cc measurement any session takes against main is void, and any branch measured on top of it appears to be the cause. This is the third such episode this week (#9169's window, #9305, this one) and the direct argument for the pre-merge cc parity gate proposed in #9346 — every one of the three shipped with its author's fixtures and unit suites green, and only the bundle catches the failing shape.

[proggeramlug]

Status + one correction to my own earlier post, because it contradicts something I wrote above.

Reconciliation first

My previous comment listed emitter-fire, zlib-inherits, protoobj-inherits and ~35 other shapes as "byte-identical to node on the broken compiler". That is exactly what they are — identical, therefore useless as bisect fixtures. They do not differentiate green from broken; they differentiate nothing. I am stating that plainly because a list of green probes reads like progress and is not.

The two shapes I did find that diverge from node both fail on the green build too:

fixture	green 83754818e	broken a03be729c	verdict
util.inherits(SomeClass, X) → TypeError	fails	fails	pre-existing → #9362
factory class D extends <param> chained 2 levels → SIGSEGV	fails	fails	pre-existing → #9364

So: I do not yet have a fixture that separates green from broken. That is the thing still missing, and I am not going to present either of the above as if it were one.

Confirmed: still broken on tip

Independently confirmed by the parallel run on 0f95fbc9f — CC_RC=0, then PARITY: 0/5. #9340 did not fix it. The bracket is 83754818e green → tip broken, still live.

The window is 52 commits, not 15

Worth correcting, because the candidate list in circulation (#9312, #9314, #9300, #9315, #9316, #9318, #9317, #9319, #9320-#9322, #9326) is only its tail. git rev-list --count 83754818e..a03be729c = 52. The head of the window contains, among others:

9ee99197c #9250 inline array-store tier covers tagged receivers
322b6c1e4 #9257 receiver-region model + equivalence lint
c1c8623ed #9270 use live receiver in stable packed loops
6d08afc29 #9272 inline address window in front of the registry probes
3a9b203ad #9284 keep shape barriers in source modules
87270e6f2 #9291 Bloom filter for the heap-allocated registries; #9225 linear scan gated
0515179a4 #9295 classify prototype wiring as class-default
986f4e121 #9296 preserve renamed namespace constructor args
730e0a997 #9302 overflow-slot properties prime the constant-key ICs

Several of these are much closer to "a receiver arrives as a non-object" than anything in the tail. Anyone reasoning about this window should be using the full 52.

A narrowing that is evidence rather than a hypothesis

The failing throw is define_property.rs:429 (established above: the only other site is util_inherits.rs, and that one fails on green, which compiles cc --help byte-identical). The guard that reaches it is exactly:

let target_is_class_ref = class_ref_id(obj_value).is_some();
if !target_is_class_ref && !value_is_object_like(obj_value) { … is_small_handle fallback … throw }

value_is_object_like = typed_array_addr_from_value ∨ is_valid_obj_ptr ∨ is_closure_ptr; class_ref_id = tag 0x7FFE ∧ is_class_id_registered.

Asking git which of the 52 commits touch any file implementing those predicates gives exactly two:

$ git log --oneline 83754818e..a03be729c -- <the predicate files>
6d08afc29  #9272  closure/dynamic_props.rs      (is_closure_ptr: CLOSURE_MAGIC tag read hoisted above the arena check)
8b2cfe6e7  #9315  class_registry/registration.rs (additions only; is_class_id_registered itself unchanged)

descriptor_helpers.rs, addr_class.rs, class_ref_values.rs, define_property.rs and class_meta.rs are untouched across the whole window. So if the receiver is a closure that stopped being recognised, #9272 owns it; if it is a class ref whose id stopped being registered, the registration call sites (codegen/HIR) own it rather than the predicate. That does not name the culprit, but it is a real constraint rather than a prior. (I read #9272's is_closure_ptr change closely — it is a pure reordering of a conjunction, and I could not fault it on inspection. Inspection is not measurement.)

What the receiver can actually be

Instrumenting Object.defineProperty on the real node cli_2.1.112.js --help run (patching the builtin and filtering by stack to calls originating in the bundle) gives 5,177 distinct call shapes, of which the dominant ones are zod v4's $constructor:

[651] object ZodString   key=_zod   @ $ZodType.z   (cli.js:68:78640)
[540] object ZodOptional key=_zod   @ $ZodType.z
[161] CLASS  (class A extends Y{})  key=name       @ b1 (cli.js:68:78939)
[161] function O key=init / Symbol(Symbol.hasInstance) / name  @ b1

$ZodType.z is Object.defineProperty(inst, "_zod", …) where inst = params?.Parent ? new Definition() : this — i.e. the receiver is this, which lines up with the earlier session's gdb note that the receiver "resolves via helper to a class-ref". That is the single most-executed defineProperty receiver on the help path, so it is where I would expect the failure to sit.

I could not reproduce it in isolation: faithful reductions of $constructor (with and without Parent, chained 3 deep, 200 evaluations, Symbol.hasInstance, per-evaluation class identity, 500 repeated class evaluations) are node-identical on the broken compiler, and the real zod 4.4.3 (spike/tests/02-zod.ts against a real node_modules) compiles and runs byte-identically on green and broken. So whatever it is needs more of the bundle's context than a reduction reproduces — which is why I stopped reducing and went to instrumentation.

In flight

A diagnostic runtime built at a03be729c prints, at the define_property.rs:429 throw, the receiver's raw bits, NaN-box tag, class id, is_class_id_registered, pointer/undefined/null predicates and the property key — with the util_inherits site given a distinct marker so the two can never be confused again. Validated first on fixtures that hit each site deliberately (a diagnostic that cannot fire teaches nothing). The cc compile with it is running now; it should name the receiver and the key directly.

Method note for whoever picks this up next

/root/claude-keep/app_D segfaults rather than reproducing this bug (see my earlier comment) — and separately, two cc-scale compiles were running concurrently on perrymaster earlier today with available memory at 0 GB. A cc compile peaks around 29 GB, and an OOM kill leaves a plausible-looking binary that only rc=137 reveals. Worth gating on free before starting one.

[proggeramlug]

Root cause identified. The failing call is Object.defineProperty(undefined, "getContentType", …) — a class's .prototype read is returning undefined.

The measurement

A diagnostic runtime built at a03be729c, instrumenting the define_property.rs:429 throw (and giving the util_inherits.rs site a distinct marker so the two can never be confused). One cc compile, one --help run:

TEMPDIAG9341 DP bits=0x7ffc000000000001 tag=0x7ffc cid=0 proto_flag=false
              registered=false is_ptr=false is_undef=true is_null=false key=Some("getContentType")
Uncaught (in promise) TypeError: Object.defineProperty called on non-object

Exactly one such throw in the whole run. The receiver is undefined — tag 0x7FFC, is_undef=true. It is not a class ref, not a closure, not a handle, not a corrupted pointer. It is a value that should have been an object and is undefined.

That kills three standing theories outright, including one of my own: it is not an unregistered class ref (cid=0, registered=false because there is no class id at all), not a closure the predicate stopped recognising, and not the util_inherits site.

Where it is in the bundle

The key names it. getContentType is generated by axios's AxiosHeaders.accessor, which in cli_2.1.112.js (line 68) is:

static accessor(q){
  let _=(this[lb7]=this[lb7]={accessors:{}}).accessors,
      z=this.prototype;                                   // <-- z is undefined
  function Y(A){let O=VU6(A);if(!_[O])xp5(z,A),_[O]=!0}
  return H1.isArray(q)?q.forEach(Y):Y(q),this
}
...
kU6.accessor(["Content-Type","Content-Length","Accept","Accept-Encoding","User-Agent","Authorization"]);

xp5(obj, header) is axios's buildAccessors, which does Object.defineProperty(obj, "get"+Name, …) for get/set/has. Content-Type is the first entry and get is the first method, so getContentType is the first accessor built — i.e. this fails on the very first call, which is why there is exactly one diag line.

So the receiver xp5 gets is z, and z = this.prototype evaluated to undefined inside a static class method where this is the class.

Restating the bug in one line: reading .prototype off a class returns undefined in the compiled bundle. Everything downstream — the TypeError, the "in promise" framing, the 0-byte --help — follows from that.

Two corroborating facts

• --version works on every broken build (rc=0, 21 bytes, byte-identical to node) while --help fails. The failure is on the command/option-tree construction path that --version short-circuits past.
• Under PERRY_FOR_IN_DIAG=1 the broken binary emits only 4 for-in checks before dying, so this is early on that path, not deep in help rendering.

What does not reproduce it (so nobody repeats this)

I reduced the axios shape faithfully and it is byte-identical to node on the broken compiler, and identical between the green and broken builds:

• this.prototype inside a static method — fine;
• Object.defineProperty(this.prototype, …) inside a static method — fine;
• the full AxiosHeaders.accessor shape: symbol-keyed static write this[SYM]=this[SYM]={accessors:{}}, let z=this.prototype captured by a nested named function, Array.isArray(q)?q.forEach(Y):Y(q),this comma-sequence return, ["get","set","has"].forEach inside the builder, over the real six-header list — fine, accessors built and callable;
• the same as a class expression assigned to a variable and aliased — fine;
• with and without the symbol write, the comma sequence, the closure capture — all fine;
• real axios is not the only consumer: real zod 4.4.3 (spike/tests/02-zod.ts against actual node_modules) compiles and runs byte-identically on green and broken.

One genuine divergence turned up on the way — C.accessor = function(){ return this.prototype } returns undefined in perry and the prototype object in node — but it fails on the green build too, so it is pre-existing and not this regression. (Filed as part of the sweep below.)

The reduction gap is itself informative: the shape is correct but the context is not. A property read that is correct cold and wrong warm is the signature of an inline cache, which is where I would look first.

Which commits can do this

Asking git which of the 52 window commits touch the class-.prototype read path (object/field_get_set/, object/class_registry/, object/prototype_chain.rs) gives exactly four:

87270e6f2  #9291  Bloom filter in front of the heap-allocated registries; #9225's linear scan gated
730e0a997  #9302  overflow-slot properties prime the CONSTANT-KEY ICs (27 -> 5 ms)
d6794cf77  #9313  keep main green after the #9302/#9303/#9307 batch
8b2cfe6e7  #9315  class-prototype own-keys enumeration

this.prototype is a constant-key property read, and #9302 changes how constant-key ICs are primed — a warm-only wrong answer is exactly what that can produce, and it is exactly what the reduction gap points at. #9313 exists specifically to "keep main green after the #9302 batch", which says that batch had fallout. #9291's filter is release-only in effect (its audit is #[cfg(debug_assertions)]), which would explain invisibility to every debug-run suite.

I am not claiming any of these yet — this list is what the failing path can reach, not evidence.

In flight

A build at d6794cf77 (#9313) with #9323's longjmp fix cherry-picked (it applies cleanly — #9323's own base is d6794cf77) is compiling now. The cherry-pick matters: every point below #9323 segfaults on cc --help for the unrelated reason #9323 fixed, so without it a bisect step below that line answers a different question.

That point splits the four candidates cleanly:

• green ⇒ culprit is in fix(link,crypto): ELF archive grouping and scrypt cost parameters (from #9311) #9314…fix: restore three lint gates that went red during the merge batch #9322, where fix(runtime): class-prototype own-keys enumeration — accessors listed, symbols real, spec order (36 diverging fixture lines → 0) #9315 is the only one of the four;
• broken ⇒ culprit is at or before fix: keep main green after the #9302/#9303/#9307 batch #9313, i.e. perf(runtime,codegen): overflow-slot properties prime the constant-key ICs (27 → 5 ms, 5×) #9302 or perf(runtime): a Bloom filter for the heap-allocated registries, and #9225's linear scan gated — cc --help −1.25% instructions, −2.37% cycles #9291 — and it also disproves the "verified green at fix: keep main green after the #9302/#9303/#9307 batch #9313" premise that this investigation has been leaning on unverified since the start.

Either answer is worth having; the second especially, because that premise is the one that produced both previous wrong attributions.

Sweep findings filed separately

• util.inherits(SomeClass, …) throws "Object.defineProperty called on non-object" — set_super_property has no class-ref arm #9362 — util.inherits(SomeClass, …) throws the identical message (set_super_property has no class-ref arm). Pre-existing; matters here because the two throw sites emit the same bytes.
• SIGSEGV: factory returning class D extends <param>, chained two levels, then instantiated (zod v4 $constructor shape) #9364 — SIGSEGV on a factory returning class D extends <param> chained two levels then instantiated (the zod v4 $constructor idiom). Pre-existing on green and broken.