AI Hotkey Not Working in Slack / VS Code: Why It Fails and How to Fix It
You highlight a message in Slack, press your AI rewrite hotkey, and… nothing. Same in VS Code. But in TextEdit, Notes, or a Word document, the identical tool works perfectly. This is the single most common complaint about inline AI editors, and it’s maddening precisely because it’s selective — the tool clearly works, just not where you spend most of your day.
The good news: this isn’t random, and it isn’t your fault. There’s a specific, explainable cause, and there are concrete ways to work around it.
What’s actually happening
Inline AI editors don’t have magic access to your text. To read your selection and write back a replacement, they ask the operating system for help through its accessibility API:
- On macOS, that’s the Accessibility API, which exposes on-screen text through objects called
AXUIElement. - On Windows, that’s UI Automation (UIA).
These APIs were built so screen readers and automation tools could “see” and manipulate the content of any app. When an app is a normal native app — built with the OS’s own UI toolkit — it publishes its text fields to these APIs automatically. The inline tool reads the selected text, sends it to the AI, and injects the result. Smooth.
Slack and VS Code are not native apps. They’re built on Electron — essentially a Chromium browser wrapped in a desktop window. The text you’re editing isn’t a native OS text field; it’s HTML rendered inside an embedded browser. By default, Electron and Chromium apps expose very little to the OS accessibility tree, or expose it in a shape the inline tool doesn’t expect. So when the tool asks the OS “what’s the selected text in the focused field?”, it gets back nothing, or an empty value, or a structure it can’t write to.
The tool then does the worst possible thing: it fails silently. No error, no popup. It tried, got nothing, and gave up. From your side it looks like the hotkey is broken.
Why it’s specifically Slack and VS Code (and Notion, Obsidian, Discord, Teams…)
The pattern is “anything built on Electron or Chromium.” That’s a huge slice of the modern desktop:
- Slack, Discord, Microsoft Teams, WhatsApp Desktop — chat apps
- VS Code — and many other modern code editors
- Notion, Obsidian — note and knowledge apps
- Any web app in a browser tab — Gmail, Google Docs, Linear, etc.
These are exactly the apps high-volume writers and developers live in. So an inline tool that only works in native apps effectively doesn’t work where you need it.
How to fix it
Step 1: Rule out the easy stuff first
Before blaming the architecture, confirm the basics:
- Accessibility permission is granted and current. On macOS: System Settings → Privacy & Security → Accessibility → make sure your AI tool is listed and toggled on. After any app update, toggle it off and back on — macOS frequently silently revokes the permission for an app whose signature changed on update. On Windows, run the tool as the same privilege level as the target app (an elevated/admin app can’t be automated by a non-elevated tool, and vice versa).
- The hotkey isn’t being swallowed. Slack and VS Code both bind a lot of shortcuts. Check that your AI tool’s hotkey doesn’t collide with an app shortcut. Try a deliberately unusual combination to test.
- You actually have text selected. Some tools need an active selection; clicking into a field isn’t enough.
Step 2: Try Electron’s accessibility flag (VS Code, Slack)
Electron apps can be told to expose their accessibility tree. macOS sometimes triggers this automatically once a screen reader / accessibility client is active, but you can often force it:
- VS Code: it generally turns on accessibility support automatically when an assistive client is detected; you can also check
Editor: Accessibility Supportin settings (set to “on”). - Slack: historically Slack has had limited and inconsistent accessibility exposure; there’s no reliable user-facing toggle, which is exactly why so many tools fail in it.
This sometimes helps, but it’s unreliable and app-dependent — which is the core of the problem.
Step 3: Use a tool with a fallback chain (the real fix)
The durable fix isn’t a setting you flip — it’s choosing a tool that doesn’t depend on the accessibility write succeeding. A well-built inline editor uses a fallback chain:
- Try the fast native accessibility write.
- If it can’t confirm the text was replaced within ~200ms, fall back to a clipboard-based inject: copy the selection, process it, and paste the result with a simulated paste keystroke (which Electron apps do accept, because it’s just a normal paste).
- If even that isn’t safe, drop the result into a small “Insert” popover you click once to place.
The key insight: typing and pasting always work in Electron apps, even when the read/write accessibility path doesn’t. A tool that leans on that fact as a fallback keeps working where pure-accessibility tools die.
How EditSnappy fixes this at the root
This failure is the reason EditSnappy exists. Most tools have only step 1 of that chain — when the native write fails in Slack or VS Code, they have no plan B, so nothing happens.
EditSnappy runs the full fallback chain: it tries the native accessibility write first for speed, and the instant it can’t confirm the replace, it falls back to a clean clipboard inject or a one-click “Insert” popover. So in Slack, VS Code, Notion, Obsidian, Discord, Teams and JetBrains IDEs — the apps that go silent on every other inline tool — the text actually lands instead of nothing happening. The reliability fallback isn’t a footnote in the feature list; it’s the centerpiece of the product.
You can see how EditSnappy works and try it free in your own apps — including the ones that broke your last tool.
Related
- Why inline AI breaks in Obsidian & Notion
- Fix: inline AI tool does nothing in Java/JetBrains apps
- Accessibility permissions for AI text apps, explained
- Want reliable AI editing inside Slack specifically? See AI writing inside Slack and AI editing in VS Code & JetBrains IDEs.
Part of the Why Inline AI Editors Fail troubleshooting hub · EditSnappy home.