Hi I have a Ubuntu VM loaded as per instructions and have everything setup. Accessing the VM from host with Firefox/Canary/Chrome… all have the same error with the Cross-Origin.
I tried the docker prod, docker dev and even PPM running…Nothing works at all…
Please help!
Ive just posted a similar issue to this, well, same issue… did you resolve it?
are you using Ollama? I am aware of some CORS issues with Ollama, this error references Cross Origin, I wonder if its related to CORS?
Its literally not working with anything. Ollama or web sources…anything that uses the bolt terminal is not working.
The only working version I have is Docker Desktop on Windows and then http://localhost:5xxxx …that works because localhost does use CORS …
but anything trying to reach the VM running it does like CORS… no idea how to fix…tried all ChatGPT solutions like edit vite.config.ts to deal with CORS and COOP COEP and rebuild Docker but no go.
I honestly can’t see how anybody is running this on a VM and accessing it from the host browser (which is very common use case)…without doing some sort of fix.
in my scenario:
oTToDev is running on a remote docker
Ollama is running on a remote machine
They happen to be the same machine.
Browswer is running remotely, through Tailscale so I am using the Tailscale hostname to access the oTToDev URL
I reckon these errors are coming from oTToDev and not ollama, since the inference seems to be working fine… agree?
Agree. The problem is the vite server is treating and enforcing CORS/COOP/COEP.
I don’t know enough of how to circumvent this.
http://localhost:5xxx from the machine where it runs, works w/o error…but that is not a suitable situation.
Are you running an updated version of the Chrome Canary browser? This sounds like the necessary support for cross-origin isolation is missing.
In terms of site hosting, there is a page on the webcontainers site specifically related to these headers and support, there are other resources related to github pages, etc.
Hope this helps
I watched Eric from Bolt.new create an app.
In his prompt he asked the model to handle CORS.
Hope this helps.
I worked around the ollama cors issues by add this value to my Ollama container
Am running the latest Canary on Windows 11.
No luck.
Can you tell me which file to edit this into (from a default bolt install). The project I am creating uses vite (don’t know if this helps).
this is completely issue from webcontainer issue, it needs coop/coep headers
i have an api server running on my localhost scraping web data
what ever i do bolt can not access it. no idea why.
tells me 50 times its fixed the issue and it never works.
i gave up wasted like 5m tokens.
Our issue is not with Ollama, inference is working fine, it’s the inability for the bolt terminal to spawn, therefore no files can be created / read / executed etc
In fact not only ollama but any api call to an LLM whether local or remote has same issue.
Is this the same issue, have you seen this post? Failed to spawn bolt shell - Failed to execute 'postMessage' on 'Worker': SharedArrayBuffer transfer requires self.crossOriginIsolated
I spung up a new windows VM to test this “Cross-Origin” issue and I was able to bypass the error or reproduce it at will. The bypass is just a workaround not a solution as I am able to get the code to run in the bolt window only. We will need to pinpoint the exact setting that needs to be disabled/allowed in your browser, so yes, the workaround is to go into “Internet Option” and set it to a custom setting with most option set to allow allowed along with XSS filter. As stated this is not a solution as I bypass most of the browser security settings.
Does this work with Chrome / Chrome Canary?
I tested with regular Chrome and Firefox, but I had to scrapped that since the browser states it was “not secured” I eventually created a host file in windows “C:\Windows\System32\drivers\etc\hosts” so I do not have to use Cloudflare to access it and use PFSense HA proxy to give it an SSL (HTTPS). I have not duplicate the setup so I am not sure if it can be replicated. below is what it looks like with https access.
The browser is responsible for enforcing CORS. The the only way around it is to enable the Vite server to setup a proxy and perform route mapping to the destination (or maybe setting up an NGINX). Vite should have a mechanism to do this since React, Angular, etc. all have the ability to do this.
Somewhere this needs to be added to the server code in order to handle proxy requests:
import { defineConfig } from ‘vite’;
import vue from ‘@vitejs/plugin-vue’;
export default defineConfig({
plugins: [vue()],
server: {
proxy: {
‘/api’: {
target: ‘http://your-api-server.com’, // Replace with your API URL
changeOrigin: true,
rewrite: (path) => path.replace(/^/api/, ‘’),
},
},
},
});
If believe this proxy bit of code can also acommadate non-CORS requests as well by just switching the target server: Http://your-api-server.com to localhost.