VS Code Remote-SSH: long thread shows malformed JSONL, active-writer conflicts, and StreamingMarkdown failures

What version of the IDE extension are you using?

openai.chatgpt@26.810.52044

What subscription do you have?

Pro plan

Which IDE are you using?

VS Code

What platform is your computer?

VS Code Remote-SSH; remote: Ubuntu 24.04, Linux 6.8.0-124-generic x86_64

What issue are you seeing?

In the Codex IDE extension running in VS Code over Remote-SSH, a long-running conversation persistently fails to render assistant responses. The UI displays “Markdown couldn't render” with a “Try again” button, even when the generated Markdown appears valid. Retrying or reloading the window does not reliably resolve it.

The remote Codex logs show three correlated failures:

1. Repeated StreamingMarkdown error-boundary failures (193 occurrences observed).
2. Session transcript parsing failures: “failed to parse line as JSON” and “EOF while parsing a string” for three transcript entries.
3. Repeated thread-store conflicts: “thread already has an active writer”.

The affected JSONL session was approximately 28.7 MB with 8,576 lines, and its largest entry was approximately 1.62 MB. Two Codex app-server processes were also present.

This appears to involve both the IDE extension’s Markdown webview renderer and the bundled app-server/session-persistence layer. The session contains confidential research content, so I have not attached the complete raw transcript.

What steps can reproduce the bug?

1. Open VS Code and connect to an Ubuntu 24.04 host using Remote-SSH.
2. Install and use the Codex IDE extension version 26.810.52044.
3. Create a Codex conversation and use it for many long-running tasks with large command/tool outputs until the session transcript becomes large (the affected session was approximately 28.7 MB).
4. Resume the same conversation after reconnecting or reloading VS Code. In the observed case, another VS Code extension host/app-server was also connected to the same remote host, resulting in two Codex app-server processes.
5. Ask Codex to generate a response containing normal Markdown, such as a table, inline math, bullet points, and local file links.
6. While the response is streaming, or immediately after it completes, the response is replaced by “Markdown couldn't render”.
7. Click “Try again” or run “Developer: Reload Window”, then reopen the same conversation. The rendering failure recurs.
8. Inspect the Codex extension logs. They contain StreamingMarkdown error-boundary entries, JSONL parsing errors (“EOF while parsing a string”), and “thread already has an active writer” conflicts.

I have not reproduced the problem in a new, short conversation. It appears specific to a large resumed session and may be made more likely by multiple extension hosts accessing the same thread.

What is the expected behavior?

Assistant responses should render correctly during and after streaming, including standard Markdown tables, lists, inline math, code, and local file links.

Resuming or reloading a long conversation should preserve the session without creating malformed JSONL records. If multiple VS Code extension hosts access the same thread, Codex should coordinate them safely or enforce a single writer rather than producing thread-store conflicts.

If an individual transcript record is malformed or the session exceeds a supported size, the extension should recover gracefully, skip or isolate the affected record, and display an actionable warning. It should not replace otherwise valid assistant responses with “Markdown couldn't render”.

Clicking “Try again” or reloading the window should restore rendering without requiring the user to abandon the conversation.

Additional information

_No response_