They are though.
The URL that the extension is on is the same for hosted test and release.
The whole point of hosted test is that it’s identical to release.
Going from hosted test to release just makes the extension public/visible to viewers.
It doesn’t move where the files are/change the domain.
So if having CORS issues, either use a catch all CORS rule, or debug the issue.
Some errors can manifest as a CORS issue, for example you protest your API route only with a CORS header, but for some reason yoru API route 404’s your server then issues a redirect to a 404 page which doesn’t ahve a CORS header.
This then raises a CORS error, but it’s not a CORS error, it’s a 404.
Another example is that the NGINX in front of your NODE server is up, but the Node server is down. This raises a 503 error, as the backend is down, BUT will raise a CORS error as theres no CORS headers on the 503 page that nginx generates.
So it’s possible that you don’t have a CORS error but something else, that end logs in the browser as a CORS error.
So if you get CORS error you need to leaf thru your network tools carefully.
And consider additional logging on your server to monitor what actually is going on/attempting to be loaded.
Thats why when I do use “lists of domains” in my CORS config, I list my localtest in that URL, since my localtest isn’t “localhost” its’ a real domain with a reverse SSH Tunnel.
So my “live” nginx production server handles the SSL and real domaining for extension testing.
Localtest just means “not on Twitch’s CDN” so you could have your localtest be the same server as your EBS for example. Then you have SSL handled and a known URL to add to yoru CORS list when using “lists” of domains rather than a catch all.