{"version":"2.1.259","anchor":"cloud-device-hooks-bridge-gains-a-muted-state","canonical_anchor":"cloud-device-hooks-bridge-gains-a-muted-state","heading":"Cloud device-hooks bridge gains a \"muted\" state","tier":"soon","area":"Cloud Sessions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.259\/e\/cloud-device-hooks-bridge-gains-a-muted-state","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.259","markdown":"### Cloud device-hooks bridge gains a \"muted\" state\n\nThe cloud device-hooks bridge gains a muted phase that unregisters from the cloud session and restores registration on unmute.\n\nThe cloud device-hooks bridge used by `claude --cloud` now supports a distinct `muted` phase, separate from stopped, idle, and registered. A new `servingMute` method transitions the bridge into `{kind:\"stopped\", reason:\"muted\"}`, unregisters and releases the current registration with the cloud session, and logs a `muted` outcome; unmuting restores registration and clears the `muted` note.\n\nThe device-hooks client-register flow also recognizes `muted` as an outcome alongside `registered`, `unregistered`, `dormant`, and `no_consent`, routed through the same success-telemetry path, with a `servingMuted` flag threaded through to consumers. Plugin-forwarding feature status reporting now reports muted state as `{ state: \"off\", source: \"stored\", reason: \"muted\" }`, distinct from `declined`, `unreadable`, or `could_not_send`.\n\n- Area: Cloud Sessions\n- Names: `claude --cloud`, `servingMute`\n- Tier: Nothing to try yet\n- Useful: 3\/5\n- Signal: 4\/5\n- Present in the build but not switched on"}