Code outside a TypeScript class writes `instance['secret']` to read a member declared `private secret: string`. Does that compile, and why does TypeScript allow it?

## The behaviour ```ts class Session { private token = "abc"; } const s = new Session(); // s.token; // error: 'token' is private and only accessible within class 'Session' const t = s["token"]; // compiles; t is string ``` The visibility check runs on property access expressions. Element access with a string-literal key resolves to the same declared member — so you keep the type — but is exempt from the check. This is long-standing, documented behaviour, not an accident of inference. ## Why the hatch exists The alternative escape route is a cast: ```ts const t = (s as any).token; // t is any ``` That works too, but it destroys the type: `t` becomes `any`, and any mistake downstream goes unchecked. The bracket form is strictly better when you must reach in, because a typo in the key is still an error and the result keeps its real type. The main legitimate use is testing — asserting on internal state without widening the class's public surface just to make it observable — plus occasional interop with libraries that dig into instances. ## The full list of holes Be able to enumerate these; interviewers use the question to see whether you understand that `private` is a checker rule: 1. **Bracket access.** `s["token"]` — no error, full type. 2. **`as any` / `as unknown as X`.** Assertions are compile-time only and perform no check. 3. **Plain JavaScript callers.** The modifier is erased on emit, so a JS consumer of your compiled package writes `s.token` freely. 4. **Enumeration and serialisation.** `Object.keys(s)`, `{ ...s }` and `JSON.stringify(s)` all include the field, because it is an ordinary own property. 5. **Structural reads through a wider type.** Assigning the instance to a type that declares the property publicly is generally blocked — private members make class types compare nominally — but reflection-style access via `Object.entries` is not. ## What is *not* a hole A subclass cannot quietly take the member over. If a base declares `private x` and a derived class declares its own `x`, the compiler rejects the class: the two are separate declarations of a private property, and the derived class is not assignable to the base. Nor can a derived class widen a private member to public. Private members also break naive structural compatibility — two classes with identical shapes are mutually assignable only when the private member originates from the same declaration — so you cannot slip past the check by declaring a lookalike interface and asserting to it, at least not without an explicit double assertion. ```ts class A { private id = 1 } class B { private id = 1 } let a: A = new B(); // error: separate declarations of a private property 'id' ``` ## What actually closes the hatch Only `#token`. A private name is JavaScript syntax scoped to the class body: `s["#token"]` looks up a string key that does not exist, `(s as any).#token` is still a syntax-level error because private names may not be referenced outside the declaring class, and the field is not an own property, so nothing enumerates it. The cost is that your tests must go through the public API, and there is no `protected` equivalent for subclasses. ## How to talk about it The strong answer is not "bracket access is a loophole to avoid". It is: `private` is a design tool the checker enforces for dot access on TypeScript source; the bracket form is a typed, deliberate hatch that is far better than `as any` when you genuinely need it; and any member whose exposure would actually hurt — a credential, a handle, anything you would not want in a log line — belongs in a `#` field, where none of the hatches apply.