It doesn't matter that it theoretically all happen in the browser. You can serve different versions to different IPs etc. Every heuristic in me would be screaming don't use that if I would have a need for such tool.
The only way an attack vector is possible here is if you think GitHub themselves would maliciously inject an altered version of the code in the repo, and even then you'd be able to see the code and network requests in your developer tools.
Just distribute the code for local execution? Sure, it's less accessable for the target audience, but it is more transparent.
But what else is new? Most users are willing to sacrifice privacy and security for convenience. That's how we got into this whole mess.
I mean, I get what you mean, but this is literally what's already happening. It's distributed via HTTP, and executed in your browser. You can save it (Ctrl-S, still a thing browsers do), and -- since it's distributed in source form -- easily inspect it, or reopen it later, in a different browser on a different computer. A zip file of the same thing is available on the repo (it's a zip of the repo).
If you don't trust that it won't access the web, disable your internet while running it or some such, as with other code you don't trust. If you don't trust it to mess with your files, well, you're in luck because modern browsers are probably the best audited sandbox out there.
I say I get what you mean, because most people won't do any of it. Instead of saving the page and running what they trust or have verified to be a safe snapshot of the page, they'll reopen the hosted version, trusting that it's still safe, even though the page may have been replaced with one that does upload their files.