{"version":"2.1.277","anchor":"takeuserframereceivedwallms-is-a-no-op-on-the-baselocal-ses","canonical_anchor":"wall-clock-tracking-of-when-user-frames-arrive-over-the-wire","heading":"Remote sessions now track wall-clock arrival time of incoming user messages","tier":"internal","area":"Remote Control","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.277\/e\/takeuserframereceivedwallms-is-a-no-op-on-the-baselocal-ses","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.277","markdown":"### Remote sessions now track wall-clock arrival time of incoming user messages\n\nClaude Code's remote transport now records when user messages actually arrive over the wire, feeding new latency telemetry\n\n**What**\n\nThe remote transport used for Remote Control sessions now tracks, per message, the wall-clock time a user message frame actually arrived over the wire. It does this through a new transport callback, `setOnUserFrameReceived`, which populates a bounded map of arrival timestamps, and a method, `takeUserFrameReceivedWallMs`, that reads and clears the timestamp for a given message.\n\nThe base (local, non-remote) session read-loop class also gained a `takeUserFrameReceivedWallMs` method, but it always returns `undefined` there since there's no network transport to time. Only the remote-transport subclass has the real implementation.\n\n**Why**\n\nThis timestamp feeds into other latency telemetry (such as flag-settle timing), letting Claude Code measure delays specific to remote sessions without affecting local sessions, which have no equivalent network hop to measure.\n\n- Area: Remote Control\n- Names: `takeUserFrameReceivedWallMs`\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}