Chrome Remote Desktop app on a Mac: what exists

Searching for the Chrome Remote Desktop app and ending up on a web page is not a mistake in the search. On a computer, the web page is the product. There is an installer for the Mac, and there is an app in the phone stores, and neither of them is the thing that appears when a remote session starts on a desktop. Getting the pieces named correctly takes about a minute and removes most of the confusion that follows, including the very common belief that something failed to install.

The installer on the Mac is the host, not the client

Two roles exist in every remote session. The host is the machine being controlled. The client is the machine doing the controlling. Chrome Remote Desktop ships different things for each role, and the naming does not make that obvious.

The host is a package downloaded from the setup page and installed into the system. It runs in the background, it survives a restart, and it is what answers when a connection arrives. Once installed, it does not present a window at all. There is nothing in the Dock, nothing in the Applications folder to double click, and nothing to open in order to check that it is working. That absence is the single most common reason people conclude the installation failed.

The client is where the remote screen appears, and on a computer that role is filled by a browser tab. The official instructions are direct about this.

On your computer, Chrome Remote Desktop is available on the web. To use your mobile device for remote access, download the Chrome Remote Desktop app. Source: support.google.com

The sentence names the split precisely. The app exists, and it is for phones and tablets. On a Mac there is a web address, and the setup that installs onto the disk is only the half that gets connected to.

Why the old Chrome app is not coming back

Anyone who used this years ago remembers something different: an entry in a grid of Chrome apps, launched from within the browser, listed at chrome://apps. That container no longer exists on desktop platforms.

Chrome Apps in the Chrome Web Store are only supported on Chromebooks and won't work on Windows, Mac, or Linux after December 2022. Source: support.google.com

Chrome apps were a packaged format that ran on the browser engine but behaved like installed software. Google retired the format outside ChromeOS, and everything built on it either moved to the open web or stopped. Chrome Remote Desktop moved. That is why old walkthroughs describe an install step that cannot be followed, and why searching the Chrome Web Store for the app turns up extensions and unrelated results rather than the thing being described.

The practical consequence is that the current product has no desktop container of its own. It inherits whatever container the browser gives it, which by default is a tab among other tabs. Every complaint about remote sessions on a Mac that is not about the network traces back to that fact.

What macOS asks for before the host answers

The host has to do two things the operating system guards closely: watch the screen and move the pointer. macOS does not grant either quietly.

The official instructions note that a computer password may be needed during installation, and that security settings may have to be changed as part of setup. In practice that means two panes in System Settings under Privacy and Security. Screen Recording controls whether the remote side sees anything at all. Accessibility controls whether keyboard and mouse input from the remote side reaches the machine.

The failure modes are distinct and worth recognising, because they look like network problems and are not. A connection that succeeds and shows a black or frozen picture is a Screen Recording grant that is missing. A connection that shows the screen perfectly while clicks and keystrokes do nothing is an Accessibility grant that is missing. Neither produces an error message on the remote side.

One more detail catches people on a Mac that is used remotely and rarely touched in person. A machine that has gone to sleep, or that is sitting at the login window after a restart, cannot be reached by the host in the normal way. Setting the machine not to sleep while on power, and leaving a session logged in, is what makes the setup reliable rather than intermittent.

What a session loses inside a tab

A remote desktop is unusual among web pages because it wants the entire keyboard. That is exactly what a browser is designed not to give away.

Window management keys land on the browser rather than the remote machine. Closing a tab, switching tabs, opening a new tab, and focusing the address bar all fire locally. On a Mac controlling another Mac, the command key sits under the thumb for almost every shortcut, which makes the collision constant rather than occasional.

The browser's own chrome takes vertical space. A tab strip and an address bar occupy the top of a screen that is already showing a scaled down copy of a full desktop, so the remote content shrinks or scrolls.

There is also the accident nobody plans for. A remote session in a tab is one press of the wrong key away from being closed, and a middle click on the tab does the same. Sessions live in the tab, so closing it ends the connection.

Full screen mode inside the client solves part of this and creates a different problem: the tab is still there behind it, and leaving full screen puts everything back. The gap between what a remote desktop needs and what a tab provides does not close by adjusting the client.

Comparing the containers

Container	Keyboard shortcuts reach the remote machine	Survives an accidental tab close	Separate Dock icon	Login stays separate
Ordinary browser tab	Partly	No	No	Shared with the browser
Full screen inside the tab	Mostly	No	No	Shared with the browser
Second browser profile in a tab	Partly	No	No	Yes
Standalone app built from the web client	Mostly	Yes	Yes	Yes
Mobile app on a phone or tablet	Touch input only	Yes	Yes	Per device

The table is about containers, not about the client itself, because the client is identical in every row. Nothing about the remote session changes. What changes is how many browser behaviours sit between the keyboard and the remote machine, and whether the session has somewhere to live that is not shared with forty tabs.

The last row is worth noting for a different reason. The phone app is a genuine app, which is why people looking for a desktop app find references to it and assume a desktop equivalent must exist somewhere. It does not, and the mobile version is built around touch rather than a keyboard.

Two kinds of session, and only one of them persists

The same product covers two jobs that behave very differently, and treating them as one is a reliable way to be surprised.

Remote access is the persistent kind. A host is installed once, a PIN is set, and the machine stays in the list until it is deliberately removed. This is the arrangement for reaching an office machine from home, and it is the one worth building a window for, because it gets used repeatedly.

Remote support is the temporary kind. It runs from a different page, and it works by generating a code that the other person types in. The published behaviour sets clear limits on it.

The access code will only work one time. If you are sharing your computer, you will be asked to confirm that you want to continue to share your computer every 30 minutes. Source: support.google.com

Single use codes and a confirmation prompt every half hour make this route safe for helping a family member and unsuitable for unattended access. A session left running overnight will stop at the first prompt nobody is there to answer.

The distinction decides what to set up. Anyone whose actual need is reaching one specific machine most days should install the host on it and stop thinking about codes entirely. Anyone helping different people occasionally never needs a host on their own machine at all, only the support page and a browser. Mixing the two, by handing out codes for a machine that should simply be in the list, produces exactly the intermittent disconnections that get blamed on the network.

Which Google account owns the machine list

The list of remote machines belongs to a Google account, and that turns into a real problem on a Mac that is signed into more than one.

If the host was set up while a work account was current, the machine appears under that account. Opening the client later in a browser window that has a personal account in front shows an empty list, which reads exactly like the host stopped working. Signing out and back in fixes it for that moment and breaks whatever else was using the other account.

The clean solution is separation rather than switching. A browser profile bound to one account keeps that account current inside it permanently, and a standalone window built on that profile carries the binding with it. The Features page describes the profile isolation that makes this hold: cookies, session, and history stay inside the app, so the window opens on the same account every time regardless of what the main browser is doing.

This matters more for remote access than for most services, because the moment of needing it is usually the moment of least patience. A machine at the office that will not appear in the list is a problem that has to be solved before any actual work starts.

Setting the window up once

Building a dedicated window for the client is a short job, and three settings decide whether it stays useful.

Point it at the access page rather than the marketing page, so opening it lands on the machine list without a navigation step. Give it a name and an icon distinct from the browser, since the whole point is being able to reach it without hunting. Sign in inside that window and let it keep the session, so the account binding is set once.

Extensions are worth a thought here too. A window built on an installed browser keeps them working, which is useful for a password manager and useless for anything that rewrites page content, since the remote screen is a video stream rather than a document. Turning off content modifying extensions in that profile removes a class of odd behaviour before it appears. The Guide covers the per app extension switches that make this a setting rather than a compromise.

What to change first

Confirm which of the two macOS permissions is missing before touching anything else, because a black screen and a dead keyboard are different faults with different fixes. Once the session is reliable, move it out of the tab strip, since a connection that can be closed by a stray keystroke will eventually be closed by one. A builder such as Kagemusha turns the access page into a window with its own icon and its own signed in account, which is the part that stops being worth repeating by hand.