Claude as a Mac app not working: what to check, in order

A Claude window on the Dock either works invisibly or fails in a way that looks like nothing. The icon bounces and stops. The sign in page loads and then refuses. The keyboard shortcut does nothing at all. None of these produce a useful error message, which is why people try the same four things in a random order and give up. The failures have distinct causes and they can be separated in about two minutes if the checks are done in the right sequence.

Work out which layer broke before changing anything

Three separate layers have to work, and each one fails differently. Identifying the layer first prevents an hour of fixing the wrong thing.

The outer layer is the application bundle. macOS decides whether the .app is allowed to launch at all, based on its signature and its quarantine flag. When this layer fails, nothing appears: no window, no login screen, sometimes a dialog about an unidentified developer or a damaged app.

The middle layer is the profile, which is the directory holding cookies, local storage, and the signed in session. When this fails, the app opens fine and asks for a login that was supposedly already done, every single time.

The inner layer is the site itself plus whatever sits between the Mac and it. Sign in refusals, blank panes, and features that work in the browser but not in the window all live here.

Symptom	Layer	First place to look
Nothing opens, or a security dialog appears	Bundle	System Settings, Privacy and Security
Opens but asks for login every launch	Profile	The app's data directory and profile setting
Login page appears and then refuses	Site	Which engine the window uses, and which sign in method
Shortcut does nothing	System	Privacy and Security, Accessibility
Notifications never arrive	System	Notifications settings, and where permission was granted
Worked yesterday, broken today	Bundle or engine	What updated overnight

Run the check for the matching row before trying anything else. The rest of this article is those rows in order of how often they are the answer.

The sign in page loads and then refuses

This is the most common failure and the least obvious, because the page is clearly working. The refusal usually comes from the identity provider, not from Claude.

Google states the rule directly.

To help protect your account, Google doesn't let you sign in from some browsers. Google might stop sign-ins from browsers that: Don't support JavaScript or have JavaScript turned off. Have unsecure or unsupported extensions added. Are being controlled through software automation rather than a human. Are embedded in a different application. Source: support.google.com

That last line is the one that matters. A window built around an engine embedded inside a small utility can be caught by it, and the same page in Chrome or Safari signs in without complaint. The same document tells developers who built on the Chromium Embedded Framework to switch to browser based OAuth or migrate to a progressive web app, which confirms the direction of travel.

There are three ways past it. Use the email and verification code path instead of the Google button, which avoids the provider check entirely. Use a window that runs on a browser already installed on the Mac and reads its real profile, in which case the sign in is that browser's sign in. Or complete the login once in the browser and let the window inherit the resulting session, which only works on the second kind of tool.

One diagnostic separates a window problem from an account problem in ten seconds. Open the same URL in a normal browser window on the same Mac and attempt the same sign in. If it fails there too, the window is innocent and the issue is the account, the network, or the organisation policy. If it succeeds there and fails in the window, the engine is the variable, and no amount of clearing caches inside the window will change that.

Team and Enterprise organisations add a fourth case. Single sign on routes the login through an identity provider that may check the device, and a window that does not look like a normal browser session can be rejected at that step rather than at the Claude step. The tell is that the failure happens after leaving claude.ai, on a page belonging to the identity provider.

Nothing opens on the first launch

When a generated app is opened for the first time and simply refuses, the cause is almost always macOS security policy rather than the app.

Apple's documented path out is deliberately not a single click.

If you're certain that an app that you want to open is from a trustworthy source and hasn't been tampered with, you might be able to temporarily override your Mac security settings to open it. Source: support.apple.com

The sequence is: attempt to open the app, then open System Settings, click Privacy and Security, scroll down, and click Open Anyway. The warning appears once more, and confirming there saves the app as a permanent exception. The order matters: the Open Anyway button only appears after a launch has already been blocked.

Two different dialogs get confused here. A message about an unidentified developer means the app is not notarised, which is normal for a bundle generated on the Mac itself. A message that the app will damage the computer, or that it cannot be opened because it is damaged, means something else: macOS detected known malware, or the bundle was modified after signing. The second case is not worth overriding. Delete it and generate it again.

On a managed Mac there is a third possibility. Apple notes that the setting controlling which downloaded apps are allowed might not be available at all if the Mac is managed by a system administrator or an IT department, in which case no amount of clicking will help and the request has to go through that department.

It asks for the login again every single time

The app opens, the site loads, and the session from twenty minutes ago is gone. This is the profile layer, and there are three usual causes.

The first is a fresh data directory on every launch. If the app was rebuilt or regenerated between launches, the new bundle may point somewhere else, and the cookies from the old one are still on disk but unreachable. Building once and keeping that bundle solves it.

The second is a shared directory being cleared by something else. Browser settings that clear cookies on quit apply to the profile, not to the browser window, so a window reading that profile loses the session at the same moment.

The third is a deliberate setting. Claude offers incognito chats, and a window opened in a private context by design will never persist anything. Check whether the window was configured to start in a private session before assuming something is broken.

The distinction that resolves this quickly: if the browser itself stays signed in and only the window forgets, the window is on its own profile. If both forget, the profile is being cleared and the setting is in the browser.

The keyboard shortcut does nothing

Quick entry in the official desktop app is a common source of this, and the requirements are specific. Anthropic lists macOS 12 or later for quick entry, macOS 14 or later for voice dictation, and Claude Desktop installed and running, which can be in the background.

Permissions are the usual blocker. The documentation names three: Screen Recording, required to capture screenshots and share application windows. Accessibility, required for quick entry itself. Speech Recognition, required for voice dictation on macOS 14 or later. All three are reviewed in System Settings under Privacy and Security, and a permission granted to a previous version of an app sometimes needs to be toggled off and on after an update.

Conflicts are the second blocker, and the fix is documented rather than clever. The quick access shortcut can be changed from the default double tap of the Option key to Option plus Space, or to a custom keyboard shortcut, under Settings then General. The voice shortcut is more constrained: it can use Caps Lock or be disabled, and nothing else. If another utility already owns the same combination, one of the two has to move.

For a generated window rather than the official app, a global hotkey is provided by whatever assigned it, and it needs Accessibility permission for the same reason. A shortcut assigned in macOS Keyboard settings does not need any of this and is worth trying first as a test.

Notifications never arrive

A window that never makes a sound is usually working exactly as configured, and the configuration was set somewhere unexpected.

Apple's guidance for Safari web apps is precise on this point and easy to miss: to get the unread count badge on the Dock icon, the site's notification request has to be answered inside the web app, not in Safari. Only then does the web app appear in Notifications settings under System Settings. Granting permission in the browser and expecting the separate window to inherit it does not work, because as far as macOS is concerned they are two different applications.

Check three places in order. First, whether the site's own notification setting is on inside Claude's settings. Second, whether the app appears in System Settings under Notifications and is allowed to post. Third, whether a Focus mode is filtering it, since a newly created app is not on any allow list that was built before it existed.

If the app never appears in the Notifications list at all, the permission prompt was never answered inside it, and there is no way to add it manually. The prompt has to be triggered again from within the window, which usually means clearing that site's stored data for the app and reloading. Apple documents a Privacy tab in web app settings that clears the website's data, including cookies and caches, which also signs the session out, so this is a step to take deliberately rather than while troubleshooting something else.

It worked yesterday and broke overnight

When something that was stable stops, the question is narrow: what changed while nobody was looking.

For the official app, the answer is often an update that did not complete. Anthropic's macOS deployment notes are explicit about why. An install in ~/Applications can be updated without administrator privileges. An install in /Applications requires administrator access and write permissions to the folder, to Claude.app, and to all files it contains. On a work Mac without admin rights, updates fail quietly and the version drifts. Administrators can side step this by deploying the .pkg through Jamf, Kandji, or Microsoft Intune, and by managing updates centrally instead.

For a window built on an installed browser, the overnight change is usually that browser updating. The engine moved, and the generated bundle is still pointing at the previous layout. Tools differ in how they handle this: some detect the change and repair the app, some require it to be regenerated, and some simply fail. This is worth knowing about a tool before it happens rather than after, and the Features page is where that behaviour is normally described.

For a window with a bundled engine, browser updates are irrelevant and the risk sits elsewhere: the project shipping the engine has to keep shipping. Nativefier, still recommended by a large number of older tutorials, carries a note stating it is unmaintained, and its repository was archived by its owner on 29 September 2023.

What to change first

Start with the layer, not the symptom: if nothing opens it is Privacy and Security, if the login repeats it is the profile, and if the login refuses it is the engine. When the answer turns out to be the engine, a window built on a browser already installed on the Mac removes the whole class of sign in failures, and Kagemusha documents how that is set up.