Text injection

The three injection strategies

AXUIElement splice — native Cocoa apps

For native macOS apps, evoglyph reads the current value of the focused text field via the macOS Accessibility API (AXValue), inserts the new text at the cursor position, and writes the updated value back.

This is the default strategy. Apps not matched by the bundle-ID routing table use this path; if it fails, evoglyph falls back to copying to the clipboard with a notification.

Keystroke injection — terminals

Terminal-class apps typically do not expose editable text via the Accessibility API in a way that supports direct splicing. For this category, evoglyph uses keystroke injection — text is delivered as synthesised key events rather than a direct AXValue write.

The routing table in the next section is the authoritative source of which apps are currently mapped to which strategy.

Pasteboard — browsers and Electron apps

Browsers and Electron-based apps do not expose editable text via the Accessibility API in a way that supports direct splicing. For these apps, evoglyph writes the transcribed text to the system pasteboard and synthesises Cmd + V to paste it. The effect is a single paste operation arriving at the cursor.

This is the same path a human uses when pasting from the clipboard, so it works in any app that accepts paste input.

How evoglyph picks a strategy

evoglyph identifies the frontmost app by its bundle ID and selects the injection strategy from a routing table. The table below lists the current mappings:

The strategy is applied automatically — there is nothing to configure. Note that iTerm2 and Obsidian are currently mapped to the pasteboard path, not keystroke injection. For per-app details, see Target apps.

Password and secure fields

evoglyph detects and skips native macOS secure fields (AXSecureTextField). When the focused element is a native password input, injection is refused — nothing is typed or pasted, and you're notified.

Web browsers and some app surfaces are different. A web <input type="password"> is rendered web content and exposes no secure-field signal to macOS, so evoglyph cannot reliably detect it and will not necessarily skip it. Treat password fields in a browser as unprotected.

Independently of detection, dictation is produced by speech recognition followed by an AI cleanup pass. Both are non-deterministic — the text that lands may not exactly match what you spoke. That's fine for prose; it is unacceptable for a password or other exact secret.

Recommendation: don't dictate into password or secure fields — type secrets manually. This matters most in web browsers, where automatic skipping does not apply.

Note the placement in the injection pipeline: native fields route through the Accessibility API (where the secure-field check lives); browser and Electron surfaces route through the pasteboard (where macOS exposes no secureness signal).

Switching apps mid-dictation

Your text always lands in the app where you started recording, not wherever focus is when you stop the hotkey. evoglyph captures the target at the moment the hotkey goes down:

• AX-splice path — the element reference captured at recording start is written to directly (PipelineOrchestrator.handleRecordingStarted sets recordingStartElement at hotkey-down).
• Pasteboard path — Cmd+V is posted to the process ID of the recording-start app (PasteboardInjector.postCmdV calls keyDown.postToPid(pid); pid derived from the same captured element).

Switching windows, Command-Tabbing, or clicking in another app while dictation is in progress does not redirect which app receives the text — the pipeline passes the captured element and pid through transcription and cleanup unchanged and injects at the end of that path. However, moving the cursor within the target app during dictation can change where in that app the text is inserted; see the Troubleshooting callout below.

If injection fails entirely on all paths, evoglyph copies the text to your clipboard and posts a notification so you can paste manually.

Why Accessibility permission is required

Both the AXUIElement splice path and the keystroke path require the macOS Accessibility permission (System Settings › Privacy & Security › Accessibility). Without it, evoglyph cannot read focused text fields or synthesise keystrokes — injection falls back to pasteboard for all apps.

The pasteboard path does not require Accessibility permission, but it overwrites whatever was previously on your clipboard. For most workflows, granting Accessibility access and getting the native splice path is the better experience.

See the Grant permissions guide for how to enable Accessibility access.

Troubleshooting injection failures