Chrome Screen Recording Permission on Mac: Sharing a Window Again

Two problems arrive under the same search. In the first, Chrome refuses to share a screen: the Share button does nothing, or the picker opens and the other side sees black. In the second, Chrome is sharing when it should not be, and a reminder that the screen is being captured keeps appearing with no obvious tab behind it. Both come back to the same two layers, a macOS grant that belongs to the Chrome application and a page-level picker that belongs to the tab. Knowing which layer is refusing turns a long afternoon into two clicks.

The two layers Chrome has to pass

macOS keeps one switch per application. Chrome either has screen capture access or it does not, and that decision covers the whole browser. Websites never appear in the system list, because the operating system has no idea which tab asked.

The web platform then adds a second layer inside Chrome. A page calls a screen sharing API, Chrome shows a picker, and the user chooses a tab, a window or the whole desktop. Chrome Enterprise documentation describes this directly in the policy that governs it: when screen capture is allowed, a web page can use screen-share APIs such as getDisplayMedia() or the Desktop Capture extension API to prompt the user to select a tab, window or desktop to capture. The choice is per session by design, which is why no amount of configuration will make Chrome remember one particular window forever.

The practical consequence is a short diagnostic. If no picker appears at all, the problem is Chrome side: a policy, a disabled feature in the meeting service, or a page that never made the call. If the picker appears but the result is black or empty, the problem is usually the macOS grant or a browser that has not been relaunched since the grant was made.

Granting it once, in the right place

Apple's Mac User Guide gives the path. Open the Apple menu, choose System Settings, click Privacy & Security in the sidebar, then click Screen & System Audio Recording. Find Google Chrome in the list and turn it on. If Chrome is not listed at all, the plus button below the list adds an application directly, which is faster than waiting for Chrome to ask again.

The label is version dependent, and this trips up people following older instructions. Apple's guide for macOS Ventura 13 names the same list Screen Recording and reads "Click Screen Recording." Current versions of the guide name it Screen & System Audio Recording and note that an app can be allowed to record both the screen and audio, or just audio. Anyone reading a help desk article written two releases ago is looking at the right place under the wrong name.

Google documents the macOS Sequoia behaviour from its own side. Its guide to presenting in a meeting states that after updating to macOS Sequoia a cautionary prompt appears the first time a meeting is recorded or a screen is shared, that Allow must be selected for Google Chrome permissions when prompted, and that anyone who missed the initial dialog needs to add Google Chrome to the screen and system audio recording list in System Settings. That is the same list described above, reached the same way.

Resetting a decision Chrome is already holding

A grant that was made while Chrome was running is not always picked up by the running process, and this single detail accounts for a large share of the cases where the switch looks correct and sharing still fails.

Google is explicit about the fix. Its screen sharing troubleshooting page states that to reset permissions, closing Chrome is not enough and a full restart is required, and gives chrome://restart as the way to perform it. Typing that in the address bar closes and reopens the browser window, after which the meeting should be rejoined. Google adds that Chrome restores open tabs and windows on restart, though Incognito windows are not reopened.

If the restart changes nothing, the recorded decision itself can be cleared. macOS ships tccutil, and its manual page describes it as the command that manages the privacy database, with a single supported command, reset, which resets all decisions for a named service so that apps prompt again the next time they access it. An optional bundle identifier limits the reset to one app. Scoping the reset to Chrome's bundle identifier is the proportionate move, because the unscoped form clears the decisions of every application that uses the same service, which means every other conferencing tool and capture tool on the Mac will ask again from scratch.

Chrome profiles do not each get a grant

People running a work profile and a personal profile often expect two entries in the system list. There is only one. All Chrome profiles run inside the same application bundle, so macOS sees a single app and stores a single decision. Granting screen capture in the work profile grants it in every profile, and revoking it revokes it everywhere.

Chrome's own policies behave the opposite way. The documentation for the screen capture policy notes that it is applied at Chrome profile level and applied to the browser without a restart. So a managed work profile can have capture disabled while a personal profile in the same Chrome can still share, and no amount of System Settings work will change that. The system grant is per application, the policy is per profile, and the two are easily mistaken for each other.

When the real block is a policy

If the picker never appears, a managed policy is a strong candidate, and Chrome Enterprise documents exactly what it does. The screen capture policy has been supported on Chrome for Mac, Windows and Linux since version 81. Left unset it defaults to allowing pages to prompt for capture. When it is disabled, calls to screen sharing APIs fail with an error.

That same documentation names the escape hatches, and they are worth knowing because they explain why capture sometimes works on one site and not another on the same managed Mac. The disabled state is not considered, and a site is allowed to use screen sharing APIs anyway, if the site matches an origin pattern in any of four allow lists, covering screen capture, window capture, tab capture and same origin tab capture by origin. An administrator who has allowed one meeting service by origin and left everything else blocked produces precisely the behaviour that looks like a broken permission.

Google also notes, on the ordinary user side, that screen sharing may be turned off by administrator settings for a Workspace organisation or by the meeting host's own controls. Three different owners can switch this off, and none of them is the Mac.

What the capture reminder is telling you

The second half of this search is the opposite problem: Chrome appears to be capturing when nothing should be. Apple documents one of the visible signs. When software is sharing, mirroring or recording the screen, the Mac lock screen can show the message "Your screen is being observed." Apple's support note lists the ordinary causes, including the screen sharing feature of a videoconferencing app, AirPlay or other software showing the screen on an external display or television, remote access tools such as Screen Sharing and Apple Remote Desktop or another VNC app, and the screen recording feature built into macOS.

A meeting tab left open is by far the most common cause when the app named is a browser. Reviewing open tabs for an active meeting, a recording tool, or a remote support session usually finds it in under a minute. Apple's note suggests updating macOS and restarting the Mac if the message persists, and using safe mode to learn whether third party software that loads at startup is responsible.

Revoking the grant is the one move that settles the question for good. Turning Chrome off in Screen & System Audio Recording means no page in Chrome can capture anything until the switch is turned back on, which is a clean test rather than a guess. The cost is that the next legitimate meeting will need the switch again, so this is a diagnostic rather than a permanent setting for anyone who presents regularly.

Tab, window or entire screen

Once capture is working, the choice inside the picker changes what the meeting can do, and Google Meet's troubleshooting page publishes the comparison. Sharing a tab and sharing a window or desktop both support sharing audio, annotation, and fullscreen for viewers. Scrolling inside the meeting, navigating Google Slides from within the meeting, and zoom controls are listed for tab sharing only.

Presenting choice	Audio	Scroll and zoom in the meeting	Slides navigation in the meeting
A Chrome tab	Supported	Supported	Supported
A window or the entire screen	Supported	Not listed	Not listed

Two further conditions are published alongside that table. Sharing audio for a window or desktop share requires macOS 14.2, Windows 11 or newer. And a meeting can carry a maximum of ten simultaneous presentations. A reader convinced that screen sharing is broken is sometimes looking for a feature that only exists on the tab path.

When Chrome is one of four browsers on the Mac

Plenty of Macs end up with Chrome for meetings, a second browser for a client's tenant and a third for a personal account, purely because signed-in sessions collide inside one browser. Each of those browsers is a separate application to macOS, so each needs its own row in Screen & System Audio Recording, its own relaunch after a change, and its own place for a stale decision to hide.

A browser that keeps every web app in its own window, with its own cookie container, addresses the reason those extra browsers were installed in the first place. Several accounts of the same service stay signed in side by side, while the operating system still sees one application and stores one capture decision. The honest trade-off is that a single grant then covers every app inside that browser, so it should be given deliberately rather than clicked past. Putting meeting services in a space of their own keeps the scope tight, and the Workspaces page shows how the grouping works in practice. Which services can be added as their own window is listed on the supported apps page.

What to change first

Open System Settings, Privacy & Security, Screen & System Audio Recording, confirm Google Chrome has a row and that it is on, then run chrome://restart before testing anything else, since an unrelaunched Chrome is the most common reason a correct setting looks broken. If the picker never appears at all, the block is a policy or a host setting rather than a permission, and if the same meeting has to work every week, moving it into a window of its own in SpaceDeck means the grant is made once.