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

A meeting window built from a browser breaks in a small number of ways. The camera stays black. The microphone level never moves. Screen sharing appears to start and the other side reports an empty frame. Sound loops back as an echo. The call drops around the one hour mark. All of it looks like the container was built wrong, and most of it is not. Meetings are a bad place to experiment, because someone is waiting on the other end. The fix is to know which layer the failure belongs to before touching anything.

Sort the failure into one of four layers

Every symptom lands in one of four places, and each layer has a different owner.

The first layer is whether the call was joined at all. A wrong account, a waiting room that never admitted the participant, a feature switched off by a host or an administrator. The second layer is macOS permission. Camera, microphone, and screen recording are granted per application, not per website. The third layer is how the container itself was built: where the session is stored, which URL it opens, where links go. The fourth layer is the service and the plan: meeting length, participant ceiling, whether recording exists at all.

The test that separates them takes under a minute. Open the same meeting URL in an ordinary browser tab. If the symptom follows, the cause sits in layer one or layer four, and no amount of container tweaking will move it. If the symptom appears only in the built app, the cause is local, and the search narrows to permissions and the container.

Running that split first is what keeps a fix to five minutes instead of an hour of settings archaeology.

The camera stays black or the microphone picks up nothing

This is the first thing most people hit, and it has two distinct causes that look identical on screen.

The first is the operating system. Google states plainly that access to the computer camera and microphone has to be allowed before Meet can be used. In a browser, that grant was given once, to the browser. A standalone container is a different application as far as macOS is concerned, so the grant does not carry over. Open System Settings, then Privacy and Security, and look for the container by name in the Camera and Microphone lists. If the name is absent entirely, the prompt has never fired. Pressing the camera button in the green room before joining triggers it.

The second cause is the site level permission. Once a browser has been told to block the camera for a site, it stops asking. Google's documented recovery is to open the Meet home page, start a new meeting, click the blocked camera icon at the top right, and choose to always allow meet.google.com to access the camera and microphone. If the meeting does not reload afterwards, leaving and rejoining applies the change.

A third possibility has nothing to do with Meet or with macOS permission at all. An external webcam can only be held by one application at a time, so a recording tool or a camera utility left running in the background will keep the device busy. The symptom is identical to a denied permission: a black tile and no error text. Switching to the built in camera in the Meet settings panel is the fastest test. If the built in camera works, the problem is a device conflict, and quitting the other application releases it.

Containers that hide the address bar make the second fix awkward, because the icon lives in the bar. The shortcut is to fix the permission in a normal browser window, then reopen the container. A permission repaired in the browser does not always transfer, because Safari web apps keep their own website data. When the container was built from Safari, expect to grant it separately and only once.

Screen sharing starts but nobody sees it

Since macOS Sequoia, this has become the most reported failure of the three, and the cause is a permission that did not exist in the same form before.

If you've recently updated to macOS Sequoia: Make sure to select "Allow" for Google Chrome permissions when prompted. You'll receive a cautionary prompt when you first attempt to record a meeting or share your screen. Source: support.google.com

The text names Chrome because that is the common case, but the mechanism is per application. A standalone container asking to capture the screen produces the same prompt under its own name. Miss that dialog once and sharing simply stops working with no visible error. The recovery is in System Settings, under Privacy and Security, in the entry for screen and system audio recording. Add the container there, then quit and reopen it. Skipping the restart is the usual reason the fix appears not to work.

A different symptom is sharing that starts correctly but shows the participants a hall of mirrors. Google advises presenting a separate tab or window rather than the meeting window itself. A standalone container helps here, because the meeting window carries its own name in the picker instead of appearing as one more browser window among many.

One more ceiling worth knowing: Google documents a maximum of 10 simultaneous presentations in a single meeting. On a busy call where several people are already sharing, a share that refuses to start may be hitting that limit rather than a permission problem.

Audio is missing, or everything echoes

Two audio failures dominate, and neither is a settings problem in the usual sense.

The first comes from how the call was joined. Clicking the present button in the green room, before joining, joins the meeting in companion mode. Google documents that the microphone and speaker are unavailable in that mode. Someone who pressed present intending to show a document is now in the call with no voice and no sound, which reads exactly like a broken container. A microphone button that cannot be clicked is the tell. Leaving and rejoining normally restores audio.

The second is echo caused by joining the same meeting twice from the same Mac. A calendar link opens in the default browser, then the Dock icon gets clicked out of habit, and the machine is now in the call as two participants with two microphones and two speakers live. Sound loops. The participant list shows the same name twice, which makes this trivial to confirm and trivial to fix by leaving one of them.

When system audio is being shared, Google's guidance is to enable the system default audio output device to avoid echo. On a desk that switches between a headset and external speakers, both the Meet audio settings and the macOS sound settings deserve a look before anything else gets changed.

The call ends after about an hour

A meeting that cuts everyone off near the sixty minute mark is not a container fault, and rebuilding the app will not change it.

On a free Google account, group meetings with three or more participants have a length limit, while one to one calls have none. That is why a call can appear to run fine and then start a countdown the moment a third person arrives. Paid Google Workspace plans raise the meeting length ceiling to 24 hours across the business tiers, so the same symptom often means the call was joined with a personal account instead of the work one. The participant list shows which identity is in the room.

Recording behaves the same way. Saving a recording to Google Drive is not available on the entry tier and appears from the middle tier upward, so a missing record button is a plan question rather than a container question. Checking the plan and the signed in account takes seconds and rules out an entire category of false leads.

The session is gone every morning

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 container, which starts empty. Signing in once should then persist.

When it does not persist, two places explain almost every case. The Privacy tab inside the container's own settings offers to clear that app's website data, and using it removes the session by definition. Anything configured to clear cookies at quit, whether a system setting or an extension, has the same effect on every launch.

A Chrome installed app belongs to the profile it was created from, so signing out in that profile signs the app out too. Chrome's documentation notes that removing browsing data during uninstall means signing in again on the next visit, which explains reinstalls that keep asking for a password.

A related report reads as a broken session but is not one. The sign in holds, and yet the meeting history and the scheduled calls look wrong or missing. That is two accounts, not one fault. Separate sessions between a browser and a container are exactly what the design allows, and the cost of that separation is losing track of which identity a given window holds. The signed in address shown in the account menu settles it in seconds. Naming the work container after the company, with a distinct icon, makes the answer visible from the Dock before the window is even opened.

A lookup table for the middle of a call

When people are waiting, there is time for one guess. This is the shortest path from symptom to cause.

Symptom	Look here first
Black camera	Camera permission for the container in System Settings
Microphone dead	Microphone permission, then whether the join was companion mode
Share invisible to others	Screen and system audio recording permission, then relaunch the app
Echo or feedback	Whether the same Mac joined the call twice
Call ends near an hour	Which account is signed in, and its plan
Login required daily	Container privacy settings and any clear on quit rule
No record button	Plan tier

The top three rows are all macOS permissions, all granted per application, and all reset when the container is rebuilt. That is a good reason to build the container during a quiet hour and run one throwaway meeting through it, exercising camera, microphone, and screen share before it matters.

What to change first

Grant the three permissions once, in a test meeting, on the container that will actually be used every day. Then write down which method built it, which account signed in, and which permissions were granted, so the next Mac takes minutes instead of an afternoon. If several daily sites are heading for the same treatment, keeping them on one consistent method is what makes the permissions predictable, and the Supported services list shows which ones are already handled that way. The scope of what a container can do is set out under Features, and the Kagemusha guide documents the build steps end to end.