{"version":"2.1.239","anchor":"remote-sessions-can-re-enroll-a-device-after-a-403-and-retry","canonical_anchor":"remote-sessions-can-re-enroll-a-device-after-a-403-and-retry","heading":"Remote sessions can re-enroll a device after a 403 and retry","tier":"notice","area":"Device Trust","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.239\/e\/remote-sessions-can-re-enroll-a-device-after-a-403-and-retry","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.239","markdown":"### Remote sessions can re-enroll a device after a 403 and retry\n\nRemote session events no longer get dropped when the server rejects an untrusted device; it re-enrolls and retries.\n\n**What**\n\nEvent uploads for remote sessions now send a trusted-device token, and when the server refuses with a 403 for an untrusted device the client can re-enroll and try again rather than dropping the events. Telemetry separates this case from an ordinary success.\n\n**Details**\n\n- Parsing the refusal body is behind the `tengu_violin_wood` gate, which falls back to off, so on a stock build the retry path does not engage.\n\n**Evidence**\n\n`remote_send_event_untrusted_device`\n\n- Flag `tengu_violin_wood`: Off in both readings (read for one account on one subscription tier against v2.1.239; this account: off, anonymous baseline: off, compiled default: off)\n- Area: Device Trust\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 3\/5"}