x-codex-turn-metadata UTF-8 decode failure on reconnect when workspace path contains Cyrillic characters

x-codex-turn-metadata UTF-8 decode failure on reconnect when workspace path contains Cyrillic characters

Summary

In the VS Code extension Codex – OpenAI’s coding agent from OpenAI
(openai.chatgpt), streaming reconnect fails on Windows when the workspace
path contains Cyrillic characters. The extension UI repeatedly shows
Reconnecting... and logs a UTF-8 header decoding error for
x-codex-turn-metadata.

The failure appears to be triggered by serialized workspace metadata in an HTTP
header during reconnect handling.

Environment

• Extension id: openai.chatgpt
• Marketplace name: Codex – OpenAI’s coding agent
• Publisher: OpenAI
• Extension version: 26.318.11754
• VS Code: 1.111.0
• OS: Windows
• UI locale: ru-RU
• System locale: ru-RU
• ANSI code page: ACP=65001
• OEM code page: OEMCP=65001
• Windows setting enabled:

Beta: Use Unicode UTF-8 for worldwide language support

• Workspace path:

C:\1C\Выгрузки баз\УТ

Steps To Reproduce

1. Open the Codex extension in VS Code on Windows.
2. Use a workspace whose absolute path contains Cyrillic characters, for

example: C:\1C\Выгрузки баз\УТ.

1. Start a prompt that produces a long enough streamed response for reconnect

logic to kick in.

1. Wait until the UI shows Reconnecting....

Actual Result

• The extension retries reconnect several times: Reconnecting... 2/5, 3/5,

4/5, 5/5.

• Each retry shows the same error:

stream disconnected before completion: UTF-8 encoding error: failed to convert
header to a str for header name 'x-codex-turn-metadata'

• The header value shown in the error contains serialized metadata with

workspaces, including the current workspace path.

• The Cyrillic path appears as escaped UTF-8 byte sequences like \xd0....
• The streamed response does not recover cleanly.

Expected Result

• Reconnect should succeed even when workspace paths contain non-ASCII

characters.

• Internal metadata should not break stream recovery.
• Workspace paths with Cyrillic characters should be handled the same way as

ASCII-only paths.

Notes

• This is not a model-output issue. The failure points to reconnect transport

/ metadata handling.

• The problem is likely related to non-ASCII data being passed through

x-codex-turn-metadata and then decoded incorrectly on reconnect.

• I cannot confirm the exact root cause from source, but the error strongly

suggests header encoding/decoding around workspace metadata.

Workaround

Opening the same project through an ASCII-only path should be tested as a
workaround, for example via a junction/symlink such as C:\UT.

If the problem disappears in that setup, it would further confirm that the
trigger is non-ASCII workspace metadata rather than the prompt itself.

Suggested Investigation

• Check how x-codex-turn-metadata is serialized during streamed reconnect.
• Verify whether workspace paths are embedded in that header as raw JSON.
• Avoid putting Unicode-heavy metadata into HTTP headers, or encode it in an

ASCII-safe form.

• Test reconnect behavior on Windows with:
• ASCII-only workspace path
• Cyrillic workspace path
• ACP/OEMCP=65001
• ACP/OEMCP non-UTF-8