Camera and Mic Blocked on Google Meet: Getting Both Back

Both are gone at once. No picture, no level bar, and a message saying the camera and microphone are blocked. Two devices failing in the same second looks like something serious, and it is almost always the opposite: one answer, given once, that covered both.

That is useful information rather than bad news. A fault that takes out the camera and the microphone together has a much shorter list of causes than either one alone, because whatever caused it had to be something that sits above both devices. Reading the symptom that way turns a long hunt into two checks in a fixed order.

One prompt, two permissions, two stored answers

Meet asks for the camera and the microphone in a single request when a meeting is joined. One click answers both. That is why a single moment of impatience, usually while a meeting is already starting and the prompt is covering the Join button, disables both devices at once.

The storage is not single, though, and this is where the fix goes wrong. The browser keeps camera answers and microphone answers separately, on separate pages, for the same site. Reversing the block therefore takes two edits even though it took one click to create. Fixing the camera page and testing only the camera is how people conclude the setting did not work.

macOS is arranged the same way. Privacy and Security has a Camera list and a Microphone list, each with its own switch per app, and a browser can be allowed in one and denied in the other. The two lists are also built independently from what has actually been requested, so an app can be present in one and missing from the other.

The practical rule that follows: every step below is done twice, once for the camera and once for the microphone, before anything is tested.

What both being blocked tells you

Compare the two patterns and the candidate list narrows on its own.

What is blocked	What that rules in	What it rules out
Camera and microphone together	One shared answer: the joint prompt, a system switch, an administrator policy	Cables, individual devices, device selection
Camera only	The camera's own stored answer, or the camera device	A shared cause
Microphone only	The microphone's own stored answer, or the audio device	A shared cause
Both, and also on a second Mac	The account or the network policy	Anything local

The first row is the case this covers, and the third column is the part worth taking seriously. A shared block means there is no point checking a cable, replugging a camera, or changing which microphone Meet selected. Those all live below the gate that refused, and nothing below the gate has been reached yet.

The fourth row deserves a moment before starting. If the same meeting behaves the same way on a different Mac with a different account, the block is not in the settings of either machine. On a Mac issued by a company or a school, a configuration profile can set both privacy controls centrally, and a control set that way cannot be changed locally. A switch that is greyed out, or a browser setting shown as managed, is the signature, and the fix is a request to whoever administers the machine.

Fix the system level first

This order matters. The system level sits above the site level, so a site permission granted while the system still refuses produces no change at all, and the reasonable conclusion is that the site fix failed.

The path is the Apple menu, then System Settings, then Privacy and Security in the sidebar. Open Camera, find the browser, and turn its switch on. Then open Microphone and do the same. Apple's own note about these lists is the one to remember: if there are no apps in a list, nothing installed has asked for that device yet. Built in apps such as FaceTime and Photo Booth are granted camera access without asking, which is why they keep working while a browser does not.

An app that is absent from a list cannot be added by hand. Absence means the request has never arrived. Open a meeting in that browser and let the page ask, which produces the macOS prompt and creates the list entry in the same step.

Then quit the browser. Quit, not close the window, and open it again. A running application can hold the previous answer for the rest of its session, and skipping this is the single most common reason a correct change appears to do nothing.

Two confirmations are available afterwards without joining a meeting. The green light beside the camera glows whenever the camera is on and goes out once every app that can use it has been closed or quit. Control Center carries a Recording Indicator light that shows when the microphone is in use or was recently used. If neither appears when a meeting preview opens, the system level is still refusing and there is no reason to move on yet.

Then the site level, on both pages

In Chrome the path is Settings, then Privacy and security, then Site settings, then Camera, and afterwards the same route to Microphone. Each page lists the sites that were allowed and the sites that were blocked.

There are two ways to act on an entry. Selecting the site's name opens its own page, where the setting can be changed to Allow. Choosing Delete next to the site clears the stored answer instead, so the prompt appears again on the next visit. Delete is usually the better choice here, because the original problem was an answer nobody meant to give permanently, and clearing it restores the question rather than replacing one permanent answer with another. Each page also has a down arrow for choosing the default device the browser offers to sites.

When the prompt does come back, the choices are along the lines of allowing while visiting the site, allowing this time, or never allowing. The last one is what created this situation. Nothing marks it as permanent and nothing reminds you later that it exists.

One detail decides whether the right entry is being edited. The answer is stored against the site in the address bar, which for a meeting joined from a calendar link is Meet's own address, but for a meeting embedded in another product's page is that product's address instead. Reading the addresses in the list, rather than looking for the one name expected, is what finds that case.

Site answers are also stored per browser profile. A second profile, a guest window or another browser starts with no answer at all and asks fresh, which is occasionally the fastest way into a meeting that is already running. It is also why the same block seems to come back: it was cleared somewhere other than the profile in daily use.

Verify in the join screen, not in the call

Testing this inside a live meeting is slow and public. Meet's join screen does it better and nobody else is watching.

On the preview tile before joining, the camera and microphone can be checked separately. Clicking Microphone and speaking should move a level bar. Clicking Camera should show the picture, and Meet's own documentation notes that if the camera is working, the video feed appears to the right of Video. Clicking Speaker and then Test speakers sends a sound to the selected output, which covers the third device that people discover is wrong five minutes into a call.

Both indicators moving means the whole permission chain is intact: system level, site level, and device selection. Anything still wrong after that is a device choice or the other end of the call, and those are visible in Settings, then Video and Audio, where the camera, the microphone and the speaker are each selected from their own menu and the panel closes with Done.

The third permission that catches people out

Camera and microphone are two of three. Presenting a screen is a separate permission on a Mac, held in its own list, and it is the one that appears to be broken at the worst possible moment.

The list is Screen and System Audio Recording, in the same Privacy and Security section, and it allows an app access to the screen and system audio or to audio only. Apps can be added to it explicitly using the add button. Google's own guidance for presenting covers the macOS Sequoia case directly: a cautionary dialog appears when an app tries to record or share the screen, the answer to choose is Allow, and if that dialog was missed, the browser has to be added to screen and system audio recording permissions in System Settings by hand.

Worth knowing while sorting out the other two, because the moment of discovery is otherwise a meeting where presenting was the point.

It behaves differently from the other two in one way that is easy to misread. Screen sharing has no live indicator equivalent to the camera light, and the refusal often shows up as a share that starts and then presents a blank or black area rather than as a message saying no. So the test is the same trip through the join screen, extended by one step: start a share to nobody, in a meeting with only yourself in it, and confirm that the preview shows the real screen. Doing that once, before the meeting that needs it, is the whole precaution.

Why this keeps happening in one crowded browser

The mechanics above are simple. What makes them recur is where the answers live.

One browser profile holding a dozen services holds one shared set of device answers, and a prompt that appears while a meeting is starting gets answered in whatever way clears it fastest. That answer then applies to the site for good. Tabs get closed and reopened all day, profiles get switched, extensions that manage tabs or media behave differently in each one, and the meeting page is the one thing in that window that cannot tolerate any of it.

A browser that keeps each web application in its own window with its own container changes what a permission means. The answer for the meeting application is given once, in a window that does nothing else, and it is not sitting in a list beside every other service. The application is its own entry in the macOS privacy lists too, so the Camera, Microphone and Screen and System Audio Recording rows point at the thing actually being used rather than at a general purpose browser that does everything. The feature list covers that separation, and the meeting services are on the supported applications list.

What to change first

Do the system level before the site level: System Settings, then Privacy and Security, then Camera and Microphone in turn, then quit the browser and open it again. Only then clear the stored site answers on both the Camera and the Microphone pages under Site settings, using Delete rather than Allow so the prompt returns. Confirm in Meet's join screen, where the level bar moves and the video feed appears, before joining anything.

If the meeting keeps sharing a window with every other service in the working day, that is the part worth changing, and SpaceDeck was built for it.