Target apps

For a deep-dive into how each injection method works under the hood, see Text injection.

How injection picks a strategy

When transcription completes, evoglyph looks at the focused text field and asks one question: can I write into this field directly via the macOS Accessibility API? The answer — not the app's name or bundle ID — decides which injector runs:

• AXValue (read-splice-write): the most reliable method. When the focused field accepts a direct Accessibility write, evoglyph reads its current value, splices the new text in at the caret, and writes the result back. No clipboard pollution, no synthetic key events. Native macOS text fields take this path.
• Pasteboard + Cmd+V: evoglyph writes the text to the clipboard and synthesizes a Cmd+V keystroke. Used when the focused field does not expose a writable Accessibility value — browser, Electron, terminal, and other web-rendered surfaces. evoglyph picks this automatically for any such app; there's no per-app list to be on.
• Clipboard fallback: when the chosen injector fails, evoglyph copies the text to the clipboard and posts a notification. You paste manually.

This capability check lives in AppClassifier and AXValueInjector in the macOS app source. A small built-in table still pins a few well-known apps to a specific path (and handles a couple of quirks like newline behavior), but it's a set of overrides layered on top of capability detection, not the primary decision. The matrix below mirrors that table as of the latest doc update; if you spot a mismatch, the source is canonical.

The compatibility matrix

Per-app notes and gotchas

iTerm2

Pasteboard + Cmd+V. The one thing that breaks injection here is iTerm2's Secure Keyboard Entry setting. When it's on, no app (including evoglyph) can synthesize keystrokes into the terminal, and the Cmd+V chord silently does nothing.

To disable: in iTerm2's menu bar, open iTerm2 › Secure Keyboard Entry and uncheck it. The setting is per-session for the menu and global if you also clear it under Preferences. If you need secure entry for a sensitive shell, toggle it back on and use the clipboard fallback for that session.

Obsidian

Smooth, no known issues. Works in the editor, search bars, command palette inputs, and tag fields.

Chrome (and Chromium browsers)

Pasteboard + Cmd+V works inside text inputs, textareas, and contenteditable regions (Google Docs, Notion-in-Chrome, etc.). Note that pasting into a styled contenteditable can inherit the page's text formatting (font, size, color) — if you need plain text, paste with Cmd+Shift+V manually after evoglyph injects, or strip formatting in the destination editor.

Claude desktop and Anthropic apps

One of the few apps with an explicit built-in override. Its content surface is web-rendered (no writable Accessibility value), so dictation pastes in via Cmd+V — which drops newlines in as literal newlines, so a multi-line message doesn't submit until you press Return yourself. Claude is also tagged submit-on-Return, so on the rare keystroke fallback path its newlines are sent as Shift+Return rather than Return. See newlines in chat apps below — this is the single most important behavior to be aware of in chat clients.

Electron chat apps (Slack, Discord, others)

These don't expose a writable Accessibility value — their composers are web-rendered — so evoglyph detects that and pastes via Cmd+V automatically. There's no per-app list to be on and no bundle ID to match: any such surface is handled the same way. Dictation lands in the composer as one paste, and you press Return yourself to send.

VS Code, Cursor

Both render their editors in a web surface that doesn't accept an Accessibility write, so evoglyph detects that and uses the Pasteboard + Cmd+V path. The VS Code editor's autocomplete popup will sometimes intercept the paste; if a single dictation gets split across the popup and the buffer, dismiss the popup with Escape before pressing the hotkey.

Notion (desktop or web)

Desktop Notion renders its content in a web surface, so it gets the Pasteboard + Cmd+V path automatically. Web Notion goes through Chrome — same path. In both cases, large dictations may take a beat to render in the page's contenteditable; this is Notion's own debounce, not an evoglyph issue.

Slack

Slack's composer is web-rendered, so evoglyph detects it and pastes via Cmd+V. Because the whole dictation arrives as a single paste rather than as typed Return keystrokes, newlines land as literal newlines in the composer and nothing gets sent until you press Return yourself. Dictating multi-paragraph messages then editing in place works exactly as you'd expect.

Native Cocoa apps

The default tier. Apple's first-party apps (Notes, Pages, TextEdit, Mail compose, Reminders, etc.) and most well-behaved third-party native apps expose their text fields via the Accessibility API, so AXValue read-splice-write works without any clipboard side effects. This is the tier where evoglyph is least disruptive — your clipboard contents are preserved.

Fallback (clipboard + notification)

When neither AXValue nor Pasteboard+Cmd+V can be confirmed to land in the focused app, evoglyph copies the transcribed text to the clipboard and posts a notification banner. You paste manually. This path is rare in modern apps but can fire for apps with custom rendering surfaces (some games, drawing apps with their own text engines) or terminals running with secure input enabled.

Newlines in chat apps (Shift+Return)

This deserves its own section because it's the single most user-visible quirk of injection.

In most chat clients (Claude desktop, Slack, Discord, and similar), Return sends the message and Shift+Return inserts a literal newline. The paste-routed path handles this for free: a single Cmd+V drops the whole dictation — newlines and all — into the composer as one paste, so nothing gets sent until you press Return yourself.

The one case that needs help is the keystroke path. If evoglyph typed a multi-line dictation as raw \n characters into a submit-on-Return app, every newline would fire Return and submit the message — five short messages instead of one. evoglyph handles this by tagging "submit-on-Return" apps in AppClassifier.needsShiftReturnForNewline (Claude desktop is the notable one). When such an app is the injection target and the keystroke path is used, \n and \r are sent as Return with the Shift modifier. The result: a literal newline in the chat composer, and your message stays intact until you press Return yourself.

What if my app isn't listed?

You don't have to be on a list. evoglyph picks a path from what the focused field can do: a direct Accessibility write if the field accepts one (AXValue), a Cmd+V paste if it doesn't, and the clipboard fallback only if neither lands. Most modern apps work via one of the first two paths without any per-app rule. The matrix exists for the handful of apps where capability detection alone picks the wrong strategy, or where a quirk (like Claude's Return-submits behavior) needs explicit handling.

Apps that genuinely don't accept any of these methods are rare. Common offenders:

• Terminals with secure-input enabled (toggle it off, see iTerm2 above)
• Apps with fully custom-drawn text surfaces (some game launchers, niche graphics tools)
• Sandboxed apps that reject Accessibility queries (very rare on macOS)

If you hit one, the clipboard fallback gets your text out and you paste manually. If a frequently-used app is misbehaving and the fallback fires every time, file an issue on GitHub with the bundle ID — that's the signal we use to add an explicit rule.

Troubleshooting

For deeper diagnostics — clipboard pollution, partial pastes, or the fallback path firing unexpectedly — see the troubleshooting guide.