›_ Codex Issues
Codex Issues / #15463

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

Open 💬 3 comments Opened Mar 22, 2026 by Serg2000Mr
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 5 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #13232

Powered by Codex Action

etraut-openai contributor · 5 months ago

If you're able to repro this, please use /feedback to upload your logs and session details, then post the thread ID here.

fujikento · 4 months ago

Reproduces with Japanese (CJK) workspace paths as well — same root cause.

Repro

  • codex-cli 0.120.0 on macOS (Darwin 25.3.0)
  • cwd = /Users/<user>/独自スキル (UTF-8 multi-byte chars)
  • Any codex exec ... invocation

Observed error (repeats 5× on Reconnecting...):

ERROR codex_api::endpoint::responses_websocket: failed to connect to websocket:
UTF-8 encoding error: failed to convert header to a str for header name
'x-codex-turn-metadata' with value:
"{...\"workspaces\":{\"/Users/<user>/\xe7\x8b\xac\xe8\x87\xaa\xe3\x82\xb9\xe3\x82\xad\xe3\x83\xab\":{...}}..."
url: wss://chatgpt.com/backend-api/codex/responses

The header value embeds the raw UTF-8 bytes of the CJK path (独自スキル → \xe7\x8b\xac\xe8\x87\xaa\xe3\x82\xb9\xe3\x82\xad\xe3\x83\xab), which fails HTTP header validation (http::header::HeaderValue requires visible ASCII).

Eventually falls through after 5 retries and the request completes, but adds ~5–10s latency per invocation and pollutes stdout.

Suggested fix: percent-encode (or base64-encode) the x-codex-turn-metadata payload before inserting into the header, since the workspace path is user-controlled and can contain any Unicode. This matches the broader class of CJK / Cyrillic / emoji / other non-ASCII paths.

Workaround until fixed: rename the workspace to an ASCII-only path.