Chrome Remote Desktop on a Mac: one window for the other machine

Chrome Remote Desktop works, which is the reason so many people end up living with the one part of it that does not. The remote machine appears inside a browser tab, and from that moment the desktop of another computer is competing for space with a tab strip, an address bar, and thirty unrelated tabs. Google's own instructions end the section on stopping a session with the words close your tab, which is an accurate description of the architecture and also a warning. This covers what Google documents for macOS, what the network has to allow, and how to stop the session from being a tab.

Two addresses, two different jobs

Almost all of the confusion around Chrome Remote Desktop comes from mixing up the two web addresses, because they do genuinely different things and Google keeps them separate.

remotedesktop.google.com/access is for machines that belong to the same person. Set up remote access on the computer that will be reached, and it appears in a list on every other computer signed into the same Google account. Connecting takes a PIN. This is the route for reaching an office Mac from home, or a home desktop from a laptop.

remotedesktop.google.com/support is for someone else's machine, one time. The person being helped generates an access code and sends it over. The helper enters it under Give support and connects. Google documents two limits on this that matter: the access code works only once, and while a computer is being shared the person sharing it is asked to confirm that they want to continue every 30 minutes.

The second limit is the one that catches people out on long jobs. A thirty minute confirmation prompt means unattended support of somebody else's machine is not what the support route is built for. If a machine genuinely needs to be reachable without anyone sitting at it, that is the access route, set up in advance on the machine itself, not a support code.

Both routes open in a browser, and Google's instructions for every one of them start the same way, with opening Chrome and entering the address. Nothing is installed to be the person connecting out. Software is installed only on the machine being reached.

Connecting out from a Mac

For a Mac that is only ever the one doing the connecting, the setup is shorter than most guides suggest. There is no host component to install and no permission dialog to approve. The documented steps are to open Chrome, enter remotedesktop.google.com/access, click Access to choose which computer, enter the PIN, and select the arrow to connect.

The PIN is worth understanding as a second factor rather than a formality. Being signed into the Google account lists the machines. The PIN is what actually opens one. Google also states that all remote desktop sessions are fully encrypted, and that it collects and stores some anonymised data about network delays and session length to improve the service.

Ending a session is where the architecture shows. Google documents two ways: Options then Disconnect, or simply closing the tab. Both are correct, and the second one is the problem. On a Mac, the keystroke that closes a tab is one key away from several things done constantly, and in a long session the same keystroke is being sent through to the remote machine some of the time and caught by the local browser the rest of the time. Sessions get killed by accident, not by decision.

The machine being reached is a separate piece of work

The asymmetry is easy to miss when both ends are Macs owned by the same person. Setting up the machine that will be reached means downloading and installing Chrome Remote Desktop on it, and Google notes that a computer password may have to be entered to give it access, and that a prompt to change security settings may appear. That is a one time job done while sitting in front of that machine, and it cannot be done from the other end. Anyone setting up both sides should do the host side first, in person, before travelling.

Removing a machine from the list is the other operation worth knowing before it is needed. Next to the computer in the list at remotedesktop.google.com/access, the control is Disable remote connections. On a Mac being retired, the host software is removed by finding and launching the application named Chrome Remote Desktop Host Uninstaller.

Why a remote desktop is the worst possible tab

Three things go wrong specifically because the session is a tab, and none of them are about connection quality.

The first is vertical space. A remote screen is scaled to fit whatever height is left after the tab strip and the address bar have taken theirs. On a laptop display that is a meaningful fraction of the picture, and the cost is paid continuously, in text that is slightly too small to read comfortably for the entire session.

The second is keyboard collision. Every shortcut typed into a remote desktop has to reach the other machine, and the local browser is standing in the way of a good number of them. Window and tab management keys are the obvious casualties. A shortcut that should have gone to the remote application closes the session instead, and Google's own documentation confirms that closing the tab is the same thing as ending the session.

The third is ordinary tab loss. A remote session is something people leave running while doing other work, which is exactly the condition under which a tab migrates into another window and cannot be found. There is no Dock icon and no entry in the application switcher, so the only way back is to go looking through tab strips.

None of this is a fault in Chrome Remote Desktop, which is doing something impressive inside the constraints of a web page. It is a mismatch between what the thing is and where it lives. The fix is to change where it lives.

What the network has to allow

When a connection fails, the cause is usually one of a short list of things Google names directly, and checking them is faster than guessing.

The connection needs the internet on both ends, and if the page itself will not open, Google points at the computer's network settings first. Antivirus software is called out explicitly as something that can prevent Chrome Remote Desktop from working, along with the specific traffic 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, which is STUN.

Two policy conditions are worth checking before spending an hour on firewall rules. If the computer being accessed is on a work or school network, Google states it might not let a person give others access, and points at the administrator. And on a managed account, an administrator may control access to Chrome Remote Desktop outright. A setup that works perfectly from a personal account and fails from a work account is usually policy rather than plumbing.

The last item on Google's troubleshooting list is the dull one that fixes things anyway: make sure Chrome is up to date.

Giving the session a window of its own

Method	Engine	Session and cookies	Fits Google's documented path
Safari, Add to Dock	Safari	Separate from Safari	Google's instructions name Chrome
Chrome, Install page as app	Chrome	Shared with the Chrome profile	Yes
A site to app tool	Chosen per app	Isolated per app	Yes, when built on Chrome or Chromium

The engine column is the one that decides this, and it is why the answer here differs from other web applications. Google's instructions for every part of Chrome Remote Desktop begin with opening Chrome, and its troubleshooting list ends with keeping Chrome current. A window built on Safari may well work, but it is outside the documented path for a service whose reliability is the entire point.

Chrome's own route is documented as More, then Cast, save, and share, then Install page as app, with an Install button appearing in the address bar on some sites. The window that results belongs to the Chrome profile that made it, so the Google account is already signed in and nothing needs re entering. Uninstalling is documented from inside the running app, as More then Uninstall, with an option to also delete its data from Chrome.

The gain is immediate and larger than it sounds. The tab strip and address bar are gone, so the remote screen gets the whole window. There is a Dock icon, so the session is one click away instead of a search through tab strips. And the window is not sitting inside a browser window full of other work, so the shortcuts that used to close it by accident have nothing to close.

A purpose built tool earns its place in the case Chrome's own route handles least well, which is more than one of anything. The features list describes what such a tool sets up per app, and supported services shows how many other work sites end up treated the same way.

Two accounts, two machines, two windows

The multiple account problem is not a corner case for anyone who does support work or who keeps personal and work machines separate.

Chrome Remote Desktop lists machines per Google account, and browser cookies are shared across every tab and every installed app in one Chrome profile. One profile therefore shows one account's machines. Reaching a work machine and a personal machine means either signing in and out repeatedly, or creating a second Chrome profile and installing a second window from inside it.

That second path works and is worth knowing, but it is administered at the profile level, which means the Chrome profile picker becomes part of the daily routine. A tool that isolates the session per application reaches the same result without that, because each window carries its own cookies by construction rather than by remembering which profile to launch from.

The same logic covers the support case. Someone who helps clients regularly wants one window pointed at the support page and a different one pointed at their own machine list, named after what each one does. Windows named after the job are findable in the application switcher. Windows named after the product are not.

What to change first

Decide which of the two addresses is actually in daily use, then build one window on it with Chrome rather than Safari, since Chrome is the browser Google's own instructions name. Point it at the machine list or the support page, not at a sign in screen, and name it after the machine or the client. If it turns into two windows for two accounts, a tool such as Kagemusha gives each one its own isolated session instead of leaving the browser profile picker in the middle of the routine.