Raycast not working on Mac: what to check

Raycast stops responding, the hotkey does nothing, snippets refuse to expand, or a feature that worked last week quietly stopped. The instinct is to reinstall. For a resident app on macOS that instinct is usually wrong, because the common causes live in the system permission database and in other apps competing for the same keystroke. Both survive a reinstall untouched, so the app comes back in exactly the state it was in.

What is worth having instead is an order of inspection. Permissions, duplicate copies, input conflicts, login items. Working down that list stops most symptoms somewhere along the way, and it takes less time than a clean install does.

Name the symptom before touching anything

"Not working" covers four situations with different causes. Deciding which one applies halves the work that follows.

• The app does not launch, or quits immediately after launching.
• The app is running but the hotkey produces nothing.
• The window opens, but one specific feature fails: window commands, snippet expansion, dictation.
• Everything worked until a macOS or Raycast update, and then it did not.

Getting this wrong is expensive in a particular way: the fix for one category does nothing for the others, so guessing means running through remedies that were never going to apply. Deciding the category costs about thirty seconds.

The first is about the app itself. The second is about input never reaching it. The third is about a permission attached to that one feature. The fourth overlaps with the others but changes where to start, because an update that revokes a permission is the single most common way a working setup breaks.

That fourth case points at the structural fact behind most of this: Raycast does not have one permission, it has several, each attached to different features. There is no single switch that means "allowed". Thinking of it as one switch is what makes a machine where some features work and others do not seem impossible to explain.

Step one: match the permission to the failing feature

Open System Settings, then Privacy & Security. Three panes matter, and each governs something different.

Pane	What stops working without it
Accessibility	Every hotkey, and snippet expansion
Screen Recording	Window management commands
Microphone	Dictation

Accessibility has the widest blast radius. Raycast's own troubleshooting page is unambiguous that without it, no Raycast hotkey can register at all. So the maddening case where Settings clearly shows a hotkey assigned, and pressing it does nothing, is almost always this pane and not a broken shortcut.

There is a failure mode worth knowing: Raycast appears in the list, the toggle looks correct, and the permission is still not in force. The documented fix is to toggle it off, then back on. That resets the underlying grant. macOS major updates are the usual trigger.

If window commands are the only thing failing, the pane is Screen Recording rather than Accessibility. Moving and resizing windows needs it. Raycast prompts for it the first time a window command runs, and if that prompt was dismissed, later attempts fail silently with no second prompt. Nothing on screen tells you why.

Step two: check that only one copy is running

This one is quick and skipping it invalidates everything after it. Open Activity Monitor and search for Raycast. If two processes appear, one of them is a leftover: a second install in a different folder, an older version left behind during an upgrade.

Two copies produce symptoms that look like corruption. A snippet keyword fires twice and inserts doubled text, or the two instances cancel each other and nothing appears. Raycast's guidance for people who deliberately run two is to make sure snippet expansion is enabled in only one of them.

Spend the minute here. When permissions look correct, settings look correct, and the symptom persists anyway, a second copy is the reason often enough to justify always checking.

Step three: find out who else wants that keystroke

If the window will not open and permissions are clean and only one copy is running, something else is holding the shortcut. The Raycast hotkey defaults to Option + Space, but many people reassign it to Command + Space to displace Spotlight, and that combination is contested on a stock Mac.

Three system owners claim it, and the documentation lists all three:

• Spotlight. System Settings, Keyboard, Keyboard Shortcuts, Spotlight. Uncheck or change Show Spotlight search.
• Input Sources. Same Keyboard Shortcuts screen. If more than one input language has ever been configured, a switching shortcut is probably bound there.
• Siri. Siri may be set to a held Command + Space or Option + Space. A held binding does not block the press outright, it adds a delay when toggling the window.

That third one explains a symptom people describe as sluggishness rather than failure. If Raycast opens but feels late, check the Siri shortcut before concluding anything about performance.

Third-party tools compete too. The documentation names the categories: text expansion tools against Raycast Snippets, keyboard remappers, and other launchers bound to the same keys. Disabling the suspect temporarily and retrying is the only reliable test, since two tools claiming one shortcut leaves no error message anywhere.

Snippets have failure causes of their own beyond permissions. A keyword containing a space, a quote, or a backtick will not match, because those act as delimiters. And apps with custom text input, some code editors, terminals, and password managers, do not support text replacement at all. Try the same snippet in a different app: if it expands there, the app is the constraint, not Raycast.

Step four: login items that stopped firing

"It no longer starts automatically" is a separate class of problem. Open System Settings, General, Login Items & Extensions, and confirm Raycast is present in the Open at Login list and enabled.

When it is enabled and still does not fire, the documented fix is to remove the entry and add it back. The macOS login items database occasionally holds stale information for frequently updated apps, and re-registering clears it. This is not specific to Raycast. Any app that ships updates often can end up in the same state.

Reinstalling belongs after these four steps, not before them. The documented sequence is to install the current version over the existing one, and only if that fails, remove the app along with its supporting files and install clean.

One more category deserves a mention here because it produces symptoms that fit none of the four steps cleanly: file search behaving badly. If results are missing, or indexing appears to hang forever, the cause is usually a folder the indexer cannot get through rather than a broken install. Encrypted cloud storage folders are a documented hang point, and the fix is to exclude them through the Ignore Patterns setting under File Search rather than to reinstall anything. The same setting handles the other common case, which is a very large developer tree pulling the index size up. After changing exclusions, quit and reopen Raycast so indexing restarts from the new scope.

The reason this matters for diagnosis is that a stuck indexer makes the whole app feel slow, which invites the conclusion that Raycast itself is at fault. Checking the search scope takes a moment and rules out a cause that no amount of permission fixing would ever have addressed.

What to collect if it still fails

If all four steps come back clean, the next move is reporting it. Arriving empty-handed guarantees several rounds of back and forth before anything useful happens, so gather these first. Raycast's troubleshooting page lists them:

• Versions. The Raycast version from Settings, About, and the macOS version from System Settings, General, About.
• Steps to reproduce. Which command was opened, which keys were pressed, which option was selected, and whether it happens every time or intermittently.
• Logs. The Copy Raycast Logs command puts them on the clipboard.
• A screen recording. Faster than prose for anything visual.
• A crash report, if the app is dying rather than misbehaving.

Of these, the documentation singles out steps to reproduce as the single most valuable item. Something reproducible gets fixed. Something that cannot be reproduced tends to stay open indefinitely, regardless of how clearly it was described.

Conditions count as steps. If it only happens with an external display attached, only when a particular app has focus, or only after the Mac wakes from sleep, that belongs in the report. A note about running a beta of either Raycast or macOS matters too, since leaving it out sends the investigation down the wrong path entirely.

Two states that look like faults and are not

Before filing a bug, rule these out.

A Focus session icon that appeared on its own. Raycast Focus normally shows a floating bar, but it can be moved to the menu bar from that bar's overflow menu. Once moved, later sessions show up there too. An icon that seems to have installed itself is usually this setting, and it disappears again when the session ends.

High memory readings. Third-party stats tools sometimes report inflated figures, so confirm in Activity Monitor first. A large file index also inflates the number legitimately, and excluding big or rarely used folders through the Ignore Patterns setting shrinks it. Only memory that climbs continuously across hours of normal use is worth reporting.

The icon disappeared from the menu bar. Settings, General has a Show in Menu Bar toggle, and with it off Raycast keeps running with no icon at all. Separately, if a menu bar manager is installed, that tool may simply be folding the icon out of view. In both cases the app is alive and the hotkey opens the window. Test with the hotkey before treating a missing icon as evidence of anything.

Ruling out the menu bar as a variable

That second case is awkward precisely because the cause is not in Raycast. If something is folding icons and you are not sure what it covers, no amount of inspecting the app will produce an answer. Know what your organiser hides and what it leaves out before you start diagnosing: the features page sets out the scope of hiding and how the tool behaves while resident.

The retrieval cost differs by approach, and it matters here more than it looks. If checking a hidden icon means expanding the whole bar every time, diagnosis gets slower exactly when you are iterating. The comparison page covers how the common methods differ on that. Worth reading alongside it: the pricing page, since something installed temporarily for a diagnosis should not turn into a commitment.

What to change first

Open Privacy & Security and check Accessibility before anything else, because it governs every hotkey and it is what system updates most often revoke. If that pane is correct, check Activity Monitor for a second copy. Only after both come back clean is it worth looking at Koffret or any other menu bar tool as an explanation for what you are seeing.