Chrome Remote Desktop host on a Mac: sharing the screen you sit at
Being the machine that gets reached is a different job from being the machine that reaches out, and most of the trouble people run into with Chrome Remote Desktop on a Mac sits on the host side. Something is installed. macOS asks for approval. A dialog mentions security settings. And then either it works for years without being thought about again, or it fails in a way that cannot be diagnosed from the other end, because nobody is sitting in front of the Mac to see what it is asking for. This covers what the host component is, which approvals macOS controls, the difference between the two ways of sharing, and what to do before walking away from the machine.
Installing the host is a job done in person
Google's instruction for setting up a Mac to be reached is short: open Chrome, enter remotedesktop.google.com/access, and under Set up Remote Access click Download, then follow the onscreen directions to download and install Chrome Remote Desktop.
The sentence that follows is the one worth reading twice. Google notes that a computer password may have to be entered to give Chrome Remote Desktop access, and that a prompt to change security settings may appear. Those two lines are the entire reason this is a job done while sitting at the machine. A password prompt and a system approval dialog cannot be answered from somewhere else, and there is no remote connection yet to answer them through.
That is the single most common way a plan to reach a Mac from a trip fails. The installer runs, the machine appears in the list, and something in the approval chain was never completed, so the connection attempt from the hotel produces a black screen or nothing at all. The fix is always local, which is exactly what is not available.
Removal is equally local and equally specific. Google documents uninstalling on a Mac by finding the application named Chrome Remote Desktop Host Uninstaller and launching it, then clicking Uninstall. That is a separate application from anything in the Applications folder that looks like Chrome, and it is what should be run on a machine being sold or handed on rather than deleting files by hand.
The two macOS approvals that decide whether it works
macOS does not let any application watch the screen or drive the keyboard without explicit permission, and a remote desktop host needs both. Apple documents where each one lives.
Screen access is controlled from the Apple menu, then System Settings, then Privacy and Security in the sidebar, then Screen and System Audio Recording. Without it, a connecting session may authenticate and then show nothing useful, because the host is not allowed to see what is on the display.
Control is the second one, in the same place under Accessibility. Apple describes this as the permission a third party application needs when it tries to access and control the Mac through accessibility features, and warns that giving an application access to the Mac also gives it access to contacts, calendar and other information. That warning is worth reading rather than clicking past, because it is the honest description of what remote control means: whoever connects has the machine.
Two practical notes follow from this. A macOS upgrade is a good moment to check both panes, because approvals granted to an older build of an application do not always survive a major version change, and the symptom appears as a session that connects to a blank screen. And on a Mac managed by an employer, these panes may be controlled by policy, which brings the question back to the administrator rather than the software.
Persistent access or a one time code
Google separates the two ways of sharing a machine into two addresses, and choosing the wrong one produces a setup that cannot do what was wanted.
| Route | Address | Who reaches it | Authentication | Runs unattended |
|---|---|---|---|---|
| Remote access | remotedesktop.google.com/access | The same Google account | PIN | Set up once, stays available |
| Remote support | remotedesktop.google.com/support | Anyone given the code | One time access code | Confirmation asked every 30 minutes |
Remote access is for a machine the same person owns. Once set up, it appears in the list on every computer signed into that Google account, and connecting takes the PIN. This is the route for an office Mac that has to be reachable from home.
Remote support is the other shape entirely. The documented steps are to go to remotedesktop.google.com/support, download and install Chrome Remote Desktop, then select Generate Code and send the code to the person who will connect. When they enter it, a dialog appears showing their email address, and the share is approved by selecting Share. Sharing ends with Stop Sharing.
Two documented limits define what this route is for. The access code works only one time. And Google states that while a computer is being shared, the person sharing is asked to confirm that they want to continue every 30 minutes. That is a deliberate design choice and it makes the support route unsuitable for anything unattended, because the session dies at the first unanswered prompt.
Google's help pages describe the sharing dialog in blunt terms that are worth quoting to anyone being walked through it on the phone: the person connecting will have full access to applications, files, email, documents and history. Nobody should be generating a code without understanding that sentence.
The question about a signed out Mac
The most searched host side question is whether a Mac can be reached when nobody is signed in, and the honest answer starts with what is not in the documentation. Google's help pages describe setting up remote access, sharing a computer, connecting, giving support, and removing a computer. They do not describe reaching a Mac that has not been signed in since it started up.
What they do describe is the persistent route: remote access configured on the machine in advance, listed under the owner's Google account, opened with a PIN. That is the mechanism to use for a machine that should be reachable without anyone touching it, and it is worth testing properly before relying on it. The test is not connecting from the next room while still signed in at the desk. The test is locking the machine, walking away, and connecting from a different network.
Two settings on the Mac itself decide more than anything in Chrome Remote Desktop does. A Mac that goes to sleep is not reachable, so a machine intended to be available needs its sleep behaviour set accordingly. And the login password, the disk encryption state and the account being signed in or out all sit between a successful connection and a usable desktop. Sorting those out in person, then testing from outside, is the only reliable sequence.
What the network has to allow
When a host that was working stops working, Google's own troubleshooting list is shorter than most forum threads and should be worked through first.
The machine needs an internet connection, and if the page will not open at all, the computer's network settings come first. Antivirus software is named explicitly as something that can prevent Chrome Remote Desktop from working, along with what it has to be allowed to pass: outbound UDP traffic, inbound UDP responses, traffic on TCP port 443 for HTTPS, and traffic on TCP and UDP port 3478 for STUN.
Then the policy items. Google states that if the computer being accessed is on a work or school network, it might not let a person give others access, and points at the administrator. On a managed account, an administrator may control access to Chrome Remote Desktop directly. A host that works from a personal account and fails from a work one is almost always policy.
The last item is keeping Chrome current, which matters more on the host than on the client because the host component is the part that has to keep talking to macOS across system updates.
One reassurance and one caution belong together here. Google states that all remote desktop sessions are fully encrypted, and that it collects and stores some anonymised data about network delays and how long a session lasted in order to improve the service. Against that, a host with persistent access enabled is a standing door into the machine, protected by a PIN and a Google account. On a shared or family Mac, turning access off with Disable remote connections when a stretch of travel ends is a reasonable habit rather than paranoia.
The host's own controls are a browser page too
There is a detail about the host side that only becomes annoying once it is a routine. Everything about managing the host is a web page. Generating a support code, seeing the machine list, and turning access off through Disable remote connections all happen at remotedesktop.google.com in a browser tab.
For a Mac that is shared occasionally, that is fine. For a Mac that a family member or a colleague sits at and has to generate a code from whenever help is needed, a browser tab is the wrong container. The person who needs it is, by definition, the person who is currently confused about something, and asking them to open Chrome, type a long address and find the right button is asking a lot at exactly the wrong moment.
| Method | Engine | Suits the support page | Suits the machine list |
|---|---|---|---|
| Chrome, Install page as app | Chrome | Yes | Yes |
| Safari, Add to Dock | Safari | Google's instructions name Chrome | Same |
| A site to app tool | Chosen per app | Yes, on Chrome or Chromium | Yes |
Chrome's documented route is More, then Cast, save, and share, then Install page as app. Pointing that at the support page and leaving a named icon in the Dock of the machine that gets helped turns a phone call from four instructions into one: click the icon, read out the code. That single change is worth more than any tuning of the connection.
Building it on Chrome rather than Safari is the right default here, because Google's instructions for every part of Chrome Remote Desktop begin with opening Chrome and its troubleshooting advice ends with keeping Chrome up to date. The features list covers what a purpose built tool sets per app, including the icon and the name that make the difference on somebody else's Mac, and supported services shows the range of sites that end up handled this way.
What to change first
Do the host setup in person and finish it: install, answer the password prompt, then open System Settings, Privacy and Security, and confirm the entries under Screen and System Audio Recording and under Accessibility. Then test from outside the building with the machine locked, not from the next room. If someone else sits at the Mac and will need to generate support codes, leave them a named Dock icon pointing at the support page, which a tool such as Kagemusha can build on Chrome with its own session instead of one more tab to find.
Frequently asked questions
Can the host be set up remotely on a Mac?
No, and this is the most common way the plan fails. Google notes that a computer password may need to be entered to give Chrome Remote Desktop access and that a prompt to change security settings may appear. Both have to be answered at the machine, which is why the host side is a job done in person before travelling.
Which macOS permissions does the host need?
Two, both under Privacy and Security in System Settings. Screen and System Audio Recording lets the host see the display, and Accessibility lets it control the Mac. Apple's own warning on the Accessibility pane notes that giving an application access to the Mac also gives it access to contacts, calendar and other information.
Why does the sharing session keep asking for confirmation?
Because that is documented behaviour on the support route. Google states that while a computer is being shared, the person sharing is asked to confirm that they want to continue every 30 minutes, and that the access code works only once. For a machine that has to be reachable unattended, the remote access route with a PIN is the one to set up instead.
Can a Mac be reached when nobody is signed in?
Google's help pages do not describe that scenario. What they document is remote access set up in advance on the machine, listed under the owner's Google account and opened with a PIN. Whether it works in a given setup depends on the Mac's sleep behaviour and sign in state, so it has to be tested by locking the machine and connecting from a different network.
How is Chrome Remote Desktop removed from a Mac properly?
Google documents finding the application named Chrome Remote Desktop Host Uninstaller, launching it, and clicking Uninstall. Separately, access for a machine can be turned off from the list at remotedesktop.google.com/access using Disable remote connections, which is the right step when the machine should stay usable but stop being reachable.
It worked before a macOS upgrade and now shows a blank screen. What changed?
Start with the two permission panes. A host that authenticates but shows nothing is the classic signature of missing screen access, and approvals granted to an earlier build do not always carry across a major macOS version. After that, work through Google's network list: outbound UDP, inbound UDP responses, TCP port 443, and TCP and UDP port 3478.