{"version":"2.1.286","anchor":"auth-server-doc-tells-implementers-not-to-reject-unknown-inp","canonical_anchor":"auth-server-doc-tells-implementers-not-to-reject-unknown-inp","heading":"Built-in gateway documentation updated for unknown fields, auto-mode safeguards and managed settings","tier":"notice","area":"Gateways","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.286\/e\/auth-server-doc-tells-implementers-not-to-reject-unknown-inp","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.286","markdown":"### Built-in gateway documentation updated for unknown fields, auto-mode safeguards and managed settings\n\nGateway docs inside Claude Code now say to ignore unknown input, describe auto-mode safeguards fields, and change the managed settings response format\n\n**What**\n\nClaude Code includes documentation for people running a sign-in server or an LLM gateway, a server that sits between Claude Code and the model. That text changed:\n\n- Servers must ignore request parameters, body fields and headers they do not recognize (\"Don't reject what you don't recognize.\"). They should pass body fields and `anthropic-beta` values through unchanged.\n\n- In auto mode, the client adds an `anthropic-beta` value and a top-level `safeguards` field to requests, and reads `safeguard_results` from responses. A gateway that does not support this should answer with a 400 error naming `safeguards`.\n\n- The managed settings response is now wrapped as `{uuid, checksum, settings}`, with a sha256 checksum used for `If-None-Match` and 304 (not modified) replies. Before, the documentation described returning the bare `managed-settings.json` with an ETag.\n\n**Why**\n\nIf you run a gateway, requests can carry fields your server has not seen before and should not be rejected. The findings suggest a managed settings response in the old shape may be treated as a failed fetch.\n\n- Area: Gateways\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 3\/5"}