Thanks for your help. I didnt know this command ;-)

Well, in the end it turns out that many common providers for static content do not support this feature (e.g. GitHubPages, my specific provider, etc.). This means I will stick to pyscript.com for the moment.

However, this seems to be an issue when designing pyscript apps using py-editor. Are there any plans (maybe in the near future) to overcome this issue :D

we use GitHub Pages without issues through mini-coi exactly to circumvent public hosts limitations.

You can use that script on your page as long as the mini-coi is in the root of your project, or you can npx mini-coi . to bootstrap a webserver for static content that automatically provides those headers.

We need SharedArrayBuffer for tons of reasons so I am afraid that's not going to change as a simple while(True) loop would break your whole page with terminal or editor and we don't want that to happen (and indeed it doesn't happen with the worker approach, which is the default in the py-editor).

Would it be possible to minimize the friction @WebReflection by having pyscript automatically load mini-coi if the appropriate headers are not set?

Right now, I believe, you will be loosing non-technical users as they don't even know how to see the error message in the browser console. I also got "burned" by this as I jumped directly to the py-editor docs. And it was not mentioned there. Took me +10 mins before I found the solution in the PyScript docs because I started searching elsewhere.

minimize the friction by having pyscript automatically load mini-coi if the appropriate headers are not set?

no, because that's not how Service Worker files work: these MUST be on your site/server, these cannot be anywhere else.

Took me +10 mins before I found the solution in the PyScript docs because I started searching elsewhere.

Then we need to do a better job at making it obvious some header is needed for some feature to work ... the F.A.Q. section (IIRC) has one, though ... but the good news is that I am making a 3rd option/alternative that would still optionally require a Service Worker to work 100% but without affecting headers or requiring COI ... these are all inevitable technical details one must face to unlock full potentials of the project, there is no way around it ... we can eventually just fallback (which is a WIP hopefully ready soon).