Chrome Remote Desktop app on a Mac: what exists

On a Mac, the Chrome Remote Desktop "app" is three separate things, and only one of them is something you open. The download on the setup page installs a background host that lets the Mac be controlled. The screen you control from is a web page at remotedesktop.google.com. The only downloadable client app is for phones and tablets. So if you installed it and found nothing new in Applications or the Dock, nothing went wrong. Below: what each part does, how to give the web client a window of its own, what macOS has to allow, and the settings that stop sessions from dropping. Every official page cited here was opened and checked on October 18, 2026.

The three pieces, named correctly

Google's own help page, Access another computer with Chrome Remote Desktop, says it in two sentences: "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." Once you see the split, most of the confusion goes away.

Piece	Where it comes from	What it does	Has a window
Host	Download button under "Set up Remote Access" at remotedesktop.google.com/access	Lets this Mac be reached and controlled	No
Web client	The page remotedesktop.google.com in Chrome	Shows and controls another computer	A browser tab, or its own window if installed as a web app
Companion extension	Chrome Web Store	Lets the web page install and manage the native host	No
Mobile app	Google Play and the iPhone and iPad store	Controls a computer from a phone or tablet	Yes, on the phone

The Chrome Web Store listing calls itself "the companion extension for the Chrome Remote Desktop website". On October 18, 2026 it showed version 2.1, last updated August 9, 2024, 22.66 KiB, and 41,000,000 users. It is a helper for the site. It is not a client you launch.

The Android app on Google Play showed 10M+ downloads and an update dated February 26, 2026 on the same day. That is the "app" that keeps turning up in search results. It is a real app, and it is the reason people assume a desktop version must exist too.

Why the old Chrome app is gone

Anyone who used Chrome Remote Desktop years ago remembers a tile in the Chrome app launcher. That format is retired outside ChromeOS. The Chrome Web Store help page on Chrome apps says: "Chrome Apps in the Chrome Web Store are only supported on Chromebooks and won't work on Windows, Mac, or Linux after December 2022."

That explains why old walkthroughs describe install steps you can no longer follow, and why searching the Web Store mostly finds the companion extension and unrelated remote tools. The product moved to the open web. On a Mac, the client is now whatever container the browser gives that web page.

That container is something you can choose. The default is a tab. It does not have to stay that way.

Setting up the host on the Mac you want to reach

The official steps are short. Open Chrome, go to remotedesktop.google.com/access, click Download under "Set up Remote Access", and follow the installer. The help page warns that "You may have to enter your computer password" and that you "may also be prompted to change security settings". On a current Mac, those security settings are two panes under System Settings, then Privacy and Security.

The first is screen recording. Apple's guide Control access to screen and system audio recording on Mac covers where it lives. Without it, the controlling side connects but sees a black or frozen picture.

The second is accessibility. Apple's guide Allow accessibility apps to access your Mac covers it. Without it, the screen appears fine, but clicks and keystrokes from the other side do nothing.

Neither failure shows an error on the controlling computer, so tell them apart by which half is broken. Picture missing means screen recording. Input missing means accessibility.

After setup, the Mac appears in the list on the access page under the Google account that was signed in at the time. You choose a PIN during setup, and anyone connecting later has to type it. The help page notes that "all remote desktop sessions are fully encrypted."

To remove the host later, the help page names the tool: find the "Chrome Remote Desktop Host Uninstaller" application on the Mac and click Uninstall. That is also the quickest way to confirm the host is installed, because it is the one visible file the installer leaves behind.

Two kinds of session, and only one persists

The same product covers two jobs that behave very differently.

Remote access is the persistent kind. You install the host once, set a PIN, and the machine stays in your list until you remove it with "Disable remote connections". This is the setup for reaching an office Mac from home every day.

Remote support is the temporary kind. It runs from remotedesktop.google.com/support. The person being helped clicks Generate Code and sends the code to the helper, who enters it under "Give support". The help page sets the limits: "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." The person sharing also sees a dialog with the helper's email address and has to click Share.

Single-use codes and a check every half hour make support sessions safe for helping a relative and useless for unattended access. A support session left running overnight stops at the first prompt nobody answers. If you need to reach one specific machine most days, install the host on it and stop using codes. If you help different people now and then, you never need a host on your own Mac, only the support page.

Giving the web client a window of its own

Since the client is a web page, it picks up everything a browser does around a web page, including the parts that get in the way of a remote desktop.

The worst problem is keyboard shortcuts. A browser keeps its own shortcuts for closing a tab, switching tabs, opening a new tab and jumping to the address bar. On a Mac controlling another Mac, most shortcuts use the Command key, so these clashes happen constantly. The second problem is accidental closing. The help page's own instruction for ending a session is "close your tab to stop your session", so a stray keystroke that closes the tab ends the connection too. The third is space. A tab strip and an address bar take height from a screen that is already showing a scaled-down copy of another desktop.

There are three ways out of the tab, all available today.

Install the page as a web app in Chrome

The client page publishes a web app manifest. On October 18, 2026 it declared the name "Chrome Remote Desktop", the short name "Remote Desktop" and a display mode of "standalone". That means Chrome can install it as an app. Google's Use web apps help page gives the menu path: More, then "Cast, save, and share", then "Install page as app...". The installed app opens in its own window, with no tab strip, and Chrome lists it at chrome://apps. From there you can also choose "Launch at startup". This is the nearest thing to the old Chrome app, and it costs nothing.

Use a separate browser profile

A second Chrome profile signed in to the Google account that owns your machine list keeps that list one click away. It fixes the account problem in the next section, but it is still a tab in a browser window, so the keyboard clashes stay.

Wrap the page with a site to app tool

A tool that turns a website into a standalone Mac app builds a separate application around the page, with its own Dock icon, its own browser profile and per-app settings. That matters for a remote desktop in ways a plain installed web app does not cover. Details below.

Which Google account owns the machine list

The list of remote computers belongs to a Google account. On a Mac signed in to more than one, that becomes a real problem.

If the host was set up while a work account was active, the machine shows up under that account. Open the client later in a window where a personal account is in front, and the list is empty. It looks exactly like the host stopped working. Signing out and back in fixes it for the moment and breaks whatever else was using the other account.

The fix is to keep the accounts apart, not to keep switching. A window whose profile is tied to one account opens on the same machine list every time, whatever the main browser is doing. This matters more for remote access than for most services, because you usually need it at the moment you have least patience. An office machine missing from the list is a problem to solve before any real work can start.

What a dedicated wrapper adds for remote sessions

A plain installed web app removes the tab strip. A site to app tool adds controls aimed at the failures above. Taking one published product as a concrete example, its Guide lists these per-app settings:

Problem in a remote session	Setting that addresses it	Default in that tool
Command Q quits the window mid-session	Quit Confirmation shows a "Do you really want to quit?" dialog	Off, switch on per app
Tab strip and address bar take screen height	Tab Bar off shows only the web content	Off
Wrong Google account in front	Profile isolation gives each app its own cookies and sign-in	Always on
Sign-in popups blocked	Window Handling set to Smart allows sign-in dialogs and blocks the rest	Smart
Reopening lands on the wrong page	Tab Restore reopens the last tabs and scroll position	On

The same guide notes that each app gets its own profile automatically, and that you sign in once inside each new app. Point the app at remotedesktop.google.com/access rather than the marketing page, so opening it lands straight on your machine list. The Features page describes the profile isolation and the seven supported browser engines, and the Pricing section lists a free tier of up to three apps and a one-time Pro price of $24.99 for unlimited apps. Those were the figures shown on October 18, 2026.

Extensions deserve a thought too. The remote screen is a video stream, not a document, so an extension that rewrites page content has nothing useful to do there and can cause odd behavior. A password manager is still useful on the PIN screen. Per-app extension switches let a remote desktop window run with almost nothing installed.

When the connection is the problem, not the window

Some failures have nothing to do with which container the client runs in. The help page lists the network needs: outbound UDP traffic, inbound UDP responses, TCP port 443, and TCP and UDP on port 3478 for STUN. Antivirus or a corporate firewall that blocks UDP is the most common cause of a machine that shows as online but will not connect. On work or school networks, the help page notes that an administrator may block giving others access, and that managed accounts can be restricted by policy.

Sleep is the other common cause. A Mac that has gone to sleep, or that is sitting at the login window after a restart, will not answer the way a logged-in, awake Mac does. On a Mac that is mostly used remotely, set it not to sleep while on power, and check after every macOS update that the screen recording and accessibility grants are still there.

What to change first

First check which macOS permission is missing, because a black screen and a dead keyboard are different faults. Then get the client out of the tab strip. Install the page as a web app if keyboard clashes are the only problem, or build a separate app with its own profile and quit confirmation if you also switch Google accounts. Kagemusha is one way to build that second kind of window.