macOS global dictation does not paste with Russian keyboard layout

I did one more pass to narrow this down to the packaged Desktop code.

In Codex Desktop 26.422.30944, the global dictation paste path is in the packaged Electron main bundle (app.asar, .vite/build/main-*.js). The relevant flow is:

• write transcript to Electron clipboard
• wait briefly
• call the macOS paste helper
• restore the previous clipboard if it still contains the transcript

The macOS paste helper currently shells out to osascript and sends paste with a layout-dependent AppleScript command:

- tell application "System Events" to keystroke "v" using command down
+ tell application "System Events" to key code 9 using command down

key code 9 is the physical V key on macOS. This makes Cmd+V work regardless of the active keyboard layout, and I verified locally that it fixes Russian layout paste.

I also cloned the public openai/codex repo at current main and could not find this Desktop source string there. The public repo appears to contain the CLI/Desktop launcher, while this paste implementation is only present in the packaged Electron app. So I cannot submit a direct PR against the public source for this specific line unless the Desktop source is published or mapped into this repo.

Suggested internal source-level change: in the macOS branch of the global dictation paste helper, replace the System Events keystroke "v" using command down call with key code 9 using command down.

We are seeing the same issue on Codex Desktop 26.429.20946 on macOS.

Global dictation successfully records/transcribes, and the relevant macOS permissions are enabled (Accessibility, Input Monitoring, Microphone, Screen Recording, and Automation -> Codex -> System Events). However, with a Russian keyboard layout active, the transcript is not pasted into Discord, Notes, or TextEdit.

After switching the input source to ABC/English, the behavior is consistent with the diagnosis above: the failure appears to be the layout-dependent System Events paste step rather than transcription or permissions.

So this reproduces on the latest Codex Desktop version as well.

the keystroke-based-on-character pattern is a layout trap on macOS. AppleScript's keystroke "v" resolves to whatever key produces 'v' under the current input source, which on Russian or Dvorak isn't kVK_ANSI_V. key code 9 + cmd works because it's the physical V slot regardless of layout. cleaner fix is dropping System Events entirely: CGEventCreateKeyboardEvent with kVK_ANSI_V hits the same path without the AppleScript bridge. or skip simulated Cmd+V altogether and write to the focused element via AXUIElementSetAttributeValue on kAXSelectedTextAttribute, no clipboard race, no layout coupling.

I can confirm this is still reproducible in a newer Codex Desktop build, and it also affects Zhuyin, not only Russian layouts.

Environment:

• Codex Desktop: 26.611.62324
• macOS: 26.5.1
• Input source: com.apple.inputmethod.TCIM.Zhuyin / ZhuyinBopomofo

Behavior:

• Global dictation starts normally.
• Transcription works.
• The transcript appears in the global dictation UI/history.
• Dictation works inside the Codex app.
• But when the focused target is an external app such as TextEdit/Notes, the transcript is not inserted.

I verified locally that this is still the same layout-dependent paste issue. Before patching, the packaged app still contained:

tell application "System Events" to keystroke "v" using command down

Under Zhuyin, this does not reliably send physical Cmd+V, so the paste step silently fails.

Local workaround that fixed it:

I patched /Applications/Codex.app/Contents/Resources/app.asar and replaced the AppleScript paste command with:

tell application "System Events" to key code 9 using command down

After fully quitting and restarting Codex, global dictation insertion into external apps started working under Zhuyin.

This confirms the issue is not microphone permissions, Accessibility permissions, or transcription. It is still the layout-dependent paste implementation.

Note: this workaround modifies the signed app bundle and will be overwritten by updates, so it is not a viable user-facing fix.

Suggested fix:
Use key code 9 using command down, CGEvent with kVK_ANSI_V, or another layout-independent paste mechanism for macOS global dictation.

I can confirm this issue as well.

In my case, Codex global dictation works correctly when the current macOS keyboard layout is English, but fails to paste the recognized text when the current layout is Russian.

What I observe:

• I use Codex global dictation with Right Option as the hotkey.
• With English layout active, the dictated text is transcribed and pasted into the focused text field correctly.
• With Russian layout active, Codex appears to record and transcribe the speech, but the final paste step fails.
• The recognized text can still be found in Codex transcription history/settings, so this does not look like a speech recognition problem.
• The issue reproduces in external apps/text fields, not only in one specific app.

This makes the feature unreliable for users who regularly switch between English and Russian layouts. Manually switching to English before every dictation is not a practical workaround.

The diagnosis in the original issue looks correct to me: the final paste action should be layout-independent on macOS. Using a physical key code for paste, or another layout-independent paste mechanism, would likely fix this without requiring users to change keyboard layout or install external automation tools.

Please prioritize this fix, since global dictation is otherwise very useful but currently unreliable for multilingual macOS users.
Codex version: 26.623.81905 • Released Jul 1, 2026
macOS version: 26.5.1 (25F80)

Still reproducible after another Codex Desktop update, and the local binary patch is still required.

Clarification: although the issue title mentions Russian, this is not specific to Russian text or the Russian keyboard layout. The underlying failure is the layout-dependent macOS paste simulation. Zhuyin/Bopomofo reproduces the same problem because keystroke "v" using command down depends on the active input source. A more accurate scope would be non-US/non-ABC keyboard layouts or input sources.

Environment:

• Codex Desktop: 26.623.81905, CFBundleVersion 4598
• macOS input source: com.apple.keylayout.ZhuyinBopomofo
• App path: /Applications/Codex.app

Observed:

• Global dictation records/transcribes successfully.
• The transcript is available, but final paste into the focused external app fails when Zhuyin is active.
• Switching layout avoids the issue, consistent with the existing layout-dependent paste diagnosis.

I inspected the updated app bundle and confirmed the packaged app still contains:

tell application "System Events" to keystroke "v" using command down

After replacing it locally with the layout-independent equivalent:

tell application "System Events" to key code 9 using command down

the bundle contains old_count=0 and new_count=1, and the replacement AppleScript compiles successfully with osacompile_exit=0.

This is the same workaround as before, but Codex updates overwrite it and it also breaks the app code signature, so it is not a viable user workaround.

Expected fix:

Use a layout-independent paste mechanism for macOS global dictation, e.g. physical key code paste / CGEvent with kVK_ANSI_V, or another non-layout-dependent insertion path.

I’d like to clarify the scope here: this does not appear to be Russian-specific.

This is likely affecting many non-ABC / non-US macOS keyboard layouts and input sources. I can reproduce the same failure with Zhuyin/Bopomofo, and others have confirmed Russian as well. The common factor is not the spoken language or transcription result, but the final paste step being layout-dependent.

Current behavior appears to rely on:

tell application "System Events" to keystroke "v" using command down

On macOS, this is interpreted through the active keyboard layout/input source. Under non-English layouts, it may not produce the physical Cmd+V paste shortcut, so the transcription succeeds but insertion into the focused external app silently fails.

A layout-independent implementation fixes this locally:

tell application "System Events" to key code 9 using command down

or equivalently a CGEvent-based paste using the physical kVK_ANSI_V key.

I think this should probably be treated as an internationalization/accessibility bug rather than a Russian-layout edge case, because global dictation is effectively unreliable for multilingual macOS users unless they manually switch to English before every dictation.