Unhandled "provider is closed" inside the runtime's own error handler terminates the host process

Start with the napi-oop-runtime error path shown in dist/index.js and the filterSecrets, writeLog, and handleError frames in app.js; reproduce an in-flight tool dispatch followed by session disposal. Done means a post-close failure is reported without recursively using the closed provider, and the host remains running with a catchable operation failure.

Environment: @github/copilot 1.0.71 (win32-x64), Node v24.16.0, .NET 8 host embedding the SDK in-process (napi-oop-runtime).

Summary

When a tool-call result is written to a session after its provider has been closed, the runtime raises Error: provider is closed. Its error handler then logs that failure through the same closed provider, which throws a second time inside the handler. That second throw is unhandled and terminates the host process with 0xC0000005 (access violation) rather than failing the operation.

Error: provider is closed
    at Object.call (napi-oop-runtime/dist/index.js:68:2208)
    at Proxy.S (napi-oop-runtime/dist/index.js:68:3671)
    at t.filterSecrets (app.js:114:26376)
    at wR.filterSecrets (app.js:143:52707)
    at wR.error (app.js:651:10732)
    at wR.writeLog (app.js:652:163)
    at Hle.logToLevel (app.js:61:1536)
    at Hle.error (app.js:61:1719)
    at t.handleError (app.js:5076:625)
    at process.<anonymous> (app.js:5076:360)

The final two frames are the process-level handler, so there is nothing left to catch it.

Reproduction shape

1. Create a session and subscribe to ExternalToolRequestedEvent.
2. Dispatch the tool asynchronously — the event handler cannot await it, so the dispatch is fire-and-forget.
3. Dispose the session while a dispatch is still in flight, for example because the turn was cancelled by a deadline.
4. The dispatch completes and calls session.Rpc.Tools.HandlePendingToolCallAsync(...) on the now-closed session.

Observed reliably on a long-running host that creates one session per turn against a process-wide client.

Impact

The whole host process dies, not just the affected session. For a service embedding the SDK, every concurrent operation in that process is lost, and the failure surfaces as a process exit rather than an exception the caller can handle. A caller cannot defend against this in managed code either, since an access violation is not catchable.

Suggested fix

Make the error-handling path resilient to a closed provider. filterSecrets / writeLog reach back into the provider while handling an error that the provider itself raised; falling back to a local sink when the provider is unavailable would keep the secondary failure inside handleError instead of letting it escape.

More generally, an error raised because a resource is closed should not be reported through that same resource.

Workaround

On the caller side: gate any post-dispatch write on session liveness, and drain in-flight dispatches before disposing the session. That removes the trigger but not the underlying fragility — any other error raised after provider close will still terminate the process.