WebSocket connection fails with non-ASCII characters in workspace path

Bug

Codex CLI fails to establish WebSocket connections when the workspace path contains non-ASCII characters (e.g., CJK characters). The path is placed into the x-codex-turn-metadata HTTP header, which does not support non-ASCII bytes.

Reproduction

# Working directory contains Chinese characters: /Users/me/大山/shipping-analysis
codex exec "echo hello"

Error

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: "...com~apple~CloudDocs/\xe5\xa4\xa7\xe5\xb1\xb1/shipping-analysis..."

\xe5\xa4\xa7\xe5\xb1\xb1 is valid UTF-8 for 大山, but HTTP headers are restricted to visible ASCII (RFC 7230 §3.2.6). The connection retries 5 times and eventually falls back, but this adds ~10 seconds of delay to every single invocation.

Expected behavior

Non-ASCII path components in x-codex-turn-metadata should be percent-encoded or base64-encoded before being placed into the HTTP header.

Environment

• Codex CLI: v0.118.0
• OS: macOS 15.4 (Darwin 25.4.0)
• Auth: ChatGPT (Pro plan)
• Path: iCloud Drive path containing CJK characters

Workaround attempted

Creating an ASCII-only symlink does not help — Codex resolves symlinks to the real path internally.