Proposal: Reader Mode with Read Aloud for Codex and ChatGPT desktop

[hacksurvivor]

Summary

Add an audio-first Reader Mode to Codex and ChatGPT desktop so users can listen to long assistant responses with the same ease as ChatGPT on the web.

Why this would help

Codex often produces long explanations, plans, code reviews, logs, and implementation summaries. Reading all of that visually can be tiring, and it is difficult to keep up while coding, multitasking, or resting your eyes. A first-class listening experience would improve accessibility and make long sessions more comfortable.

Operating-system accessibility tools can read selected text, but they do not provide a clean, message-aware experience. This should feel native to the conversation rather than like a workaround.

Proposed experience

• Add a Read aloud action to every completed assistant response.
• Offer an optional Reader Mode for the current response or a user-selected sequence of responses.
• Include play, pause, resume, stop, replay, skip forward/back, and playback-speed controls.
• Highlight the current sentence or paragraph and keep it visible while audio plays.
• Provide keyboard shortcuts so the experience works without reaching for the pointer.
• Read only user-visible content; never read hidden metadata or internal reasoning.
• Handle code deliberately: skip code blocks by default, announce them briefly, or let the user opt in to exact code reading.
• Remember voice and speed preferences, with a clear operating-system TTS fallback when a cloud voice is unavailable.
• Keep the interaction consistent across Codex and ChatGPT desktop where possible.

Accessibility and product value

This would be useful for people with visual fatigue, dyslexia, ADHD, or other reading and attention needs, as well as anyone reviewing a response while their hands or eyes are occupied. Codex is both an execution surface and a reading/review surface, so listening should be a first-class way to consume its output.

Relationship to existing requests

Issues #20957 and #21645 already request a per-message Read Aloud button. This discussion supports those requests and extends the idea into a coherent Reader Mode, rather than opening another duplicate issue.

Questions for the team and community

1. Should the first version be a simple per-message button, or should it include a focused Reader Mode from the start?
2. What should the default behavior be for code blocks, diffs, tables, and tool output?
3. Would sentence highlighting, speed controls, and an OS-level offline fallback belong in the initial accessibility scope?

[Kin230k]

Strong +1. I would start with a per-message Read aloud control as the first release, but define the playback model so it can grow into Reader Mode without changing the interaction later. The initial accessibility baseline should include keyboard-operable play/pause/stop, speed control, sentence or paragraph highlighting, and predictable focus behavior.

For mixed technical content, my preferred default would be to read prose and lists normally, announce code blocks, diffs, tables, and tool output as distinct regions, and let the user choose whether to enter or skip each one. Exact code reading should be opt-in because punctuation-heavy output can become unusable; diffs should announce file and added/removed context; tables should expose headers before cells. Hidden metadata and internal reasoning should never enter the reading queue.

An OS-level offline voice fallback also feels important for reliability and privacy. That narrower first version would deliver real accessibility value while leaving multi-message queues and a distraction-free Reader Mode for a later iteration.