{"version":"2.1.280","anchor":"cloudremote-session-serve-link-signing-becomes-request-scop","canonical_anchor":"cloudremote-session-serve-link-signing-becomes-request-scop","heading":"Cloud\/remote session serve-link signing becomes request-scoped","tier":"internal","area":"Sessions","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280\/e\/cloudremote-session-serve-link-signing-becomes-request-scop","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280","markdown":"### Cloud\/remote session serve-link signing becomes request-scoped\n\nThe link used to serve a device from Claude Code's cloud\/remote sessions can now be signed per-request instead of with one plain signature\n\n**Unclear.** The finding does not say what user-visible effect, if any, this has, or why request-scoped signing was introduced.\n\n**What**\n\nThe internal flow that creates a serving link for a cloud or remote session (`linkForServing`) now carries along a `request` value, built from the session's own startup data, and passes it into a new step called `signRequest`. The signer behind this (previously called `Yn`, now `ns`) can then sign either the plain way or in a way that is tied to the specific request, depending on whether a request was given.\n\n**Why**\n\nThis is an internal change to how serve links are signed, tying a signature more closely to the specific session request rather than reusing a generic signature. It has no direct setting or command for readers to use, but it affects the security plumbing behind device-serving links for cloud and remote sessions.\n\n- Area: Sessions\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 2\/5"}