{"version":"2.1.281","anchor":"permission-request-telemetry-adds-a-mode-stamp","canonical_anchor":"permission-request-telemetry-adds-a-mode-stamp","heading":"Remote session requests carry a modeStamp, and serve-only clients stay silent on unsupported requests","tier":"internal","area":"Telemetry","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281\/e\/permission-request-telemetry-adds-a-mode-stamp","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281","markdown":"### Remote session requests carry a modeStamp, and serve-only clients stay silent on unsupported requests\n\nPermission-request metadata and served remote channel requests now include a modeStamp, and control-only clients no longer answer unsupported requests with errors\n\n**Unclear.** The finding does not say what `remote_tool_gate` being `caller_reauthored` means for a user.\n\n**What**\n\nWork on remote sessions, where Claude Code is driven from another machine or program, added a `modeStamp` marker and changed how some clients reply.\n\n- Metadata attached to permission requests from hook callbacks now records `modeStamp`: \"present\" when `remote_tool_gate` is `caller_reauthored`, otherwise \"other\". It is recorded even without device attestation; before, the metadata was empty in that case.\n\n- Requests served over a remote session channel now carry `modeStamp`.\n\n- Clients configured as `controlOnly` now leave requests they do not support unanswered. Before, they always replied with an 'Unsupported control request subtype' error.\n\n**Why**\n\nFor people hosting remote sessions, a serve-only client no longer sends error replies to requests it was never meant to handle. The `modeStamp` field mainly supports reporting for the remote-tools work.\n\n- Area: Telemetry\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 3\/5"}