Chrome Remote Desktop sets the value of DISPLAY to :20 (or whatever number it chooses for the session if :20 is unavailable).
If DISPLAY is :0, that means something else is overriding it.
It's unusual for scripts to modify the value of DISPLAY. That would break many things (SSH + X11-forwarding, multi-seat setups, ...)
Maybe something in your own startup files (such as ~/.bashrc) is hard-coding DISPLAY=:0 ?

Thanks for the explanation. 

>  Maybe something in your own startup files (such as ~/.bashrc) is hard-coding DISPLAY=:0 ?


I was using screen and I may have done something stupid there. 

You haven't done anything stupid! :) This is a general problem with 'screen' and other terminal multiplexers. If you create a 'screen' session on DISPLAY :0, and you attach to it from Chrome Remote Desktop (CRD), that session will still have the old value of $DISPLAY.

It isn't just $DISPLAY that causes issues with 'screen'. CRD also sets up some other variables:

LD_LIBRARY_PATH is set so that programs running in CRD use software-rendered OpenGL.

CHROME_USER_DATA_DIR is set so that Chrome uses a separate profile. When you run Chrome inside CRD, it will run a new browser session and won't try to connect to any pre-existing Chrome session on :0 .

PULSE_... variables are set to ensure that programs running in CRD use a virtual audio output device, so that audio gets remoted through CRD.

If any of these variables are captured in a 'screen' session, it can affect programs that rely on them. For example, if you start a session within CRD, and try to attach to the session on your physical display :0, and try to run Chrome, you will find that Chrome behaves as if it's running in CRD. And programs won't play any sound, because they try to use CRD's audio device. And GPU hardware-acceleration will stop working for those programs.

It's better to avoid starting graphical apps from a 'screen' session. If you have to do this, you need to manage the DISPLAY variable yourself.