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
- Create a session and subscribe to
ExternalToolRequestedEvent.
- Dispatch the tool asynchronously — the event handler cannot await it, so the dispatch is fire-and-forget.
- Dispose the session while a dispatch is still in flight, for example because the turn was cancelled by a deadline.
- 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.
Environment:
@github/copilot1.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 with0xC0000005(access violation) rather than failing the operation.The final two frames are the process-level handler, so there is nothing left to catch it.
Reproduction shape
ExternalToolRequestedEvent.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/writeLogreach 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 insidehandleErrorinstead 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.