Renderer OOM in JSON.stringify / serializeRequestArguments when invoking agent with large chat history

I'm sorry, I can't do the extension bisect, it's not something I have bandwidth for, nor repro is stable. Dump is available, feel free to ping.
Copilot generated based on dump

# Renderer OOM in JSON.stringify / serializeRequestArguments when invoking agent with large chat history

Does this issue occur when all extensions are disabled?: Not tested. The observed workflow uses Copilot Chat with tools; extension bisect has not been performed.

## Environment

- VS Code: 1.137.0, Windows x64.
- Electron: 42.10.0.
- OS build reported by the dump: 10.0.26200.9448.
- Affected process: workbench window renderer, not the extension host.
- Renderer uptime: approximately 47 hours.
- Separate Copilot extension version at crash time: not captured in this analysis.
- Latest Insiders reproduction: not tested.

## Summary

A renderer terminated with an out-of-memory exception while serializing a chat-agent invocation. The Crashpad V8 annotation records `JSON.stringify` reached through `serializeRequestArguments`, `_remoteCall`, and the chat agent invocation path. This is not a session-save stack.

The JavaScript heap was using approximately 1,571 MiB of its 4,096 MiB limit. V8's main memory cage reported `ran out of reservation`, despite approximately 2,405 MiB free in aggregate; the largest contiguous free region was only 477 MiB.

## Observed Workflow

1. Use a long-running local Copilot Chat conversation with many tool calls, including multi-megabyte text results.
2. Restore the accumulated conversation and continue interacting with chat.
3. A chat-agent invocation reaches RPC argument serialization, and the renderer terminates with OOM.

This describes one investigated crash and its surrounding workflow, not a deterministic minimal reproduction. The exact allocation size and the smallest triggering history have not been established.

Expected: Large retained chat data is bounded, externalized, streamed, or rejected with a recoverable error before a renderer-fatal allocation.

Actual: The entire workbench window renderer terminates. The parent log reports:

```text
CodeWindow: renderer process gone (reason: oom, code: -536870904)
```

## Crash Evidence

Native exception: `0xE0000008`, raised through `KERNELBASE!RaiseException`.

Captured V8 annotation, with installation URLs removed and bundle locations retained:

```text
v8-oom-location = CALL_AND_RETRY_LAST
v8-oom-stack:
stringify
iLn workbench.desktop.main.js:5647:46424
serializeRequestArguments workbench.desktop.main.js:5647:56342
_remoteCall workbench.desktop.main.js:5647:52150
workbench.desktop.main.js:5647:48744
invoke workbench.desktop.main.js:1078:25074
invokeAgent workbench.desktop.main.js:1034:29884
j workbench.desktop.main.js:3371:35341
```

| Crash annotation | Value |
| --- | --- |
| Heap used | 1,571.1 MiB |
| Heap limit | 4,096 MiB |
| Heap utilization | 38.3% |
| Main cage last allocation status | ran out of reservation |
| Main cage largest free region | 477 MiB |
| Main cage total free | 2,405 MiB |
| Main cage size | 4,096 MiB |
| Last OS error | 0 |

Two last-resort Mark-Compact collections left live heap usage essentially unchanged at approximately 1,570.6 MiB. These annotations support a contiguous-reservation failure inside the V8 cage, not merely reaching the configured heap limit. They do not measure total machine memory pressure or identify the exact failed allocation size.

## Supporting History Evidence

The conversation restored shortly before the crash had an approximately 509 MB JSONL session file when inspected afterward. Its initial snapshot was approximately 476 MB and contained 141 requests. These are decimal file sizes; the file was modified after the crash and is not an exact crash-time payload capture.

Inspection of that snapshot, reporting aggregate sizes only, found:

- Approximately 256 million string characters under request response content.
- Approximately 127 million string characters under request result metadata.
- One tool result of approximately 15.8 million characters was identical in a serialized tool-display entry and in `result.metadata.toolCallResults`.

The installed bundle's `getHistoryEntriesFromModel` forwards each included prior response's `result` into invocation history. The chat bridge calls `$invokeAgent(handle, request, { history, chatSessionContext }, token)`, and the captured serializer branch calls `JSON.stringify` on the argument array.

Important distinction: the response-history filter excludes `toolInvocation` and `toolInvocationSerialized` display entries. The duplicated text is confirmed in persisted storage, not proven to be transmitted twice over RPC. Result metadata is still forwarded. Persisted size is not equivalent to RPC payload size.

The large retained history is a strong candidate for the serialization failure, but the minidump does not establish the exact triggering field, complete object graph, or failed allocation size. A fix may involve both core chat/RPC handling and the producer of retained tool-result metadata.

## Related Issues

- #305122: Workbench OOM during session storage; closed with a fix, milestone 1.122.0. Its documented stack is `writeSession` / mutation-log extraction, unlike this invocation/RPC stack.
- #311225: Open report of Copilot Chat memory growth and crashes. A maintainer notes chat-terminal memory improvements; this report adds a specific RPC serialization failure path.
- #332725: Open report of renderer and extension-host OOM during concurrent Copilot sessions; similar symptom, but the same serialization cause is not established.

No exact match was identified in the issue searches performed. Please merge or redirect this report if the invocation-serialization failure is already tracked.