You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
correctness: __proto__ does not equal the object's prototype for plain objects and class instances, while Object.getPrototypeOf does (arrays unaffected) #10706
__proto__ returns something that does not compare equal to the object's actual prototype, for plain objects and class instances. Object.getPrototypeOf is correct on the same objects, so the two disagree. Arrays are unaffected. Silent wrong answer, no error.
The receivers are pushed into a live array first, so they are genuinely escaped heap objects — this is not the scalar-replacement folding of #10689, and it reproduces on a tree without that fix.
Shape of the divergence
receiver
__proto__
Object.getPrototypeOf
plain object literal
wrong
correct
array
correct
correct
class instance
wrong
correct
That Object.getPrototypeOf is right while __proto__ is wrong on the same object means the prototype link itself is intact and the __proto__ accessor is returning a different value — a distinct object, or a re-derived intrinsic that is not the same identity as the one Object.prototype names. Arrays working suggests the array path resolves the intrinsic differently from the object and class paths.
Why it matters
__proto__ is deprecated but very widely used in existing library code for prototype identity checks — plain-object detection, clone and merge helpers, and x.__proto__ === Y.prototype tests in general. Those take the wrong branch silently rather than throwing, which is the hard failure mode to attribute from downstream.
It also means the two documented ways of asking the same question give different answers, so a reader cannot trust either without checking both.
Environment
perry built from main 68a545439 + #10611, Linux x86-64, compared against node v26.8.1. Found while fixing #10689; independent of it.
Fixed on main (verified on v0.5.1617). Ran this issue's own program plus a wider probe — plain object, class instance, array, subclass, function-constructor and null-prototype:
plain: true class: true arr: true
all identical to node 26.5.1, where this issue reported false true / true true / false. __proto__ and Object.getPrototypeOf now agree on every shape tested. No commit cites this issue — it was fixed incidentally, which is why it stayed open.
Activity
proggeramlug commentedon Sep 20, 2026
Fixed on
main(verified on v0.5.1617). Ran this issue's own program plus a wider probe — plain object, class instance, array, subclass, function-constructor and null-prototype:all identical to node 26.5.1, where this issue reported
false true / true true / false.__proto__andObject.getPrototypeOfnow agree on every shape tested. No commit cites this issue — it was fixed incidentally, which is why it stayed open.