Composer's Rich Text support is broken in many ways, but it cannot be disabled

Open 💬 4 comments Opened Jul 18, 2026 by alexchexes
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.715.31925

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26100 x64

What issue are you seeing?

Please see the screencast. Watch carefully, please, as it shows at least 4 different problems, all of which are caused by the poor quality of the implementation of what is apparently supposed to be Rich Text mode support.

https://github.com/user-attachments/assets/8a607fa1-4d52-4486-a007-e133b61ce3f5

Main issue:
While Rich Text mode support is broken in so many ways, it cannot be disabled.

See #33586 for additional context on how that buggy mode produces unintended input that changes code meaning, that is eventually silently sent to the model.

What steps can reproduce the bug?

Use the Codex chat UI "composer" either in VS Code or in the Codex (aka ChatGPT) App, and try these scenarios:

  • Writing or pasting lines containing the - symbol at the start of the line
  • Pasting code int readPointer(); from a C++ file with the Night Owl theme enabled (where readPointer is shown as italic)
  • Copy a word from a line that appears as a list item inside the composer, and paste it elsewhere

Then:

  • Try to locate a setting like "Plain Text mode" or "Rich Text mode" somewhere. There is no such setting, meaning that we are forced into a non-working "feature" without any chance to fully disable it until its proper implementation is landed.

What is the expected behavior?

_No response_

Additional information

This affects both: Codex (aka ChatGPT) App, and the VS Code Codex extension.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #34004
  • #33586
  • #33307

Powered by Codex Action

kkshinkai · 22 days ago

A company incapable of delivering good UX should at least have some respect for the complexity of rich-text editors.

  1. Users may want to paste nothing more than a variable name or a word, but it can arrive as bold text or even a heading, with everything typed afterward inheriting that formatting — you never established that users need external rich text in this input at all. The decision itself is wrong.
  2. Typing ` ` creates a code block even when text already exists before them, ` ` inside a code block are also swallowed — your input rule does not check the selection position first.
  3. Backticks do not create inline code — your workaround for preventing / after a backtick from opening the command menu appears to block the backtick rule as well, because you did not account for interactions between formatting rules.
  4. Copying one word from a list item and pasting it creates a nested list — you do not understand how to correctly handle the open start and end of a slice.
alexchexes · 22 days ago

@kkshinkai so much of my pain in just one message. Gotta deal with these 4 problems each day. They are not in the issue text only because it was created in the very beginning and I hadn't yet found them.

Sad that such an apparently, obviously incorrect behavior remains unfixed for weeks for hundreds of thousands of users where the fix is trivial — a simple toggle in settings that would disable the "rich text" for good. Too bad.

euntaek-hong · 21 days ago

This update has seriously broken the Codex desktop app UX for me.