openai
Broken shell step preview in VSCode's chat window
What version of Codex is running?
0.53.0
What subscription do you have?
Plus
Which model were you using?
gpt5-codex
What platform is your computer?
Win 11 10.0.26200.0 ARM64 + WSL Fedora 42
What issue are you seeing?
What steps can reproduce the bug?
run codex exec "пример", the chat's preview window of VSCode extension, it is going to show some weird characters, no matter fonts or locale availability.
What is the expected behavior?
correct text encoding, accordingly to OS fonts and locale availability, same as in the VSCode's built-in terminal window.
Additional information
Able to reproduce locally on demand if needed
@nos1609 Out of curiosity, was this running anything whether the output may have been binary or had any special encoding?
Is it possible for you to find the corresponding .jsonl file under ~/.codex/sessions and could you share the content if it's not sensitive? Perhaps then we could at least figure out what command it was running?
@bolinfest here you go, a new example
$ bash -lc 'prompt="$(< tmp/assistant_contexts/20251104-anaconda.txt)"; (HOME=$PWD/tmp/codex_home XDG_CONFIG_HOME=$PWD/tmp/codex_home/.config codex exec "$prompt" --output-last-message tmp/assistant_contexts/responses/codex.txt) & wait'
2025-11-04T15:54:40.792590Z WARN codex_core::project_doc: Project doc `/home/nos1609/myawesomeproject/AGENTS.md` exceeds remaining budget (32768 bytes) - truncating.
OpenAI Codex v0.53.0 (research preview)
--------
workdir: /home/nos1609/myawesomeproject
model: gpt-5-codex
provider: openai
approval: never
sandbox: workspace-write [workdir, /tmp, $TMPDIR]
reasoning effort: medium
reasoning summaries: auto
--------
user
ÐонÑекÑÑ:
- Rocky Linux 10 ÑÑÑановка ÑеÑез Anaconda из iPXE.
- ÐенеÑиÑÑем kickstart ÑкÑипÑом `generate_ks.sh`; диÑк вÑбиÑаеÑÑÑ Ð°Ð²Ñо (`PRIMARY_DISK`), ÑазмеÑка в %pre запиÑÑваеÑÑÑ Ð² /tmp/ks-disk.cfg.
- ÐоÑле запÑÑка iPXE и загÑÑзки Anaconda видим в `anaconda.log`:
- `15:00:47,992 ERR kickstart.parsing: the following arguments are required: -- name`
- ÐÑÑалÑной лог ÑказÑваеÑ, ÑÑо %pre-ÑкÑÐ¸Ð¿Ñ Ð²ÑполнилÑÑ ÑÑпеÑно, диÑки опÑеделилиÑÑ (`sda`), bootloader Ñежим ENABLED, custom partitioning Ñоздан.
- Ð kickstart (`build/ks.cfg`) диÑекÑоÑов `part` ÑоздаÑм Ñ Ñлагами `--label=... --name=...`, пÑÐ¸Ð¼ÐµÑ Ð´Ð»Ñ BIOS:
part biosboot --fstype=biosboot --size=1 --ondisk=${PRIMARY_DISK} --label=BIOSBOOT --name=biosboot part /boot --fstype=xfs --size=1024 --ondisk=${PRIMARY_DISK} --label=BOOT --name=boot part swap --fstype=swap --size=${SWAP_SIZE} --ondisk=${PRIMARY_DISK} --label=SWAP --name=swap part / --fstype=xfs --size=1 --grow --ondisk=${PRIMARY_DISK} --label=ROOT --name=root
- `%include /tmp/ks-disk.cfg` подклÑÑаеÑÑÑ Ð¿Ð¾Ñле %pre; никакиÑ
`logvol`/`volgroup` неÑ.
- ÐолÑзоваÑелÑÑкие паÑамеÑÑÑ (hostname, ipv4/6) подÑÑавлÑÑÑÑÑ ÐºÐ¾ÑÑекÑно.
ÐадаÑа:
- ÐонÑÑÑ, поÑÐµÐ¼Ñ Anaconda вÑÑ ÐµÑÑ ÑÑебÑÐµÑ `--name` и на какой команде ÑÑо ÑÑабаÑÑваеÑ.
- ÐÑедложиÑÑ Ð¼Ð¸Ð½Ð¸Ð¼Ð°Ð»ÑнÑе пÑавки Ñаблона или генеÑаÑии, ÑÑÐ¾Ð±Ñ ÑÑаÑно пÑойÑи паÑÑинг Kickstart.
- Ðо возможноÑÑи подÑвеÑдиÑÑ, нÑжно ли добавлÑÑÑ `--name` к `clearpart`/`ignoredisk` или каким-Ñо дÑÑгим ÑÑÑноÑÑÑм, либо пеÑеклÑÑиÑÑÑÑ Ð½Ð° `part --asprimary`/`reqpart`.
ÐгÑаниÑениÑ:
- Kickstart ÑоÑмиÑÑеÑÑÑ Ð´Ð¸Ð½Ð°Ð¼Ð¸ÑеÑки в %pre (Anaconda 40.13/Rocky 10).
- Ð rescue окÑÑжении Ð½ÐµÑ ÑÑилиÑÑ `tee`, иÑполÑзÑем ÑолÑко POSIX-Ñелл.
Also noted a "self-fixing" behavior - once completed the task, review shows text in correct encoding.
Worth mentioning, that @LIHUA919 description is accurate about the issue. https://github.com/openai/codex/pull/6182
@joshka-oai this appears to be a bad interaction between VS Code's integrated terminal on Windows and...non-Latin characters, maybe? Seems likely to be a decoding or escaping issue: can you investigate?
/cc @easong-openai
The linked PR seems reasonable, but I wonder In terms of sidestepping this issue rather than detecting and converting if it is reasonable / possible for codex to configure the shell to only output utf-8. Or is that not possible? Apologies in advance for my naive question here. It's likely that @nos1609 and @lihua919 are probably much more familiar with international code pages than I am here (there's a lot of unknown unknowns for me).
I don't see any issue with that, but I don't even know what could be more imperative for codex on Fedora than
LANG=en_US.UTF-8 as env, which is already the default encoding in WSL...
Maybe this might shed the light a bit, perhaps might be a VSCode/WSL issue https://github.com/MicrosoftDocs/windows-dev-docs/blob/docs/hub/apps/design/globalizing/use-utf8-code-page.md https://devblogs.microsoft.com/commandline/windows-command-line-unicode-and-utf-8-output-text-buffer/
Though haven't been able to reproduce this issue if just using the interactive mode in VSCode's terminal.
Thanks for those pointers. Seems like it might be exactly what we need to know. Will dive into them a bit later this week when time permits me to dive into Windows mode.
Maybe this might shed the light a bit, perhaps might be a VSCode/WSL issue
I was thinking more about this point and it didn't click to me what you meant here until now. My understanding is that VSCode will inherit the Codepage of the process that launched it. Can you perhaps try launching VSCode directly (i.e. not from a console) and see if you still hit this same problem?
If that does fix things, it might be good to diagnose / provide some more details about the steps to launch. What I'd like to see is what locales you're seeing anywhere in the path of launch through to the command. (E.g. you ran terminal, chose powershell, ...) I haven't yet tested this on windows as yet, so I'm not sure if this is an always reproducible problem or one that's specific to a machine setup in an international locale.
launching VSCode directly (i.e. not from a console)
That was the way, but it also launched "nested" codex-cli in full access mode. I might try to reproduce that with another command like cat or something else outputting non utf-8 text in a codex chat step.
I've also made a separate "native" node.js outside of WSL to solve such things, going to try to reproduce it there also, in a more straight-forward VSCode setup.
Over in https://github.com/openai/codex/pull/6182 there's a potential fix for this. Would you be ok with taking a look to see if that addresses your problem?
@nos1609, the PR that attempts to fix this should be in the next published release.
An example on a system with en-US locale, seems a bit different, hope it'll be fixed by that PR