macOS global dictation selects PyCharm Paste submenu instead of Paste action

What version of the Codex App are you using?

ChatGPT desktop 26.908.40834 (build 8881), bundle identifier com.openai.codex.

What subscription do you have?

ChatGPT Pro.

What platform is your computer?

macOS 26.6.2 (25G83), Apple Silicon.
Target application: PyCharm 2026.2.2, build 262.10315.174.

What issue are you seeing?

Global voice dictation opens PyCharm's Edit menu instead of inserting the transcript into the focused text field. This previously worked. The first affected release is unknown.

PyCharm exposes a submenu named Paste and a command with the same name inside it:

Edit
  Paste                 (submenu parent)
    Paste               (actual paste action)
    Paste from History…
    Paste as Plain Text

The global dictation paste implementation appears to select the submenu parent instead of the actual Paste action. Opening the submenu is treated as success, so the Command-V fallback does not run.

What steps can reproduce the bug?

1. Enable global dictation and automatic paste in the desktop app. The configured hold hotkey on the affected machine is Fn.
2. In PyCharm, focus an editable text field, such as the AI Chat prompt.
3. Dictate a short phrase and release the hotkey.
4. Observe the Edit menu opening and no transcript being inserted.

Control: ordinary clipboard insertion into the same AI Chat field works. The nested Paste menu structure was verified through the live macOS accessibility tree. The complete speech-to-insertion failure is user-reported; the diagnostic investigation independently verified the menu structure and the implementation below.

What is the expected behavior?

Insert the transcript at the caret. A submenu container must not be mistaken for an actionable Paste command. An option to always use Command-V would also provide a useful compatibility workaround.

Additional information

Read-only inspection of the installed app's app.asar, .vite/build/main-DaMR-wdT.js, identified this sequence:

• T4e searches the accessibility menu tree depth-first and returns the first enabled AXMenuItem whose identifier matches Paste or whose title equals Paste / its localized equivalent.
• It checks the title before descending into AXChildren, without rejecting submenu parents.
• w4e invokes AXPress on that element.
• M4e falls back to Command-V only if the menu invocation throws.
• The outer paste operation restores the original clipboard after a 700 ms delay, so the transcript may no longer be available for a subsequent manual paste even though insertion never happened.

Suggested fix: skip menu items with submenu children when resolving Paste, prefer the actual leaf action, and retain a keyboard-paste fallback or selectable paste strategy. Add coverage for a same-named parent/child menu such as PyCharm's Edit → Paste → Paste, including localized labels.

No private project content or session logs are included in this report.

Verified local workaround

In PyCharm Settings → Appearance & Behavior → Menus and Toolbars, add the Paste editor action directly under Main Menu → Edit, before the existing Cut/Copy/Paste Actions group. On the affected installation it was inserted immediately after Undo.

The live accessibility tree then exposes a leaf Paste item before the same-named submenu. Invoking that first Paste successfully inserts a test string into the AI Chat prompt. The original Paste submenu and keyboard shortcuts remain available. The user also confirmed that end-to-end voice dictation now inserts text automatically in PyCharm after this change.

Start by inspecting the paste-selection sequence in app.asar and .vite/build/main-DaMR-wdT.js, especially T4e, w4e, and M4e, then trace how the macOS accessibility menu tree is resolved and pressed. Add coverage for a same-named parent and leaf Paste menu, including localized labels, and verify that a submenu is not treated as success and keyboard fallback remains available.