Large Codex chat restore stalls in JSON-RPC buffering and accessibility Markdown block counting

Opening large existing Codex chats in the native Agents window takes tens of seconds to minutes, affecting the Agents view across workspaces. Local profiling identified two expensive paths during restoration. - VS Code: stable 1.142.0, commit `6d62b1d5dace93a33b3a6d3eca1317bd5e15bcb1` - OS: macOS 27.0.1 (26A434), Apple Silicon, 64 GB RAM - Harness: Codex in the native Agents window - Nonstandard configuration: a local Codex SDK 0.161.0 override was already in use. This has not been independently reproduced with the bundled SDK. - All extensions disabled: not tested. Insiders: not tested. - No system memory pressure or swap exhaustion was observed during diagnosis. Steps that exposed the issue: 1. Use the native Agents window with a large existing Codex conversation containing Markdown and tool responses. 2. Select the pinned conversation, or restart VS Code and restore it. 3. Observe a long stall before the conversation becomes usable. Expected: selecting an existing conversation should remain responsive, with history loading and accessibility-label generation avoiding repeated work over large payloads. The affected conversations are private, so this report does not include an exact end-to-end transcript reproducer. The observations below and proposed synthetic tests are intended to help isolate the relevant code paths. **Observed hotspot 1: JSON-RPC stdout buffering** The Codex client's `_listenToStdout` callback repeatedly concatenates and scans a growing partial JSON-RPC response. When a large response arrives across many stdout chunks, bytes already seen are processed repeatedly. Approximately 90.7% of one hung Agent Host CPU sample was in this callback. A local experimental parser retained fragments and joined only complete messages. It passed 95 boundary, Unicode, ordering, and error checks. An isolated synthetic 32 MiB fragmented-response benchmark improved from approximately 2,023 ms to 35 ms. This is a microbenchmark, not an application-wide speedup claim. **Observed hotspot 2: accessibility Markdown block counting** The session renderer accessibility provider's `_getLabelWithInfo` uses the full Markdown lexer to count table and code blocks. A local trace attributed 47.6 seconds to `inlineTokens`, although this operation only needed top-level block counts. A local experimental replacement used `blockTokens` with equivalent CR/CRLF normalization for this count operation. It passed 6,637 count comparisons, including CommonMark and generated edge cases. An isolated synthetic 490,041-character case improved from approximately 2,863 ms to 4 ms with identical counts. The change was limited to accessibility block counting; the general visible Markdown-rendering path was unchanged. **Diagnostic workaround and limits** Both changes were applied locally in memory as version-checked temporary diagnostic workarounds, with the original signed application preserved. They are not upstream fixes. Afterward, three large pinned conversations loaded in approximately 1-5.5 seconds when selected in a running app. Full startup plus restoration of the largest conversation still took approximately 19 seconds. These are local observations, not controlled results across machines or a guarantee for other conversations. Suggested maintainer validation: 1. Feed the JSON-RPC receiver one large valid message split across many small chunks. Also cover multiple lines per chunk, CRLF, Unicode boundaries, and malformed lines followed by valid lines. Verify ordering and error behavior. 2. Exercise accessibility labels on large synthetic Markdown payloads with expensive inline emphasis/link patterns. Compare table/code block counts and resulting label contents. 3. Validate normal and screen-reader modes, active streaming, switching conversations, and cold startup. The local comparison checks do not replace upstream regression testing. Potentially related: #342794 describes Codex output-related heap growth, and #337688 describes large Claude history restoration causing OOM. This report concerns measured CPU stalls in stdout buffering and accessibility block counting; it does not establish the same cause as either OOM report. Only sanitized aggregate measurements and software/hardware version information are included. No chat history, private project details, user paths, session identifiers, credentials, raw traces, or attachments are included.