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

Turning the site into a Mac app takes under a minute. The trouble starts afterwards. The window asks for a login every morning, a link jumps out into a browser, notifications never arrive, or the window sits there white and empty. All of it looks like the app was built wrong, and almost none of it is. Three causes account for nearly every report: how the container stores data, a permission answered in the wrong place, and something happening on the service side that has nothing to do with the app at all. Sorting between those three first is what keeps the fix short.

Do the split once, before touching any setting

Every symptom starts the same way. Open the same URL in an ordinary browser tab.

If the problem reproduces there, the container is innocent. The cause is the service, the account, or the network, and changing app settings will not help. If the problem happens only in the built app, the cause is local, and there are exactly three places worth looking: stored data, permissions, and the registered URL.

One more check belongs here because it resolves a surprising number of reports. Confirm which account is signed in. A built app and a browser tab can hold different sessions without any visible sign, so a missing conversation history or vanished settings often means two accounts rather than one fault. The account address is visible in the settings panel of the service itself.

That split takes about a minute. Skipping it is how people end up an hour deep in preferences that were never involved.

A second pass through the same test catches network level causes. If a VPN, a corporate proxy, or a filtering profile is active, the browser and the built app go through it identically, so a failure that survives both is pointing outward rather than at the Dock icon. Turning the tunnel off for one reload is a faster answer than reading log files, and it costs nothing to try before the deeper checks below.

The login disappears every time

This is the most common report, and the answer depends on which route built the app.

A Safari web app shares no browsing history, cookies, website data, or settings with Safari. Being signed in inside Safari therefore does nothing for the new app, which starts from scratch. That is the design, not a fault. Signing in once should stick.

If it does not stick, two places explain it. The first is the Privacy tab in the app's own Settings, which offers to clear that app's website data including cookies. Using it logs the session out by definition. The second is anything set to clear cookies at quit, whether a system level setting or an extension.

A Chrome installed app behaves differently because it belongs to the Chrome profile it was created from. Signing out in that profile signs the app out too. Chrome's own documentation is explicit that deleting browsing data during uninstall means signing in again on the next visit, so a reinstall that keeps demanding a password usually had that checkbox ticked.

Before assuming a bug, check whether the session was cleared by something that was supposed to clear it.

Running two accounts adds a variation that reads as a bug but is not one. Signing out of a work account in the browser leaves the personal session inside the built app untouched, and the reverse is equally true. What looks like a session that randomly resets is sometimes two sessions behaving correctly and independently. Giving each app a distinct name and icon makes the state visible at a glance, which is cheaper than diagnosing it again next week.

Links open in a browser instead of the app

Pressing a link inside a conversation and watching a browser window appear is expected behaviour, not damage. An app built from a browser hands destinations outside the original site to the default browser. The share button also offers Open in Safari deliberately, for the moments when bookmarks or tabs are needed.

The case that actually needs fixing is the reverse: a page that belongs to the same service escaping to the browser. That points at the registered URL no longer matching where the service lives, which happens after a domain change or a switch of subdomain.

On the Safari route, open the app, click the app name in the menu bar, choose Settings, and edit Application URL. There is a Set to Current Page button, so the reliable method is to navigate to the correct page first and then set it.

On the Chrome route there is no equivalent field for rewriting the target. Rebuilding is faster, and the old entry can be removed from chrome://apps.

The app cannot be found after building it

Sometimes the app is built and then apparently vanishes. It is almost always a folder misunderstanding.

A Safari web app is saved to the Applications folder inside the home folder, which is a different location from the system wide Applications folder. In Finder, the Go menu leads to Home, and the Applications folder inside it holds the built apps. Spotlight and the Dock reach them normally, so the distinction only matters when hunting for one.

Deleting works from the same place: drag it from that folder to the Trash. Searching the system wide folder will never find it, because it was never there.

Chrome installed apps are listed at chrome://apps instead. Right clicking an entry there offers Create shortcut, which places it on the desktop or in a menu, and Open at login, which starts it automatically after signing in.

Notifications never arrive

Notifications fail for one reason more than any other: permission was granted in the wrong window.

A web app has additional notification capabilities. The number of unread notifications can appear as a red badge on the app icon in the Dock. Source: support.apple.com

The same page states the condition attached to that capability: the site's request for notification permission has to be answered inside the web app rather than inside Safari. Granting it in the browser beforehand does not carry over. The prompt has to be allowed to appear again inside the app.

After granting it, open System Settings and select Notifications in the sidebar. The built app appears in the application list under its own name rather than under a website URL, which is also why renaming the app changes the name to look for. If the entry is switched off there, no amount of permission on the site side will produce an alert.

It is also worth confirming that the service sends notifications at all. If alerts never arrived while using an ordinary browser tab, there is nothing to restore.

The window stays blank, or login never completes

For a white window or a login that stalls, check three things in this order.

First, sign in flows that open a second window. Authenticating through a Google account or a company identity provider typically opens a small separate window. When that window is blocked, or when it lands somewhere the trimmed toolbar cannot navigate back from, everything stops. Completing the sign in inside the browser first and then rebuilding the app often clears it.

Second, extensions. A Safari web app's toolbar carries buttons for installed Safari extensions, and its Settings has an Extensions tab that enables or disables them for that app alone. Content blockers sometimes interrupt the requests a login depends on, so switching them off for that app and reloading is a clean test.

Third, stale data. The Privacy tab clears the app's cookies and cache, which forces a fresh sign in but resolves rendering problems caused by leftovers. It goes last precisely because it costs a login.

One structural detail explains why this symptom hits built apps harder than tabs. The toolbar in a web app is deliberately minimal: back, forward, share, and extension buttons, with no address bar. When a sign in flow redirects somewhere unexpected, a browser tab shows the URL and offers an obvious escape, while the app window offers nothing to read. Turning navigation controls back on in Settings at least restores the back button, which is often enough to retreat from a dead end.

If none of the three applies, return to the first split. A blank page that also appears in a normal browser tab is a service side event.

Japanese input drops characters

Characters disappearing mid conversion, or a message sending before it was confirmed, has more to do with how the input field is built than with the container. Reproduce it in a browser tab first. If it happens there too, the app is not the variable.

When it happens only in the built app, suspect a keyboard shortcut conflict. Launcher utilities and key remapping tools intercept keystrokes system wide, and an intercepted key during conversion looks exactly like a broken input field. Quitting those tools temporarily isolates the cause.

Write down the reproduction conditions while testing: which key, how many characters in, and whether it happens every time or intermittently. Those three details turn a support conversation into one round trip instead of four.

Something changed after an update

Behaviour shifting after a macOS or browser update is routine. Two places explain most of it.

The first is the name and icon. Chrome raises a notice when an installed app changes its name or icon, with options to accept, ignore, or uninstall, and its guidance says to treat an icon that starts resembling a different app as a reason to remove it. A Dock icon that looks wrong should send anyone to that notice first.

The second is permissions. Major OS updates can put notification and Accessibility grants back into a state that needs confirming. Notifications and Privacy and Security in System Settings will show whether the built app still has a row.

If neither applies and the app simply refuses to open, rebuilding is the shortest path. Quitting the browser completely before rebuilding avoids carrying the old state forward.

Timing is worth noting for a different reason. An app that broke on the same morning the operating system updated is a different story from one that broke on the morning the service shipped a redesign. Checking the service's own status page before rebuilding costs a few seconds and occasionally makes the whole exercise unnecessary, since a service side outage looks identical from inside a Dock icon and inside a browser tab. The first split catches this, which is another argument for never skipping it.

What to change first

Before rebuilding anything, write down three values: the app name, the registered URL, and where the icon image came from. On the Safari route all three sit in the same Settings panel, ready to copy. With those in hand a rebuild takes minutes and nothing is lost.

Supported services lists the sites where these behaviours have already been worked out, Features covers what the container itself can adjust, and Kagemusha documents the repair and removal steps for anyone who keeps hitting the same wall.