Chrome Remote Desktop Unattended Access: Setup and Limits

Yes, Chrome Remote Desktop does unattended access, although Google’s help pages never use that word. What the rest of the industry calls unattended access, Google calls Remote Access: a host installed on your computer, registered to your Google account and protected by a PIN. The short answer: it works well for reaching your own PCs and Linux VMs at no cost, and it is the wrong tool for managing other people’s machines. Facts below were checked on 9 November 2026 against Google’s help pages and its Linux package repository. Speed, behaviour after a reboot and behaviour on your network are not tested yet.

Remote Access and Remote Support are different things

CriterionRemote Access (unattended)Remote Support (attended)
Addressremotedesktop.google.com/accessremotedesktop.google.com/support
Who must be at the computerNobody, once it is set upThe person sharing, who approves the connection
How you get inYour Google account plus the host’s PINAn access code that works one time
Session limitNone described in Google’s helpThe sharer confirms every 30 minutes
Ends whenYou choose “Disable remote connections” or remove the hostThe sharer clicks Stop Sharing

If a search for “unattended” led you to the Generate Code button, that is the wrong half of the product. A code needs someone at the keyboard every time.

Version, licence and requirements

  • Version: the Linux host is 157.0.8103.19 in Google’s apt repository (index dated 3 November 2026). Google publishes no changelog, and Windows and macOS hosts update themselves.
  • Licence: free, proprietary, no paid edition.
  • Hosts: Windows, macOS and Linux through a 64-bit Debian package. Android and iOS devices can only connect, not be connected to.
  • Clients: Chrome and the Android and iOS apps.
  • Required: a Google account and an internet connection on both ends. There is no self-hosted option.

Set up unattended access on Windows or macOS

  1. On the computer you want to reach, open Chrome and go to remotedesktop.google.com/access.
  2. Under “Set up Remote Access”, click Download and follow the prompts to install the host. You may have to enter the computer’s password.
  3. On a Mac, grant Accessibility and Screen Recording in System Settings, Privacy & Security. Without them you get a blank screen or clicks that do nothing.
  4. Choose a computer name and a PIN of at least six digits.
  5. From another device, sign in to the same Google account, open the same address, select the computer and enter the PIN.

To stop access, return to that page and click “Disable remote connections” next to the computer. To remove the software, uninstall “Chrome Remote Desktop” from Programs in Control Panel on Windows, or run “Chrome Remote Desktop Host Uninstaller” on a Mac.

Set up a headless Linux server or VM

A machine with no browser needs the command-line route. Google’s Compute Engine guide documents it, and the same page works for any Debian or Ubuntu server you can reach over SSH.

  1. Install Google’s 64-bit Debian package together with a light desktop such as Xfce:
    sudo apt-get install ./chrome-remote-desktop_current_amd64.deb xfce4
  2. On your own computer, open remotedesktop.google.com/headless, click Begin, then Next, then Authorize. The page prints a command with a one-time code.
  3. Run that command on the server, as the user who will own the session, and set a PIN when asked:
    DISPLAY= /opt/google/chrome-remote-desktop/start-host \
        --code="4/xxxxxxxxxxxxxxxx" \
        --redirect-url="https://remotedesktop.google.com/_/oauthredirect" \
        --name=$(hostname)
  4. Check the service:
    sudo systemctl status chrome-remote-desktop@$USER
  5. To always start one desktop, take the command from the Exec= line of its file in /usr/share/xsessions/ and put it in ~/.chrome-remote-desktop-session:
    exec /etc/X11/Xsession 'startxfce4'

    The change applies the next time the host restarts.

On Linux the host starts its own virtual session rather than showing the physical console. Google warns that a desktop environment may not support two sessions at once, so use different desktops for local and remote work, or sign out of one before opening the other.

Windows Server and other Windows machines without a usable browser have an equivalent: the same setup page prints a PowerShell line that runs remoting_start_host.exe with the code, and you enter a 6-digit PIN at the prompt.

The limits of unattended access

  • Account-bound. Hosts belong to the Google account that registered them. There is no technician console, device groups, session recording or audit report.
  • The host must be online. Google’s help says only that both sides need an internet connection, and it describes no wake feature. Treat a sleeping or hibernating PC as unreachable and adjust its power settings. Not tested yet.
  • Login screen and reboots. Google does not document whether every host accepts a connection before anyone signs in after a restart. Not tested yet, so check this on your own machine before you leave the building.
  • Privacy on the far side. Anyone standing at the host can see your session, unless Curtain mode is on.
  • No self-hosting. Connections are negotiated through Google’s services, so an outage or an account lockout stops access.

Curtain mode and network control for admins

Curtain mode hides the session from anyone at the physical machine, but Google limits it to Windows Professional, Ultimate, Enterprise and Server. It is no longer supported on macOS Big Sur or later. On Windows it needs RemoteAccessHostRequireCurtain set to 1, and also fDenyTSConnections set to 0 and UserAuthentication set to 0 under the Terminal Server keys. Those last two values turn on Remote Desktop connections and relax its network-level authentication, so weigh that before rolling it out.

GoalControl from Google’s documentation
LAN or VPN connections onlyRemoteAccessHostFirewallTraversal off (0 on Windows, NO on Mac, FALSE on Linux)
No traffic relayed through GoogleRemoteAccessHostAllowRelayedConnection
Fixed UDP ports for firewall rulesRemoteAccessHostUdpPortRange
Google account must match the local account (Mac, Linux, ChromeOS)RemoteAccessHostMatchUsername
Block the service entirelyBlock remotedesktop-pa.googleapis.com

If the connection fails, check these first: outbound UDP and its replies, TCP 443, and TCP and UDP 3478 for STUN. On restrictive networks also allow remotedesktop.google.com, remotedesktop-pa.googleapis.com and instantmessaging-pa.googleapis.com. Sessions use WebRTC and try a direct path, then STUN, then a relay through Google. UDP is preferred, with a fallback to TCP. Antivirus can also block the host. For wider hardening, see the remote access security checklist.

How it compares for unattended use

CriterionChrome Remote DesktopRustDeskMeshCentral
LicenceFree, proprietaryFree, open sourceFree, open source
Version in our catalogue157.0.8103.19 (Linux host)1.4.9 (6 Jul 2026)1.2.6 (24 Sep 2026)
Sign-inGoogle account and PINDevice ID and permanent passwordAccounts on your own server
Self-hostedNoYes, optionalYes, required
After a rebootNot documented, not tested yetInstalled service stays reachableAgent-based
Fleet toolsNoneClient settings pushed by config stringDevice groups in a web console

RustDesk is the closest swap if you want your own server. MeshCentral fits when you look after many machines. AnyDesk and TeamViewer are shareware (conditionally free) and free for personal use only, so unattended access to a work machine needs a licence. More options are in the free remote desktop comparison and the self-hosted remote access guide.

Who it suits and who it does not

It suits individuals reaching their own PCs, small offices with a handful of machines where each person owns their host, and admins who want a quick desktop on a Linux VM without opening an inbound port.

It does not suit help desks and MSPs that need to manage customers’ computers, organisations that need session recording or audit logs, or anyone who cannot depend on a Google account.

FAQ

Does Chrome Remote Desktop allow unattended access?

Yes. Set up Remote Access on the host, and you can connect later with your Google account and PIN while nobody is at the computer. The one-time codes under Remote Support are for attended sessions only.

Can I use Chrome Remote Desktop unattended on Ubuntu?

Yes. Google packages the host for 64-bit Debian-based systems, and remotedesktop.google.com/headless handles servers without a browser. You get a virtual session rather than the physical screen.

How long is the Chrome Remote Desktop PIN?

At least six digits. The PIN is checked in addition to your Google sign-in, so use a number that is not used anywhere else.

Why does Chrome Remote Desktop say it cannot connect?

Google’s list starts with internet access on both ends, firewall or antivirus rules for UDP, TCP 443 and port 3478, a current version of Chrome, and administrator restrictions on work or school networks and managed accounts.

What are the disadvantages of Chrome Remote Desktop?

It requires a Google account and Google’s infrastructure, has no central console or session recording, offers no changelog, and packages its Linux host for Debian-based systems only.

Is Chrome Remote Desktop secure for unattended use?

Google states that all sessions are fully encrypted, but we have not audited that claim. In practice, access is as strong as the Google account, so turn on two-step verification and remove hosts you no longer use.

Last updated: 9 November 2026 · CtrlRemote editorial team. Licence, version and platform details are checked against each developer's official documentation.

Submit your application