{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiapbdp6xzjxfyf3secvf6x3oyfy6x7zlwho5sgjizcz2i5abb2kji",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3monbdsxka2y2"
  },
  "path": "/t/codex-on-windows-utf-8-mojibake-and-patch-context-mismatch-issues/1384116#post_2",
  "publishedAt": "2026-06-19T09:49:11.000Z",
  "site": "https://community.openai.com",
  "tags": [
    "OpenAI Codex",
    "github.com/openai/codex",
    "Windows PowerShell UTF-8 Markdown files can render as mojibake in agent context, causing patch mismatch and unreliable edits",
    "Gyropilot2"
  ],
  "textContent": "Welcome to the forum!\n\nYou are welcome to discuss Codex issues on the forum, however the official place to report and track them is the GitHub issue tracker for OpenAI Codex.\n\nI had ChatGPT look for the closest related issue and it identified:\n\ngithub.com/openai/codex\n\n####  Windows PowerShell UTF-8 Markdown files can render as mojibake in agent context, causing patch mismatch and unreliable edits\n\nopened 09:39PM - 21 Mar 26 UTC\n\nclosed 09:52PM - 21 Mar 26 UTC\n\n\n\n          Gyropilot2\n        \n\nbug  windows-os  CLI  tool-calls\n\n## Problem On Windows with PowerShell 5.1, UTF-8 Markdown files sometimes showe…d up as mojibake in the agent/tool context even though the files themselves were valid UTF-8 on disk. Typical example: - `—` showing up as `—` This made patch-based edits unreliable, because the tool seemed to be matching against the misdecoded text it was seeing rather than the real file contents. ## What I observed The strange part was that the file was not actually corrupted. - Normal agent/shell context could show mojibake - `Get-Content -Encoding utf8 <file>` showed the file correctly - hex inspection confirmed the file bytes were valid UTF-8 So the problem looked less like “the file was broken” and more like “the tool/context path was decoding it incorrectly.” ## Environment - Windows - PowerShell 5.1 - Initial code page: `437` - Initial console input encoding: `IBM437` - Initial `$OutputEncoding`: `us-ascii` ## Why this matters When the displayed context is wrong, patch/edit operations can fail even though the file itself is fine. This was especially painful with large `.md` files, because the agent could end up seeing mojibaked context, fail to match hunks, and behave as if the file content were different from what was really on disk. ## How I worked around it These local environment changes helped a lot: - `chcp 65001` - set console input/output encoding to UTF-8 - set `$OutputEncoding` to UTF-8 After that, UTF-8 reads and edit verification behaved much more reliably. ## Expected behavior The tool should read UTF-8 files correctly for context and patch matching regardless of Windows shell/codepage defaults, or at least use a deterministic UTF-8 file-reading path instead of inheriting console encoding behavior. ## Possible related issue There may also be a separate Windows issue where editing Markdown can normalize line endings in touched regions. That was much less serious than the mojibake problem, but it showed up during the same debugging session.\n\nThis does not appear to be a typical issue. Many non-English users are reporting similar problems as separate new issues, making it difficult to find an exact match for yours.\n\nIf that issue matches your problem, consider adding a  reaction on the GitHub issue page itself, not just on the forum topic, as reactions on GitHub help the developers gauge impact and prioritize work.\n\nIf it is not the same issue, try searching the existing GitHub issues for a closer match. If you cannot find one, then open a new issue with as much detail as possible.",
  "title": "Codex on Windows: UTF-8/mojibake and patch-context mismatch issues"
}