In JavaScript, a Proxy's `get` trap is called with `(target, property, receiver)`. What is `receiver`, and give a case where it is not the proxy itself.

## What the third argument actually is Every property read in JavaScript carries two objects, not one: the object you *start* from and the object where the property is eventually *found*. Normally you only notice this with getters, where `this` is the starting object even though the accessor lives on a prototype. The specification calls the starting object the receiver, and `[[Get]](key, receiver)` threads it down the whole prototype chain. A proxy's `get` trap exposes that plumbing directly: `get(target, property, receiver)`. The `target` is the object you wrapped. The `receiver` is the object the access began on. ## When receiver is not the proxy For a direct access they are the same object: ```js const p = new Proxy({}, { get(target, key, receiver) { return receiver; }, }); p.anything === p; // true ``` Put the proxy on a prototype chain and they separate: ```js const child = Object.create(p); child.anything === child; // true — the trap ran, receiver is child ``` The lookup starts at `child`, finds nothing there, walks to its prototype (the proxy), and performs `[[Get]]` on it *with the original receiver preserved*. So the trap sees `target` = the wrapped object, but `receiver` = `child`. `Reflect.get(obj, key, receiver)` and `Reflect.set(obj, key, value, receiver)` let you pass an explicit receiver too, which is the other way to observe the split. ## Why it matters for reads: accessors get the wrong `this` The naive forwarding handler looks harmless: ```js const target = { first: 'Ada', get greeting() { return 'Hi ' + this.first; }, }; const p = new Proxy(target, { get(t, key) { return t[key]; }, // receiver discarded }); const child = Object.create(p); child.first = 'Grace'; child.greeting; // 'Hi Ada' — wrong ``` `t[key]` performs a fresh `[[Get]]` whose receiver is `t`, so the `greeting` getter runs with `this === target` and reads the target's own `first`. Every property the getter touches also bypasses the proxy, so an instrumenting handler silently under-reports. Forwarding the receiver instead — `Reflect.get(t, key, receiver)` — makes the getter run with `this === child` and yields `'Hi Grace'`. ## Why it matters for writes: the property lands on the wrong object The `set` trap signature is `set(target, property, value, receiver)`, and here the consequence is structural rather than cosmetic. Ordinary assignment semantics say that when a write is satisfied by an inherited data property, the new property is created *on the receiver*, not on the prototype. So: ```js const store = {}; const p = new Proxy(store, { set(t, key, value) { t[key] = value; return true; }, // receiver discarded }); const a = Object.create(p); const b = Object.create(p); a.count = 1; b.count; // 1 — leaked through the shared prototype ``` Both children now share one slot on `store`, because the handler wrote to the target instead of to the object the assignment was aimed at. With `Reflect.set(t, key, value, receiver)` each child gets its own own-property and they stay independent. This is the bug the receiver argument exists to prevent, and it is exactly the kind of thing an interviewer means by "do you understand what the proxy is standing in for". ## The self-reference footgun One trap to watch: if you forward a *write* with the receiver and the receiver is the proxy itself — the common direct-access case — the write is re-dispatched through the proxy, and a handler that unconditionally forwards can recurse until the stack overflows. The usual defence is to forward reads and writes to the target while only passing the receiver on, rather than re-entering the proxy, and to be deliberate about which object each operation is meant to land on. ## Which traps carry a receiver Only `get` and `set` do — they are the operations the language defines as receiver-carrying. `has`, `deleteProperty`, `ownKeys`, `getOwnPropertyDescriptor` and `defineProperty` take no receiver, because those operations are defined on a single object and never thread a starting point down the chain. If you find yourself wanting a receiver in `has`, the model to correct is your mental model of the operation, not the trap signature. ## What to say in an interview Define it in one line — "the object the access started on, and the `this` for any accessor" — then produce the prototype-chain case, then name the two failures: getters reading the target's state instead of the real object's, and inherited writes piling up on a shared prototype. That progression shows you know the mechanism rather than the signature.