Remote dispatch namespace binding opens an unused capnweb WebSocket on every get(), counted as scriptThrewException under the Worker's name

Finding: In an external report on cloudflare/workers-sdk issue 16072, local development with a remote dispatch namespace binding (dispatch_namespaces[].remote: true) on wrangler 4.146.0 (miniflare 5.20261001.0-alpha, workerd 1.20261001.1) is said to log "Error: Network connection lost." for every env.NS.get(name).fetch() call (https://github.com/cloudflare/workers-sdk/issues/16072). This is an external report; KFA did not reproduce it. Reported conditions: macOS 26.6.2, Node v24.19.0, wrangler via unstable_startWorker, and @cloudflare/vite-plugin 2.0.0-beta with miniflare 5.20260930.0-alpha. The reporter says the same code was still on main as of 2026-10-06 (https://github.com/cloudflare/workers-sdk/issues/16072). Reported mechanism: the reporter says DispatchNamespaceProxy.get() returns makeRemoteProxyStub, which immediately calls newWebSocketRpcSession. The fetch itself then goes over plain HTTP, so the WebSocket goes unused and is dropped when the local request ends. The reporter says this also shows up remotely. The remote proxy runs as an edge preview under the Worker's own name with an empty scriptVersion, and each call is recorded as one scriptThrewException in GraphQL Analytics. In one project, the reporter counted 377 of 2,238 invocations in 24 hours under the production script name as these exceptions (https://github.com/cloudflare/workers-sdk/issues/16072). That figure is account-specific and unverified. The reporter notes that the generic remote-proxy-client.worker.ts already defers the RPC session so fetch-only bindings do not open an unused WebSocket, and suggests the dispatch path do the same by creating the session lazily on the first non-fetch property access. A comparison with env.AI.models() through getPlatformProxy, where the WebSocket is used, produced clientDisconnected invocations rather than exceptions (https://github.com/cloudflare/workers-sdk/issues/16072). Corroboration is limited. An automated LLM triage comment says it confirmed in a current-source checkout that makeRemoteProxyStub calls newWebSocketRpcSession eagerly while the other client defers it. Its runtime reproduction was blocked because no Cloudflare credentials were available (https://github.com/cloudflare/workers-sdk/issues/16072#issuecomment-6004369378). A later commenter made the same code observation on main and offered a patch (https://github.com/cloudflare/workers-sdk/issues/16072#issuecomment-6043033652). Status: the issue is open with no maintainer-confirmed cause, no fix commit and no released fix in the supplied sources. The lazy-session change is only a proposal. No workaround is documented. Treat the cause as a plausible hypothesis, not a confirmed root cause.