{"version":"2.1.242","anchor":"the-remote-tools-runtime-loads-as-a-separate-chunk-on-first-","canonical_anchor":"the-remote-tools-runtime-loads-as-a-separate-chunk-on-first-","heading":"The remote-tools runtime loads as a separate chunk on first use","tier":"soon","area":"Remote Tools","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.242\/e\/the-remote-tools-runtime-loads-as-a-separate-chunk-on-first-","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.242","markdown":"### The remote-tools runtime loads as a separate chunk on first use\n\nRunning tools on another machine now loads only when used, and its gate is off in this build.\n\n**What**\n\nThe machinery for running tools on another machine is fetched with a dynamic import and cached rather than being linked into the main bundle, keeping it off the startup path entirely while its gate is off.\n\n**Details**\n\n- If the import throws, the failure is logged and the loader resets, so a later access retries instead of staying broken.\n- With no runtime loaded, there is simply no remote tool host.\n\n**Evidence**\n\n`createRemoteToolHostsRuntime`\n\n- Area: Remote Tools\n- Tier: Nothing to try yet\n- Useful: 1\/5\n- Signal: 4\/5\n- Present in the build but not switched on"}