{"version":"2.1.236","anchor":"a-wire-format-for-forwarding-your-local-hooks-into-a-cloud-s","canonical_anchor":"a-wire-format-for-forwarding-your-local-hooks-into-a-cloud-s","heading":"A wire format for forwarding your local hooks into a cloud session, with nothing sending it","tier":"soon","area":"Cloud Sessions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.236\/e\/a-wire-format-for-forwarding-your-local-hooks-into-a-cloud-s","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.236","markdown":"### A wire format for forwarding your local hooks into a cloud session, with nothing sending it\n\nYour local hooks could be registered with a cloud session, but nothing sends the messages yet.\n\n**What**\n\nMessage shapes are defined for a `claude --cloud` client to register its local hooks with the cloud worker: an inventory of hooks by opaque id (command or HTTP, matcher, timeout, which settings file it came from), a list of vetted in-container templates pinned by sha256 digest, and a lease in seconds, answered with the project directory, working directory, lease expiry, accepted and ignored counts, and whether it replaced a previous owner.\n\n**Details**\n\n- Hooks deliberately not forwarded are counted by reason: after-edit hooks, unsupported kinds, plugin-supplied, managed, and other.\n- The hook callback request gained optional issue and deadline timestamps so a device can drop a stale or replayed delivery.\n- Nothing in the build constructs the registration message or reads the new timestamps; the only references are the definitions themselves and the list of commands a client may send. This is a protocol landed ahead of its implementation, so there is no flag to turn on.\n\n**Evidence**\n\n`register_device_hooks`\n\n- Area: Cloud Sessions\n- Names: `--cloud`\n- Tier: Nothing to try yet\n- Useful: 2\/5\n- Signal: 5\/5\n- Present in the build but not switched on"}