Why can a JavaScript Proxy's `get` trap cause a TypeError even when the trap body itself runs without error, and what shape of property on the target triggers it?

## Traps are checked, not trusted The intuitive model of a proxy is "the handler decides". That is almost true. Each trap is called, and then, before the result is used, the engine compares it against the real state of the target. If the result contradicts a guarantee the target has already committed to, the operation throws a `TypeError` — from the call site, not from inside your handler. These checks are called the essential internal method invariants, and they exist so that language-level guarantees survive being wrapped. The guarantee that matters is *permanence*. A configurable property can be redefined or deleted, so promising nothing about it is fine. A **non-configurable** property is a promise that it will keep existing on that object, and a non-configurable **non-writable** data property is a promise that it will keep that exact value forever. Code — including engine optimisations and security-minded code that froze an object on purpose — is allowed to rely on that. A proxy is not allowed to break it. ## The `get` case, concretely ```js const target = {}; Object.defineProperty(target, 'id', { value: 42, writable: false, configurable: false, }); const p = new Proxy(target, { get() { return 'anything else'; }, }); p.id; // TypeError: 'get' on proxy: property 'id' is a read-only and // non-configurable data property on the proxy target but the // proxy did not return its actual value ``` The trap ran fine and returned a string. The throw happens afterwards, in the proxy's `[[Get]]`, when the returned value is compared to `42` with SameValue semantics. Return `42` and the operation succeeds. There is a matching rule for accessors: if the target has a non-configurable accessor property whose getter is `undefined`, the trap must return `undefined`. Note what does *not* trigger it. A merely non-writable property (still configurable) is fine to lie about, because it could be redefined. A property that does not exist on the target at all is fine to invent. Frozen objects hit the rule hardest, because `Object.freeze` makes every own data property non-writable **and** non-configurable at once — so a proxy over a frozen object is essentially unable to fake any of its existing values. ## The rest of the invariant family Each trap carries its own version of the same idea: - **`set`** — cannot report success for a value different from a non-writable, non-configurable own data property, nor for a non-configurable accessor with no setter. - **`has`** — cannot return `false` for a non-configurable own property of the target, nor for any own property when the target is non-extensible. - **`deleteProperty`** — cannot return `true` for a non-configurable own property, nor for any own property of a non-extensible target. - **`getOwnPropertyDescriptor`** — cannot report `undefined` for a non-configurable own property; cannot report a property as non-configurable unless it exists that way on the target; and cannot invent properties on a non-extensible target. - **`defineProperty`** — cannot report success for a definition the target would have rejected. - **`ownKeys`** — must include every non-configurable own key, and over a non-extensible target must be exactly the target's own keys, no more and no fewer. - **`isExtensible`** — must agree with the target's real extensibility, always. - **`preventExtensions`** — can only report `true` if the target is genuinely non-extensible afterwards. - **`getPrototypeOf`** — may return anything while the target is extensible, but once the target is non-extensible it must return the target's actual prototype. - **`construct`** — must return an object. A useful way to compress all of this: **you can lie freely about an extensible target's configurable properties, and about nothing else.** ## Practical consequences First, if you want maximum freedom in a handler, wrap an empty extensible object and synthesise everything, rather than wrapping a real object whose shape constrains you. Many virtual-object handlers use `new Proxy({}, handler)` for exactly this reason. Second, invariant errors are late and confusing to read: the stack points at the call site, the message names the target's property, and the handler looks innocent. When you see "proxy did not return its actual value", go and inspect the target with `Object.getOwnPropertyDescriptor` — the answer is always in the descriptor's flags. Third, this is the honest answer to "can I use a proxy to intercept anything?". You can intercept every operation, but you cannot contradict what the target has permanently promised. That is a deliberate design decision: it keeps `Object.freeze` meaningful and keeps invariants that other code depends on from being silently undermined by a wrapper it cannot see.