Built-in `Speech Generation Skill` is barely functional, unusable in `Plan Mode`

Open 💬 0 comments Opened Mar 7, 2026 by gaelic-ghost

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

Version 26.305.950 (863)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

When in plan mode, attempting to invoke use of the Codex built-in Speech Generation Skill Skill consistently results in Codex beginning a new plan to use the aforementioned skill. This is the opposite of expected behavior, and the opposite of an accessible interface.

This prevents any reliable use to review plans. This makes the app incredibly inaccessible to millions of potential users. It also causes me physical pain. It'd be great if someone with the privilege to contribute here ("invitation-only" repo) could implement proper AX.

What steps can reproduce the bug?

Be in plan mode.
Invoke Speech Generation Skill Skill via slash-command.

OR

Be at the "implement this plan | no and tell codex what to do different;y" prompt with a plan to be read.
Try to simply invoke the skill as your response.

NOTE: This is, of course, not 100% reliable, but most of the time it will not do as expected.

What is the expected behavior?

Invoking the Speech Generation Skill Skill via slash-command with no other user turn context should result in the model speaking it's response aloud. Perhaps offering to summarize first, depending on the length of it's response.

Additional information

I'm working on a wrapping Skill, and probably an entire AppKit GUI, to solve all the AX issues with Codex for myself, at least, and I'd be more than happy to bake a proper TTS command/button into the CLI and macOS GUI. Unfortunately, Codex is source-available, not open-source, so I suppose this issue, an ADA complaint, and biting the bullet and building my own GUI atop the Codex App Server will have to do.

Tech should be accessible to all. Tech sold to the public legally must be accessible. You're shipping a paid product to an OS with half-broken system-level AX utilities. You have disabled users themselves building the utilities that they're legally entitled to. This is not a sustainable state of affairs.

On a personal level, it really sucks to be shut out (partially, or otherwise) of so much lately. And more generally, it sucks for everyone when the disabled are last priority on all these projects and products. It hurts so many people, in so many ways, and you all should know that.

This has so much potential, and most of us cannot use it effectively, if at all, given the complete lack of consideration for AX. Similar story across the industry, and in every one of these products. Y'all could have an army of boosters if you wanted, and a lot of additional markets opened up. It's insane to leave that level of goodwill from that many people on the table, but here we are.

I love tech, I love writing code, and I love these tools (when it doesn't literally hurt me to use them). But I hate that they're not built for me to use them. They're built for one group of people, and I'm in another. It's incredibly disappointing, and we, as an industry, can do so much better than this.

View original on GitHub ↗