{"version":"2.1.267","anchor":"new-event-filter-no-op-hook-oei-added-on-every-bridge-se","canonical_anchor":"remote-control-safeguards-verification-channel-is-built-bu","heading":"New 'safeguards' capability family for permissions and remote control","tier":"soon","area":"Remote Control","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.267\/e\/new-event-filter-no-op-hook-oei-added-on-every-bridge-se","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.267","markdown":"### New 'safeguards' capability family for permissions and remote control\n\nA new 'safeguards' capability, alongside remoteTools\/hooks\/plugins, now gates safety-classification data and remote-control settings changes\n\n**Unclear.** What this hook is intended to do once implemented is not stated in the finding.\n\n**What**\n\n- The permission-context capability record used throughout Claude Code gains a fourth flag, `safeguards`, alongside the existing `remoteTools`, `hooks`, and `plugins` flags. It gates whether the model's safety\/safeguards classification data is attached to a payload.\n\n- Remote Control's device-attestation and settings-diffing machinery gains a matching `safeguards` family, used to police `apply_flag_settings` requests from a paired bridge client that try to weaken safeguards-related settings, and to strip forwarded plugin-marketplace or safeguard settings unless the connection's capabilities explicitly allow them. A new default-capabilities object turns `remoteTools`, `hooks`, `plugins`, and `safeguards` off by default.\n\n- The remote transport's flag-settings trust object also gained a `safeguards` trust category, deciding whether an untrusted or unverified peer may disable safeguards via `apply_flag_settings`; any below-floor change that can't be verified is dropped and logged rather than applied.\n\n- A new no-op event-filter hook now runs on every incoming bridge session frame before existing verification logic; it currently does nothing but is now part of the frame-handling pipeline.\n\n**Why** This lays the groundwork for treating \"safeguards\" (the model's safety classification data) as its own protected capability, matching how remote tools, hooks, and plugins are already gated, so a remote\/bridge connection can't silently weaken or disable safety-related settings unless explicitly trusted to. The actual checklist of settings this protects is currently empty, so the gate exists but doesn't yet block anything in this build.\n\n- Area: Remote Control\n- Tier: Nothing to try yet\n- Useful: 3\/5\n- Signal: 3\/5\n- Present in the build but not switched on"}