{"version":"2.1.246","anchor":"remote-driven-file-reads-get-their-own-admission-and-re-veri","canonical_anchor":"remote-driven-file-reads-get-their-own-admission-and-re-veri","heading":"Remote-driven file reads get their own admission and re-verification path","tier":"internal","area":"Remote Execution","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.246\/e\/remote-driven-file-reads-get-their-own-admission-and-re-veri","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.246","markdown":"### Remote-driven file reads get their own admission and re-verification path\n\nReads from another session go through an admission check and re-verify the path after reading.\n\n**What**\n\nReads driven from another session now resolve the file through an admission check that must return \"admitted\", otherwise the read is refused back to the caller as an invalid request. After the bytes come off disk the path is checked again, and if it no longer points where it did, the cached read state is dropped and the caller is told to read again.\n\n**Details**\n\n- Remote-driven reads bypass the read-first guard-skip heuristic and the read dedup cache.\n- They also skip dynamic skill directory triggers, skip pending handover reads, and never open an IDE diff tab.\n- Local reads take none of these branches; the whole path is conditioned on the call carrying a remote-call context, with no flag involved.\n\n**Evidence**\n\n`Served file call refused at read time`\n\n- Area: Remote Execution\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 4\/5"}