x-codex-turn-metadata header with non-ASCII git remote URLs causes 400 Bad Request on Azure OpenAI

I can reproduce a closely related variant of this issue on codex-cli 0.110.0 on macOS.

Environment:

• Codex CLI: codex-cli 0.110.0
• Platform: Darwin 25.0.0 x86_64 i386
• OS: macOS 26.0.1

In my case, the trigger is not a non-ASCII git remote URL. The trigger is a non-ASCII workspace path. The repository is located under a path containing Chinese directory names, specifically path segments such as 作业 and 实验室.

Masked log excerpt:

startup websocket prewarm setup failed: stream disconnected before completion: UTF-8 encoding error: failed to convert header to a str for header name 'x-codex-turn-metadata' with value: "{\\"turn_id\\":\\"<turn-id>\\",\\"workspaces\\":{\\"/Users/<user>/Library/Mobile Documents/com~apple~CloudDocs/作业/实验室/2024/<repo>\\":{\\"associated_remote_urls\\":{\\"origin\\":\\"git@github.com:<owner>/<repo>.git\\"},\\"latest_git_commit_hash\\":\\"<commit-hash>\\",\\"has_changes\\":true}},\\"sandbox\\":\\"none\\"}"

So this appears to be the same root cause at the x-codex-turn-metadata header layer, but with a different non-ASCII source: workspace path entries in workspaces[...], not only remote URLs.

Expected behavior: Codex should sanitize, omit, or otherwise avoid placing non-ASCII workspace metadata into HTTP/WebSocket headers.

If you haven't already done so, please report this to the Azure folks.

Thanks for the quick reply. Just to clarify, this repro is not using Azure OpenAI API. I'm using a Pro subscription with the standard Codex/OpenAI setup on codex-cli 0.110.0 on macOS.

I suspect my comment may have been easy to read as Azure-related because the original issue is about Azure, but in my case the trigger appears to be the non-ASCII workspace path metadata in x-codex-turn-metadata, not an Azure-specific remote URL or proxy issue.

Same mechanism: non-ASCII workspace path (not git remote)

Environment

• OS: Windows 10 (MSYS2/Git Bash)
• Codex CLI: latest (as of 2026-03-06)
• Workspace path: D:\CloudSync\download\ai-study 통합 (Korean characters 통합 = "unified")

Problem

The x-codex-turn-metadata HTTP header includes the CWD workspace path. When the workspace folder name contains non-ASCII characters (Korean UTF-8: \xed\x86\xb5\xed\x95\xa9), the header value violates RFC 7230 (ISO-8859-1 only), causing an encoding error.

This is the same root cause as the git remote URL issue reported here — Codex inserts raw non-ASCII bytes into HTTP headers without percent-encoding.

Trigger

The error surfaces when WebSocket connection fails with 1008 (Policy Violation) and Codex falls back to HTTPS. During HTTPS request header construction, the non-ASCII workspace path in x-codex-turn-metadata causes the failure.

Workaround

Renaming the workspace folder to ASCII-only characters resolves the issue.

Suggestion

All values injected into x-codex-turn-metadata (and any other HTTP headers) should be percent-encoded or Base64-encoded to handle non-ASCII paths safely. This affects:

• Git remote URLs (this issue)
• Workspace/CWD paths (this comment)
• Potentially any user-controlled path that enters header values

Related issues

• #13553 (non-ASCII user folder name)
• #13005 (Turkish characters)
• #13123 (Chinese filename URL encoding)
• #9580 (encoding patch failure)

I can reproduce a closely related variant on the Windows Codex app (26.306.996.0).

In my case the non-ASCII bytes are not coming from a git remote URL. They appear inside the workspaces object in x-codex-turn-metadata, where the workspace path itself is included.

What I see

• Streamed responses disconnect before completion.
• The client shows:

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

Error snippet

stream disconnected before completion: UTF-8 encoding error: failed to convert header to a str for header name 'x-codex-turn-metadata' with value: {"turn_id":"...","workspaces":{"E:\\\xe5\\x8d\\x95\\xe9\\x81\\x93\\xe6\\x9d\\xa8\\website-content\\Website":{"has_changes":true}},"sandbox":"none"}

Minimal repro

1. Open the Windows Codex client.
2. Open a workspace whose path contains non-ASCII characters.
3. Send a prompt and wait for a streamed response.
4. Observe the response hang/disconnect before completion.
5. Rename the non-ASCII path segment to ASCII and retry; streaming works.

This makes it look broader than non-ASCII git remote URLs: any non-ASCII value serialized into x-codex-turn-metadata may be able to break request/stream handling depending on the producer/client path.

Root Cause

TurnMetadataBag::to_header_value() in turn_metadata.rs serializes workspace
paths and git remote URLs directly into JSON via serde_json::to_string(). When
those strings contain non-ASCII characters (e.g. Japanese directory names such as
/home/ユーザー/プロジェクト, or Windows UNC paths like \\サーバー\共有), the
resulting JSON contains raw non-ASCII bytes.

RFC 7230 §3.2.6 restricts HTTP field values to visible US-ASCII characters.
Azure API Management enforces this strictly, returning 400 Bad Request with an
empty body when the header violates it.

Proposed Fix

Apply JSON Unicode escaping (\uXXXX) to any non-ASCII characters after
serde_json::to_string(), before the value is placed in the header. This keeps
the header ASCII-only while remaining fully transparent to any standard JSON
parser on the receiving side — no corresponding decoder is required.

The change is limited to two files:

codex-rs/core/src/turn_metadata.rs (+26 / -1)

impl TurnMetadataBag {
    fn to_header_value(&self) -> Option<String> {
        serde_json::to_string(self)
            .ok()
            .map(|json| escape_non_ascii_to_json(&json))
    }
}

fn escape_non_ascii_to_json(input: &str) -> String {
    use std::fmt::Write;
    let mut out = String::with_capacity(input.len());
    for ch in input.chars() {
        if ch.is_ascii() {
            out.push(ch);
        } else {
            let mut buf = [0u16; 2];
            let units = ch.encode_utf16(&mut buf);
            for &unit in units {
                write!(out, "\\u{unit:04X}").unwrap();
            }
        }
    }
    out
}

codex-rs/core/src/turn_metadata_tests.rs (+36 / -0) — regression test
verifying that a Japanese workspace path produces an ASCII-only header that
round-trips correctly through a standard JSON parser.

No other files need to change. I have a working implementation ready if the team
would like to invite a PR.

same issues, please fix

I can reproduce the same underlying issue in a different path-based case, not just non-ASCII git remote URLs.

Environment:

• Codex CLI: 0.116.0
• Platform: macOS 15.6.1 (Darwin 24.6.0, arm64)
• Terminal: tmux
• Model: gpt-5.4
• Auth: standard Codex/ChatGPT login flow

Observed behavior:
On every Codex interaction, the client first fails on the WebSocket transport and falls back to HTTPS with:

⚠ Falling back from WebSockets to HTTPS transport. stream disconnected before completion: UTF-8 encoding error: failed to convert header to a str for header name 'x-codex-turn-metadata' with value: "{\"turn_id\":\"...\",\"workspaces\":{\"/Users/.../\xe5...\":{...}},\"sandbox\":\"none\"}"\n```\n\nWhat seems to trigger it:\n- current working directory contains non-ASCII characters, for example a workspace path with Chinese characters\n- and/or Codex has previously persisted a non-ASCII workspace root in `~/.codex/.codex-global-state.json`\n\nImportant detail:\nThis reproduces even when the repo remote URL itself is plain ASCII. In my case the relevant non-ASCII data appears to be the workspace path included in `x-codex-turn-metadata`, not the git remote URL.\n\nMitigation I found locally:\n- removing the non-ASCII saved workspace roots from `~/.codex/.codex-global-state.json` reduces how often it happens\n- but opening Codex directly inside a non-ASCII path still reproduces it\n\nSo this looks like a broader bug: any non-ASCII value inside `x-codex-turn-metadata` can break the transport/header serialization path. It would be good to either encode/sanitize these values safely, or avoid putting workspace metadata with arbitrary filesystem paths into HTTP headers at all.

I previously suggested escaping non‑ASCII as \uXXXX in x-codex-turn-metadata as a short‑term mitigation. That is not an RFC violation, but it has readability and surrogate/double‑escape edge cases.

A safer short‑term fix is to Base64‑encode the header value (encode on send, decode on receive). Base64 yields an ASCII‑only header, avoids those edge cases, and only requires localized changes at the send/receive boundary. \uXXXX is an acceptable stopgap, but I strongly recommend following up with Base64. I can open a small PR to implement this and update tests.

@etraut-openai

I've successfully reproduced a very similar 400 Bad Request issue on Azure OpenAI as described in this thread, caused by non-ASCII characters in the workspace/project path (in my case, Japanese characters).

This seems closely related to Issue #15463 as well, where Cyrillic characters in the workspace path cause UTF-8 decode failures in the x-codex-turn-metadata header during reconnect/streaming.

Reproduction details:

• codex-cli version 0.116.0 / Codex VS Code Extension version 26.318.11754 (the same 400 Bad Request occurs with both)
• Feedback was submitted via the CLI (/feedback command)
• Azure OpenAI endpoint
• Workspace or project folder path contains Japanese characters (e.g., C:\git\日本語プロジェクト, C:\日本語フォルダ名\日本語プロジェクト.git)
• Any request that includes the metadata (even a simple prompt) fails immediately with 400 Bad Request
• Feedback upload thread ID: 019d1a73-09b7-7111-a604-f500a2160d5a

Both issues appear to share the same root cause: the x-codex-turn-metadata header includes unsanitized or improperly encoded non-ASCII (multi-byte) characters from the workspace path/git remote/etc., which Azure rejects as invalid headers (while the original OpenAI endpoint might tolerate it or decode differently).

Would it be possible to triage this together with #15463? Proper percent-encoding, base64 encoding, or sanitization of the path/metadata before placing it in the header should resolve both cases.

Happy to provide sanitized path examples, version details, or any additional logs if helpful. Thank you for looking into this!

fix it please