Broken shell step preview in VSCode's chat window

@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
Ð^ZонÑ^BекÑ^AÑ^B:
- Rocky Linux 10 Ñ^CÑ^AÑ^Bановка Ñ^GеÑ^@ез Anaconda из iPXE.
- Ð^SенеÑ^@иÑ^@Ñ^Cем kickstart Ñ^AкÑ^@ипÑ^Bом `generate_ks.sh`; диÑ^Aк вÑ^KбиÑ^@аеÑ^BÑ^AÑ^O авÑ^Bо (`PRIMARY_DISK`), Ñ^@азмеÑ^Bка в %pre запиÑ^AÑ^KваеÑ^BÑ^AÑ^O в /tmp/ks-disk.cfg.
- Ð^_оÑ^Aле запÑ^CÑ^Aка iPXE и загÑ^@Ñ^Cзки Anaconda видим в `anaconda.log`:
  - `15:00:47,992 ERR kickstart.parsing: the following arguments are required: -- name`
  - Ð^^Ñ^AÑ^BалÑ^Lной лог Ñ^CказÑ^KваеÑ^B, Ñ^GÑ^Bо %pre-Ñ^AкÑ^@ипÑ^B вÑ^KполнилÑ^AÑ^O Ñ^CÑ^AпеÑ^Hно, диÑ^Aки опÑ^@еделилиÑ^AÑ^L (`sda`), bootloader Ñ^@ежим ENABLED, custom partitioning Ñ^Aоздан.
- Ð^R kickstart (`build/ks.cfg`) диÑ^@екÑ^BоÑ^@ов `part` Ñ^AоздаÑ^Qм Ñ^A Ñ^Dлагами `--label=... --name=...`, пÑ^@имеÑ^@ длÑ^O 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` подклÑ^NÑ^GаеÑ^BÑ^AÑ^O поÑ^Aле %pre; никакиÑ^E `logvol`/`volgroup` неÑ^B.
- Ð^_олÑ^LзоваÑ^BелÑ^LÑ^Aкие паÑ^@амеÑ^BÑ^@Ñ^K (hostname, ipv4/6) подÑ^AÑ^BавлÑ^OÑ^NÑ^BÑ^AÑ^O коÑ^@Ñ^@екÑ^Bно.

Ð^WадаÑ^Gа:
- Ð^_онÑ^OÑ^BÑ^L, поÑ^GемÑ^C Anaconda вÑ^AÑ^Q еÑ^IÑ^Q Ñ^BÑ^@ебÑ^CеÑ^B `--name` и на какой команде Ñ^MÑ^Bо Ñ^AÑ^@абаÑ^BÑ^KваеÑ^B.
- Ð^_Ñ^@едложиÑ^BÑ^L минималÑ^LнÑ^Kе пÑ^@авки Ñ^Hаблона или генеÑ^@аÑ^Fии, Ñ^GÑ^BобÑ^K Ñ^HÑ^BаÑ^Bно пÑ^@ойÑ^Bи паÑ^@Ñ^Aинг Kickstart.
- Ð^_о возможноÑ^AÑ^Bи подÑ^BвеÑ^@диÑ^BÑ^L, нÑ^Cжно ли добавлÑ^OÑ^BÑ^L `--name` к `clearpart`/`ignoredisk` или каким-Ñ^Bо дÑ^@Ñ^Cгим Ñ^AÑ^CÑ^IноÑ^AÑ^BÑ^Oм, либо пеÑ^@еклÑ^NÑ^GиÑ^BÑ^LÑ^AÑ^O на `part --asprimary`/`reqpart`.

Ð^^гÑ^@аниÑ^GениÑ^O:
- Kickstart Ñ^DоÑ^@миÑ^@Ñ^CеÑ^BÑ^AÑ^O динамиÑ^GеÑ^Aки в %pre (Anaconda 40.13/Rocky 10).
- Ð^R rescue окÑ^@Ñ^Cжении неÑ^B Ñ^CÑ^BилиÑ^BÑ^K `tee`, иÑ^AполÑ^LзÑ^Cем Ñ^BолÑ^Lко POSIX-Ñ^Hелл.

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

Wow, this markup even breaks GH's own code block preview 🤔

@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?

Looks like still not fixed on v0.4.46

<img width="828" height="311" alt="Image" src="https://github.com/user-attachments/assets/3790059d-465e-4f5b-bbe7-c568b19e9294" />

@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

<img width="632" height="492" alt="Image" src="https://github.com/user-attachments/assets/01529f36-d2f5-44bf-b11b-1b5dbe240967" />

<img width="1077" height="273" alt="Image" src="https://github.com/user-attachments/assets/5a6aec1e-bdb8-4fa5-8132-e3155758fded" />
Fresh catch today

@nos1609 what version of the extension are you running / which model are you using?

Looks like fixed on v0.4.60

<img width="1113" height="546" alt="Image" src="https://github.com/user-attachments/assets/90ea5c81-b82a-4ecc-be2a-664bd13a8344" />

<img width="1413" height="653" alt="Image" src="https://github.com/user-attachments/assets/4677b4eb-b014-47f2-a456-af034d392077" />

But this is the native PowerShell use, no WSL implied

Closing as resolved in current releases.