inspector/clients
Repository files (latest commit first)
Filename Latest commit message Latest commit date
cliffhall bc433bbf72 fix: keep the object branch's __proto__ handling when filtering per key
A regression from the previous commit. The object branch was a spread, which
*defines* properties and is therefore safe; rewriting it into a per-key loop to
filter unserializable values turned it into `out[key] = value`, which *sets* —
so a persisted `"__proto__"` key vanished on reload and, with an object value,
gave the returned metadata a caller-controlled prototype. The legacy branch had
already been fixed for exactly this.

Fixed at the root rather than the site: both branches now go through one
`defineMetadataKey`, so a change to how one stores a key cannot leave the other
behind. That split is what let the earlier fix fail to protect this path.

The test uses `JSON.parse('{"__proto__":…}')`, not an object literal — a
literal `__proto__:` key sets the prototype at construction and creates no own
property, so a test written that way passes against the broken code. Confirmed
by reverting the line: only the parsed case fails.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0177mPHAdECD18nLLCTwR5rh
Signed-off-by: cliffhall <cliff@futurescale.com>
2026-08-23 20:18:38 -04:00
..
cli fix: stop leaking metadata values into diagnostics, and salvage per key 2026-08-23 20:03:37 -04:00
launcher chore(lint): fail lint on warnings (--max-warnings 0) 2026-08-23 10:47:29 -04:00
tui Merge branch 'v2/main' into v2/feat/1910-complex-request-metadata 2026-08-23 18:55:24 -04:00
web fix: keep the object branch's __proto__ handling when filtering per key 2026-08-23 20:18:38 -04:00