github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-23 22:21:55 -05:00
Code Issues 16.9k Packages Projects Releases 122 Wiki Activity

[GH-ISSUE #2308] Expose Ollama Service to use it in Chrome Browser Extension #1331

New Issue
Closed
opened 2026-04-12 11:09:44 -05:00 by GiteaMirror · 35 comments
GiteaMirror commented 2026-04-12 11:09:44 -05:00
Owner
Copy Link

Originally created by @christophrothmann on GitHub (Feb 1, 2024).
Original GitHub issue: https://github.com/ollama/ollama/issues/2308

Hey guys,
can you show us, how we can actually use the provided Ollama API's in an chrome extension.
I tried it before, but I get an 403 - Forbidden error. I already looked in the ollama documentation but did not found anything useful.

Hopefully someone can show us how to use it properly. I opened a stackoverflow question before.

Best regards,
Chris

Originally created by @christophrothmann on GitHub (Feb 1, 2024). Original GitHub issue: https://github.com/ollama/ollama/issues/2308 Hey guys, can you show us, how we can actually use the provided Ollama API's in an chrome extension. I tried it before, but I get an 403 - Forbidden error. I already looked in the ollama documentation but did not found anything useful. Hopefully someone can show us how to use it properly. I opened a [stackoverflow question](https://stackoverflow.com/questions/77911717/issue-with-calling-a-local-ollama-api-from-chrome-extension) before. Best regards, Chris
GiteaMirror commented 2026-04-12 11:09:45 -05:00
Author
Owner
Copy Link

@remy415 commented on GitHub (Feb 1, 2024):

@DevChrisRoth

Is your Ollama instance being served on the same PC? If not, you may need to set the OLLAMA_HOST environment variable to an interface that allows external connections, and the OLLAMA_ORIGINS environment variable to allow cross-origin requests.

OLLAMA_HOST=0.0.0.0 # Listen on all interfaces

I'm not exactly sure how the OLLAMA_ORIGINS environment variable works, try setting it to the machine you're running the chrome extension on.

https://github.com/ollama/ollama/blob/main/docs/faq.md#how-can-i-expose-ollama-on-my-network

<!-- gh-comment-id:1921374075 --> @remy415 commented on GitHub (Feb 1, 2024): @DevChrisRoth Is your Ollama instance being served on the same PC? If not, you may need to set the OLLAMA_HOST environment variable to an interface that allows external connections, and the OLLAMA_ORIGINS environment variable to allow cross-origin requests. OLLAMA_HOST=0.0.0.0 # Listen on all interfaces I'm not exactly sure how the OLLAMA_ORIGINS environment variable works, try setting it to the machine you're running the chrome extension on. https://github.com/ollama/ollama/blob/main/docs/faq.md#how-can-i-expose-ollama-on-my-network
GiteaMirror commented 2026-04-12 11:09:45 -05:00
Author
Owner
Copy Link

@remy415 commented on GitHub (Feb 1, 2024):

@DevChrisRoth

Ollama uses the Gin CORS package to handle origin requests:
https://github.com/gin-contrib/cors?tab=readme-ov-file#canonical-example

The origin will be whatever domain or IP you're hosting the service that will be connecting to the Ollama API. For example, if you have a button on a website that sends data to the Ollama API, and the user will type "https://example.domain.com/ollama" to get to your website, then put "example.domain.com" in your OLLAMA_ORIGINS environment variable.

If you set OLLAMA_ORIGINS=192.168.0.69, your Ollama instance will allow connection requests originating from 192.168.0.69, meaning you're hosting your user interface on that IP address. You can also set it to OLLAMA_ORIGINS=example.domain.com,192.168.0.69, and your Ollama instance will allow connection requests originating from both example.domain.com and the IP 192.168.0.69.

Edit: Fixed format

<!-- gh-comment-id:1921446867 --> @remy415 commented on GitHub (Feb 1, 2024): @DevChrisRoth Ollama uses the Gin CORS package to handle origin requests: https://github.com/gin-contrib/cors?tab=readme-ov-file#canonical-example The origin will be whatever domain or IP you're hosting the service that will be connecting to the Ollama API. For example, if you have a button on a website that sends data to the Ollama API, and the user will type "https://example.domain.com/ollama" to get to your website, then put "example.domain.com" in your OLLAMA_ORIGINS environment variable. If you set `OLLAMA_ORIGINS=192.168.0.69`, your Ollama instance will allow connection requests originating from 192.168.0.69, meaning you're hosting your user interface on that IP address. You can also set it to `OLLAMA_ORIGINS=example.domain.com,192.168.0.69`, and your Ollama instance will allow connection requests originating from both example.domain.com and the IP 192.168.0.69. Edit: Fixed format
GiteaMirror commented 2026-04-12 11:09:46 -05:00
Author
Owner
Copy Link

@christophrothmann commented on GitHub (Feb 1, 2024):

@remy415
Yeah, thanks for your comment but the issue that I have is, that I make that API call from a Chrome Browser Extension.

I have written a browser extension and when I click on the button of that little window, I make an API call to my local hosted Ollama instance on my pc

Here my Plugin:
--removed the image

...and my api call:
image

...and the required (I believe)
permissions in the manifest.json File
image

Maybe that information helps :)

<!-- gh-comment-id:1921534827 --> @christophrothmann commented on GitHub (Feb 1, 2024): @remy415 Yeah, thanks for your comment but the issue that I have is, that I make that API call from a Chrome Browser Extension. I have written a browser extension and when I click on the button of that little window, I make an API call to my _local_ hosted Ollama instance on my pc Here my Plugin: --removed the image ...and my api call: ![image](https://github.com/ollama/ollama/assets/58110317/42e2c2ed-f9ad-435d-834f-64de955c36ac) ...and the required (I believe) permissions in the manifest.json File ![image](https://github.com/ollama/ollama/assets/58110317/a2309da4-1a6f-4714-93b8-1c06dd19f624) Maybe that information helps :)
GiteaMirror commented 2026-04-12 11:09:46 -05:00
Author
Owner
Copy Link

@christophrothmann commented on GitHub (Feb 1, 2024):

I also set the OLLAMA_HOST=0.0.0.0

<!-- gh-comment-id:1921536449 --> @christophrothmann commented on GitHub (Feb 1, 2024): I also set the OLLAMA_HOST=0.0.0.0
GiteaMirror commented 2026-04-12 11:09:47 -05:00
Author
Owner
Copy Link

@remy415 commented on GitHub (Feb 1, 2024):

Can you confirm the API is working properly with a curl request from cli?

curl http://localhost:11434/api/generate -d '{ "model": "codellama",
"prompt": "Why is the sky blue?", "stream": false }'

Edit: Removed metadata sent by my mail client

<!-- gh-comment-id:1921580803 --> @remy415 commented on GitHub (Feb 1, 2024): Can you confirm the API is working properly with a curl request from cli? curl http://localhost:11434/api/generate -d '{ "model": "codellama", "prompt": "Why is the sky blue?", "stream": false }' Edit: Removed metadata sent by my mail client
GiteaMirror commented 2026-04-12 11:09:47 -05:00
Author
Owner
Copy Link

@christophrothmann commented on GitHub (Feb 1, 2024):

Hi @remy415 ,
yes I confirm that. I tested it with Postman. 😎😉
Maybe Ollama allows no request from an browser extension 😅.

Just to clarify, I did not clone the Ollama repo itself and run that. I run the Application downloaded from the official ollama.ai webpage. Should I try to clone and run that? Makes that a difference?

Best,
Chris

<!-- gh-comment-id:1921771113 --> @christophrothmann commented on GitHub (Feb 1, 2024): Hi @remy415 , yes I confirm that. I tested it with Postman. 😎😉 Maybe Ollama allows no request from an browser extension 😅. Just to clarify, I did not clone the Ollama repo itself and run that. I run the Application downloaded from the official ollama.ai webpage. Should I try to clone and run that? Makes that a difference? Best, Chris
GiteaMirror commented 2026-04-12 11:09:48 -05:00
Author
Owner
Copy Link

@remy415 commented on GitHub (Feb 1, 2024):

@DevChrisRoth
Building from src likely won't change the issue you're having, that's mostly just to change architectures or enable different CPU features (AVX512, etc) for the llama_cpp backend.

Can you enable debug on startup with OLLAMA_DEBUG=1 ollama serve and try the connect again, check your screen for the api requests and see what the server logs say when you connect

<!-- gh-comment-id:1921783054 --> @remy415 commented on GitHub (Feb 1, 2024): @DevChrisRoth Building from src likely won't change the issue you're having, that's mostly just to change architectures or enable different CPU features (AVX512, etc) for the llama_cpp backend. Can you enable debug on startup with `OLLAMA_DEBUG=1 ollama serve` and try the connect again, check your screen for the api requests and see what the server logs say when you connect
GiteaMirror commented 2026-04-12 11:09:50 -05:00
Author
Owner
Copy Link

@remy415 commented on GitHub (Feb 1, 2024):

Also, some people on the below stackoverflow forum had problems with other extensions interacting with theirs. Try disabling all other extensions and see if that fixes it.

In my case it was done due to an extension that I had on Chrome, try disabling all extensions and then try again. This may help someone else. I was stuck 3 days on this one tried everything and in the end the issue was caused by extension... –
nikola3103
Feb 15, 2022 at 10:07

<!-- gh-comment-id:1921795022 --> @remy415 commented on GitHub (Feb 1, 2024): Also, some people on the below stackoverflow forum had problems with other extensions interacting with theirs. Try disabling all other extensions and see if that fixes it. > In my case it was done due to an extension that I had on Chrome, try disabling all extensions and then try again. This may help someone else. I was stuck 3 days on this one tried everything and in the end the issue was caused by extension... – [nikola3103](https://stackoverflow.com/users/6400433/nikola3103) [Feb 15, 2022 at 10:07](https://stackoverflow.com/questions/63873773/fetch-request-from-chrome-extension-results-in-403-forbidden#comment125726747_63873773)
GiteaMirror commented 2026-04-12 11:09:50 -05:00
Author
Owner
Copy Link

@remy415 commented on GitHub (Feb 1, 2024):

Have you double-checked that your extension code is good? Is your button sending the proper messages to trigger the extension eventListener?

<!-- gh-comment-id:1921845987 --> @remy415 commented on GitHub (Feb 1, 2024): Have you double-checked that your extension code is good? Is your button sending the proper messages to trigger the extension eventListener?
GiteaMirror commented 2026-04-12 11:09:51 -05:00
Author
Owner
Copy Link

@christophrothmann commented on GitHub (Feb 1, 2024):

Hey @remy415 ,
I started the ollama serve with your command and got following logging messages back:

Bildschirmfoto 2024-02-01 um 19 30 06

I have not activated any other browser extensions, but thanks for your advice :)

<!-- gh-comment-id:1921967582 --> @christophrothmann commented on GitHub (Feb 1, 2024): Hey @remy415 , I started the ollama serve with your command and got following logging messages back: ![Bildschirmfoto 2024-02-01 um 19 30 06](https://github.com/ollama/ollama/assets/58110317/66f99fff-9f3a-4f95-b195-3d3ed014c7ca) I have not activated any other browser extensions, but thanks for your advice :)
GiteaMirror commented 2026-04-12 11:09:51 -05:00
Author
Owner
Copy Link

@mxyng commented on GitHub (Feb 1, 2024):

Extensions have their own origin. For Chrome, this should be chrome-extension:// so you'll need this for OLLAMA_ORIGINS

OLLAMA_ORIGINS=chrome-extension://...

See gin-contrib/cors

<!-- gh-comment-id:1922110323 --> @mxyng commented on GitHub (Feb 1, 2024): Extensions have their own origin. For Chrome, this should be `chrome-extension://` so you'll need this for `OLLAMA_ORIGINS` ``` OLLAMA_ORIGINS=chrome-extension://... ``` See [gin-contrib/cors](https://pkg.go.dev/github.com/gin-contrib/cors#pkg-variables)
GiteaMirror commented 2026-04-12 11:09:51 -05:00
Author
Owner
Copy Link

@christophrothmann commented on GitHub (Feb 2, 2024):

@mxyng ,
so I have to execute following in the terminal? (I'm using it on mac)
launchctl setenv OLLAMA_ORIGIN "chrome-extension://" and then run ollama serve?

Sorry to ask such a stupid question, but I'm new to this :)

<!-- gh-comment-id:1923431736 --> @christophrothmann commented on GitHub (Feb 2, 2024): @mxyng , so I have to execute following in the terminal? (I'm using it on mac) `launchctl setenv OLLAMA_ORIGIN "chrome-extension://"` and then run `ollama serve`? Sorry to ask such a stupid question, but I'm new to this :)
GiteaMirror commented 2026-04-12 11:09:51 -05:00
Author
Owner
Copy Link

@tomjorquera commented on GitHub (Feb 2, 2024):

I have the same issue, due to CORS (everything work fine when using non-browser clients).

@DevChrisRoth I worked around it for now by adding the following in my service file:

[Service]
ExecStart=...
Environment="OLLAMA_ORIGINS=moz-extension://*,chrome-extension://*"

It allows me to test my extension locally, but seems very cumbersome, as each user would need to configure their ollama instance with a similar setting.

What I don't understand is that why this behavior occurs despite me setting the proper host_permissions and calling from a background script. This is supposed to allow me to "access to those origins without cross-origin restrictions" (as per the doc linked).

I tried both with the host_permissions of manifest V3 and the old permissions setting of V2, but still get this behavior both in Firefox and Chromium.

<!-- gh-comment-id:1923553174 --> @tomjorquera commented on GitHub (Feb 2, 2024): I have the same issue, due to CORS (everything work fine when using non-browser clients). @DevChrisRoth I worked around it for now by adding the following in my service file: ``` [Service] ExecStart=... Environment="OLLAMA_ORIGINS=moz-extension://*,chrome-extension://*" ```` It allows me to test my extension locally, but seems very cumbersome, as each user would need to configure their ollama instance with a similar setting. What I don't understand is that why this behavior occurs *despite* me setting the proper [`host_permissions` ](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/host_permissions) and calling from a background script. This is supposed to allow me to "access to those origins without cross-origin restrictions" (as per the doc linked). I tried both with the `host_permissions` of manifest V3 and the old `permissions` setting of V2, but still get this behavior both in Firefox and Chromium.
GiteaMirror commented 2026-04-12 11:09:52 -05:00
Author
Owner
Copy Link

@christophrothmann commented on GitHub (Feb 2, 2024):

Hell yeah,
I finally figured it out.
I looked into the server.log file from Ollama ~/.ollama/logs/server.log and there was a useful error message.
Bildschirmfoto 2024-02-02 um 12 35 11

The solution was to start the Ollama Service in the terminal with following command:
OLLAMA_ORIGINS=chrome-extension://* ollama serve

Thanks for your help guys! @mxyng , @remy415 , @tomjorquera

<!-- gh-comment-id:1923630384 --> @christophrothmann commented on GitHub (Feb 2, 2024): Hell yeah, I finally figured it out. I looked into the server.log file from Ollama `~/.ollama/logs/server.log` and there was a useful error message. ![Bildschirmfoto 2024-02-02 um 12 35 11](https://github.com/ollama/ollama/assets/58110317/86deb19e-5cf2-4a18-a1fc-004fbbf363b8) The solution was to start the Ollama Service in the terminal with following command: `OLLAMA_ORIGINS=chrome-extension://* ollama serve` Thanks for your help guys! @mxyng , @remy415 , @tomjorquera
GiteaMirror commented 2026-04-12 11:09:53 -05:00
Author
Owner
Copy Link

@tomjorquera commented on GitHub (Feb 2, 2024):

Can we keep this issue open for now? I feel like the current solution is a workaround, and I don't get why this is needed despite the browser extension supposedly not having cross-origin restriction when set up properly.

<!-- gh-comment-id:1923680192 --> @tomjorquera commented on GitHub (Feb 2, 2024): Can we keep this issue open for now? I feel like the current solution is a workaround, and I don't get why this is needed despite the browser extension supposedly not having cross-origin restriction when set up properly.
GiteaMirror commented 2026-04-12 11:09:53 -05:00
Author
Owner
Copy Link

@remy415 commented on GitHub (Feb 2, 2024):

@tomjorquera I'm not an expert on browser and CORS configurations, but generally speaking the way you configure your browser to allow specific cross-origin types doesn't override the remote server's configuration to allow types. In this situation, the Ollama service should be considered a "remote server" as it is not explicitly coupled to your local host and is not a "client application". Ollama itself has its own configuration, and if you don't tell it to allow specific cross-origins then it will return a 403 error, even if your browser is configured to allow it. The browser configuration just means which "cross-origins" are allowed to run in the browser, but the server still needs to support it and allow it.

TL;DR: the "host_permission" configuration in the browser is to make the browser allow your COR, but that doesn't override or affect the "remote server" being configured to support and allow your COR.

<!-- gh-comment-id:1924024235 --> @remy415 commented on GitHub (Feb 2, 2024): @tomjorquera I'm not an expert on browser and CORS configurations, but generally speaking the way you configure your browser to allow specific cross-origin types doesn't override the remote server's configuration to allow types. In this situation, the Ollama service should be considered a "remote server" as it is not explicitly coupled to your local host and is not a "client application". Ollama itself has its own configuration, and if you don't tell it to allow specific cross-origins then it will return a 403 error, even if your browser is configured to allow it. The browser configuration just means which "cross-origins" are allowed to run in the browser, but the server still needs to support it and allow it. TL;DR: the "host_permission" configuration in the browser is to make the browser allow your COR, but that doesn't override or affect the "remote server" being configured to support and allow your COR.
GiteaMirror commented 2026-04-12 11:09:54 -05:00
Author
Owner
Copy Link

@tomjorquera commented on GitHub (Feb 2, 2024):

@remy415 I agree.

My question is : wouldn't it be better if the ollama server supported this use case without requiring specific configuration from the user?

<!-- gh-comment-id:1924033032 --> @tomjorquera commented on GitHub (Feb 2, 2024): @remy415 I agree. My question is : wouldn't it be better if the ollama server supported this use case without requiring specific configuration from the user?
GiteaMirror commented 2026-04-12 11:09:54 -05:00
Author
Owner
Copy Link

@remy415 commented on GitHub (Feb 2, 2024):

My question is : wouldn't it be better if the ollama server supported this use case without requiring specific configuration from the user?

Depends on the use case. Allowing various CORs by default would technically make the default installation less secure as the majority of users are just using "ollama run mistral", which doesn't require extension CORs be enabled.

It's purely a design choice, and personally I think leaving it off by default is the better option out of the box as it forces the developer to make a conscious decision about how they want to open their service up to external sources.

The Ollama team does reference setting the env variable to enable various CORS in their development documentation, too.

<!-- gh-comment-id:1924077061 --> @remy415 commented on GitHub (Feb 2, 2024): > My question is : wouldn't it be better if the ollama server supported this use case without requiring specific configuration from the user? Depends on the use case. Allowing various CORs by default would technically make the default installation less secure as the majority of users are just using "ollama run mistral", which doesn't require extension CORs be enabled. It's purely a design choice, and personally I think leaving it off by default is the better option out of the box as it forces the developer to make a conscious decision about how they want to open their service up to external sources. The Ollama team does reference setting the env variable to enable various CORS in their development documentation, too.
GiteaMirror commented 2026-04-12 11:09:55 -05:00
Author
Owner
Copy Link

@tomjorquera commented on GitHub (Feb 2, 2024):

Allowing various CORs by default would technically make the default installation less secure as the majority of users are just using "ollama run mistral", which doesn't require extension CORs be enabled.

I don't get why allowing access from a (properly configured) browser extension has different security implications than accessing ollama from any other local client installed by the user. Is there some technical limitation of CORs where allowing this would also open up others, less secure, uses also?

I'm genuinely interested in understanding which risks are mitigated by this restriction (taking in account the fact that the browser is already enforcing CORs, and that the extension has to explicitly ask for permission to access localhost from a background task in any case).

<!-- gh-comment-id:1924425770 --> @tomjorquera commented on GitHub (Feb 2, 2024): > Allowing various CORs by default would technically make the default installation less secure as the majority of users are just using "ollama run mistral", which doesn't require extension CORs be enabled. I don't get why allowing access from a (properly configured) browser extension has different security implications than accessing ollama from any other local client installed by the user. Is there some technical limitation of CORs where allowing this would also open up others, less secure, uses also? I'm genuinely interested in understanding which risks are mitigated by this restriction (taking in account the fact that the browser is already enforcing CORs, and that the extension has to explicitly ask for permission to access localhost from a background task in any case).
GiteaMirror commented 2026-04-12 11:09:55 -05:00
Author
Owner
Copy Link

@remy415 commented on GitHub (Feb 2, 2024):

That's the key words there: properly configured. Yours might be properly configured, but that doesn't mean that every browser extension is properly configured or even non-malicious. "ollama serve" is its own service: it listens on a port for external traffic. By default it's configured to listen only on localhost (another "more secure" default setting). "ollama run" is a separate part of the ollama application, but it isn't required to interact with the service component. In this particular context, ollama is a service listening on a port, and your browser extension is a client application connecting externally, regardless of your own personal use-case where client and server are both run locally.

When you release an application for general use, it's generally better to only enable features that are required for basic use. When you are configuring "ollama serve" for an external service, there are many other settings that also have to be configured anyway, so it would make sense from a generalized standpoint to also require the server maintainer to enable additional CORS.

Again, we're talking about default settings here: it's generally better to release a product that doesn't enable an inherently insecure feature (because remember: we can't assume everyone properly configures their chrome extension, or that a chrome extension isn't malicious). If a user wants to expose their ollama service externally, they must make the conscious decision to enable external access to their service, which forces a thought process about security.

Remember: exposing services to external clients always has inherent security risks. The cybersecurity field is massive, and well beyond the scope of this forum. Including things such as authentication, authorization, input sanitization, firewalls, etc. are all factors every server owner should think about before deploying any service that is exposed externally.

Last, my own two cents so take it how you will: I don't think it's a big ask to have a developer set an environment variable to configure their service to allow things like browser extensions. It's also mentioned in their developers guide, which users should probably be reading if they intend on developing software to use with ollama.

<!-- gh-comment-id:1924453768 --> @remy415 commented on GitHub (Feb 2, 2024): That's the key words there: properly configured. Yours might be properly configured, but that doesn't mean that every browser extension is properly configured or even non-malicious. "ollama serve" is its own service: it listens on a port for external traffic. By default it's configured to listen only on localhost (another "more secure" default setting). "ollama run" is a separate part of the ollama application, but it isn't required to interact with the service component. In this particular context, ollama is a service listening on a port, and your browser extension is a client application connecting externally, regardless of your own personal use-case where client and server are both run locally. When you release an application for general use, it's generally better to only enable features that are required for basic use. When you are configuring "ollama serve" for an external service, there are many other settings that also have to be configured anyway, so it would make sense from a generalized standpoint to also require the server maintainer to enable additional CORS. Again, we're talking about default settings here: it's generally better to release a product that doesn't enable an inherently insecure feature (because remember: we can't assume everyone properly configures their chrome extension, or that a chrome extension isn't malicious). If a user wants to expose their ollama service externally, they must make the conscious decision to enable external access to their service, which forces a thought process about security. Remember: exposing services to external clients always has inherent security risks. The cybersecurity field is massive, and well beyond the scope of this forum. Including things such as authentication, authorization, input sanitization, firewalls, etc. are all factors every server owner should think about before deploying any service that is exposed externally. Last, my own two cents so take it how you will: I don't think it's a big ask to have a developer set an environment variable to configure their service to allow things like browser extensions. It's also mentioned in their developers guide, which users should probably be reading if they intend on developing software to use with ollama.
GiteaMirror commented 2026-04-12 11:09:56 -05:00
Author
Owner
Copy Link

@christophrothmann commented on GitHub (Feb 2, 2024):

Hey,
I agree with @remy415 on this point.
Nevertheless, I would strongly recommend including this information in the documentation. I'm sure I'm not the first and last person to have problems with CORS.

<!-- gh-comment-id:1924517233 --> @christophrothmann commented on GitHub (Feb 2, 2024): Hey, I agree with @remy415 on this point. Nevertheless, I would **strongly** recommend including this information in the _**documentation**._ I'm sure I'm not the first and last person to have problems with CORS.
GiteaMirror commented 2026-04-12 11:09:56 -05:00
Author
Owner
Copy Link

@tomjorquera commented on GitHub (Feb 2, 2024):

Two clarifications on my message :

  • By "properly configured", I meant that the extension declares in its manifest that it needs to be allowed to make background requests to "localhost" (using host_permissions in V3, or permissions in V2).
  • My goal here is not for the users to use my ollama server, but for the users to be able to use my extension with their own local ollama instance. Meaning it's not just me that need to configure my service properly, but each user of my extension (or others').

So my question is in the context of allowing the user to use a browser extension to access ollama locally. It seems to me that, in the same way that I don't need any additional configuration on my ollama instance to interact with it using local clients (e.g. curl), I should be able to interact with it from an extension running locally in my browser.

I agree that it would definitively be weird for ollama to be configured by default to answer any requests from any origin 😄

EDIT:

And tbc, I'm not trying to be contrarian here or anything. I ask because I'm genuinely curious of understanding what would be the reason of disallowing that. So thanks for the replies folks 🙂

<!-- gh-comment-id:1924517518 --> @tomjorquera commented on GitHub (Feb 2, 2024): Two clarifications on my message : - By "properly configured", I meant that the extension declares in its manifest that it needs to be allowed to make background requests to "localhost" (using `host_permissions` in V3, or `permissions` in V2). - My goal here is not for the users to use *my* ollama server, but for the users to be able to use my extension *with their own* local ollama instance. Meaning it's not just me that need to configure my service properly, but each user of my extension (or others'). So my question is in the context of allowing the user to use a browser extension to access ollama *locally*. It seems to me that, in the same way that I don't need any additional configuration on my ollama instance to interact with it using local clients (e.g. curl), I should be able to interact with it from an extension running locally in my browser. I agree that it would definitively be weird for ollama to be configured by default to answer any requests from any origin :smile: EDIT: And tbc, I'm not trying to be contrarian here or anything. I ask because I'm genuinely curious of understanding what would be the reason of disallowing that. So thanks for the replies folks :slightly_smiling_face:
GiteaMirror commented 2026-04-12 11:09:57 -05:00
Author
Owner
Copy Link

@remy415 commented on GitHub (Feb 2, 2024):

By "properly configured", I meant that the extension declares in its manifest that it needs to be allowed to make background requests to "localhost" (using host_permissions in V3, or permissions in V2).

Keep in mind that ollama the service (ollama serve) and your extension that interacts with the API are two distinctly different things. By default, services usually come out the gate with minimal features enabled to keep things locked down. It's better to make a user enable services they need rather than make a user disable services they don't need because it's really easy for insecure options to be overlooked when setting up a new service. By forcing the user to enable them, it ensures things don't slip through the cracks. Imagine if you plugged in a new router on your home network, and it was configured to "allow any any"; you would have to then turn off the ports you don't want open rather than explicitly enabling the ports you do want open.

My goal here is not for the users to use my ollama server, but for the users to be able to use my extension with their own local ollama instance. Meaning it's not just me that need to configure my service properly, but each user of my extension (or others').

I would recommend adding in your extension's description that the extension requires a running ollama instance configured to allow CORS from Chrome, that the env variable would need to be set before starting the service, and then include a check in your code that if you get a 403 you can inform your users of the possibility that it's the CORS setting causing that error.

Conversely I would review the use-case of such an extension; essentially you are saying you're making an extension that only connects to a locally running instance of a 3rd party application that you have no control over. Maybe instead of an extension, you could create a locally running webpage (maybe via container) using ollama-js library, then make your extension interact with that as a plug-in to the webpage.

I did find something interesting in the cors library documentation:
Note: while Default() allows all origins, DefaultConfig() does not and you will still have to use AllowAllOrigins.

Also
Using all origins disables the ability for Gin to set cookies for clients. When dealing with credentials, don't allow all origins.

@DevChrisRoth Agreed, it should be in the documentation, and as I've said previously it is in the documentation. Maybe including a reference to the CORS library would be helpful?
https://github.com/ollama/ollama/blob/main/docs/faq.md -- Contains references to the env vars
https://github.com/ollama/ollama/blob/main/docs/development.md

Here's a repost of the documentation from the CORS library that ollama uses:
https://pkg.go.dev/github.com/gin-contrib/cors

<!-- gh-comment-id:1924572826 --> @remy415 commented on GitHub (Feb 2, 2024): > By "properly configured", I meant that the extension declares in its manifest that it needs to be allowed to make background requests to "localhost" (using host_permissions in V3, or permissions in V2). Keep in mind that ollama the service (ollama serve) and your extension that interacts with the API are two distinctly different things. By default, services usually come out the gate with minimal features enabled to keep things locked down. It's better to make a user enable services they need rather than make a user disable services they don't need because it's really easy for insecure options to be overlooked when setting up a new service. By forcing the user to enable them, it ensures things don't slip through the cracks. Imagine if you plugged in a new router on your home network, and it was configured to "allow any any"; you would have to then turn off the ports you don't want open rather than explicitly enabling the ports you do want open. > My goal here is not for the users to use my ollama server, but for the users to be able to use my extension with their own local ollama instance. Meaning it's not just me that need to configure my service properly, but each user of my extension (or others'). I would recommend adding in your extension's description that the extension requires a running ollama instance configured to allow CORS from Chrome, that the env variable would need to be set before starting the service, and then include a check in your code that if you get a 403 you can inform your users of the possibility that it's the CORS setting causing that error. Conversely I would review the use-case of such an extension; essentially you are saying you're making an extension that only connects to a locally running instance of a 3rd party application that you have no control over. Maybe instead of an extension, you could create a locally running webpage (maybe via container) using ollama-js library, then make your extension interact with that as a plug-in to the webpage. I did find something interesting in the cors library documentation: `Note: while Default() allows all origins, DefaultConfig() does not and you will still have to use AllowAllOrigins.` Also `Using all origins disables the ability for Gin to set cookies for clients. When dealing with credentials, don't allow all origins.` @DevChrisRoth Agreed, it should be in the documentation, and as I've said previously it is in the documentation. Maybe including a reference to the CORS library would be helpful? https://github.com/ollama/ollama/blob/main/docs/faq.md -- Contains references to the env vars https://github.com/ollama/ollama/blob/main/docs/development.md Here's a repost of the documentation from the CORS library that ollama uses: https://pkg.go.dev/github.com/gin-contrib/cors
GiteaMirror commented 2026-04-12 11:09:57 -05:00
Author
Owner
Copy Link

@tomjorquera commented on GitHub (Feb 2, 2024):

Keep in mind that ollama the service (ollama serve) and your extension that interacts with the API are two distinctly different things.

I understand that 🙂 And I understand the advantage of minimizing the attack surface by default. But here I'm struggling to get what security need is addressed by enforcing this additional verification layer on top of the one the browser is providing.

The server is only available locally by default, and needs an explicit setting (OLLAMA_HOST) to be set in order to be reachable from the network. Would there be any security risk adding moz-extension://* and chrome-extension://* to the list of allowed origins? At least in the default case where it's bound to localhost?

I would recommend adding in your extension's description that the extension requires a running ollama instance configured to allow CORS from Chrome

This is what I will do if the limitation stays. But I would really like to understand what is the actual security use case (if any) covered by this limitation, as I really don't get why allowing to call a local instance from a browser extension would be less safe than from any local client.

Conversely I would review the use-case of such an extension

The goal of my extension is to provide in-browser functionalities to the user, so that they can call a LLM directly on the content of the pages they are visiting. I want to allow the user to choose among multiple "providers", such as a local ollama instance, OpenAI API etc.
I have considered the solution of using a local application "proxy", but doing that just for supporting ollama seems a little too much (and it seems worse from a security PoV to ask the user to install not only a browser extension but also a full-blown-not-sandboxed application).

<!-- gh-comment-id:1924709686 --> @tomjorquera commented on GitHub (Feb 2, 2024): > Keep in mind that ollama the service (ollama serve) and your extension that interacts with the API are two distinctly different things. I understand that :slightly_smiling_face: And I understand the advantage of minimizing the attack surface by default. But here I'm struggling to get what security need is addressed by enforcing this additional verification layer on top of the one the browser is providing. The server is only available locally by default, and needs an explicit setting (`OLLAMA_HOST`) to be set in order to be reachable from the network. Would there be any security risk adding `moz-extension://*` and `chrome-extension://*` to the list of allowed origins? At least in the default case where it's bound to localhost? > I would recommend adding in your extension's description that the extension requires a running ollama instance configured to allow CORS from Chrome This is what I will do if the limitation stays. But I would really like to understand what is the actual security use case (if any) covered by this limitation, as I really don't get why allowing to call a local instance from a browser extension would be less safe than from any local client. > Conversely I would review the use-case of such an extension The goal of my extension is to provide in-browser functionalities to the user, so that they can call a LLM directly on the content of the pages they are visiting. I want to allow the user to choose among multiple "providers", such as a local ollama instance, OpenAI API etc. I have considered the solution of using a local application "proxy", but doing that just for supporting ollama seems a little too much (and it seems *worse* from a security PoV to ask the user to install not only a browser extension but also a full-blown-not-sandboxed application).
GiteaMirror commented 2026-04-12 11:09:57 -05:00
Author
Owner
Copy Link

@tomjorquera commented on GitHub (Feb 2, 2024):

Or maybe asked more succinctly: what is the use of enforcing a restricted set of origins when ollama is configured to be only accessible locally? 😄

<!-- gh-comment-id:1924718744 --> @tomjorquera commented on GitHub (Feb 2, 2024): Or maybe asked more succinctly: what is the use of enforcing a restricted set of origins when ollama is configured to be only accessible locally? :smile:
GiteaMirror commented 2026-04-12 11:09:58 -05:00
Author
Owner
Copy Link

@remy415 commented on GitHub (Feb 2, 2024):

Overall, it seems that ollama defaults do the package's config := cors.DefaultConfig() with http & https API calls being allowed.

image

Reference documentation:
https://pkg.go.dev/github.com/gin-contrib/cors#readme-using-defaultconfig-as-start-point

The server is only available locally by default, and needs an explicit setting (OLLAMA_HOST) to be set in order to be reachable from the network. Would there be any security risk adding moz-extension://* and chrome-extension://* to the list of allowed origins? At least in the default case where it's bound to localhost?

In your particular use case, none. But changing the default deployment configuration of the application means that every user who downloads and installs ollama will be running with that default configuration. Probably better to leave it at "cors.DefaultConfig()". Again, I'm not an expert on Go or CORS, I'm just saying that in general it's better to have restrictive defaults than loose defaults.

And just because the default is to disable chrome extensions, doesn't mean you couldn't inform your users that if they're using ollama they would need to set that env variable and restart the service to allow your extension to connect. If you do this, don't forget to inform them that if they intend on making their ollama accessible from external sources they should research and implement proper security for their use-case.

<!-- gh-comment-id:1924734390 --> @remy415 commented on GitHub (Feb 2, 2024): Overall, it seems that ollama defaults do the package's `config := cors.DefaultConfig()` with http & https API calls being allowed. ![image](https://github.com/ollama/ollama/assets/105550370/10461497-6298-49ee-9cac-ab96aeedaa72) Reference documentation: https://pkg.go.dev/github.com/gin-contrib/cors#readme-using-defaultconfig-as-start-point > The server is only available locally by default, and needs an explicit setting (OLLAMA_HOST) to be set in order to be reachable from the network. Would there be any security risk adding moz-extension://* and chrome-extension://* to the list of allowed origins? At least in the default case where it's bound to localhost? In your particular use case, none. But changing the default deployment configuration of the application means that every user who downloads and installs ollama will be running with that default configuration. Probably better to leave it at "cors.DefaultConfig()". Again, I'm not an expert on Go or CORS, I'm just saying that in general it's better to have restrictive defaults than loose defaults. And just because the default is to disable chrome extensions, doesn't mean you couldn't inform your users that if they're using ollama they would need to set that env variable and restart the service to allow your extension to connect. If you do this, don't forget to inform them that if they intend on making their ollama accessible from external sources they should research and implement proper security for their use-case.
GiteaMirror commented 2026-04-12 11:09:59 -05:00
Author
Owner
Copy Link

@tomjorquera commented on GitHub (Feb 2, 2024):

Ok so from the discussing I gather that it's ultimately a choice for the ollama team whether to restrict origins when ollama is only accessible locally or not. I would be interested to have the word from the devs on that, but given the length of the (closed) ticket they may have moved on already 😄

Maybe I will create a specific issue to discuss this proposal later on. In the meantime I will document the workaround.

Thanks for the chat @remy415

<!-- gh-comment-id:1924877458 --> @tomjorquera commented on GitHub (Feb 2, 2024): Ok so from the discussing I gather that it's ultimately a choice for the ollama team whether to restrict origins when ollama is only accessible locally or not. I would be interested to have the word from the devs on that, but given the length of the (closed) ticket they may have moved on already :smile: Maybe I will create a specific issue to discuss this proposal later on. In the meantime I will document the workaround. Thanks for the chat @remy415
GiteaMirror commented 2026-04-12 11:09:59 -05:00
Author
Owner
Copy Link

@remy415 commented on GitHub (Feb 2, 2024):

In the mean time, you could update your extension to say something like
“If you want to use this locally with ollama you can, but you have to update your command to say “OLLAMA_ORIGINS=chrome://* ollama serve”. Note that this will allow any chrome extension to connect and may have security implications if the ollama API is exposed to external clients”

I also recommend researching Zero Trust principles if you’re interested in developing security-conscious architectures, with the key principle is that you don’t implicitly trust anyone or anything, but rather explicitly trust things as you implement proper security mechanisms.

<!-- gh-comment-id:1924892255 --> @remy415 commented on GitHub (Feb 2, 2024): In the mean time, you could update your extension to say something like “If you want to use this locally with ollama you can, but you have to update your command to say “OLLAMA_ORIGINS=chrome://* ollama serve”. Note that this will allow any chrome extension to connect and may have security implications if the ollama API is exposed to external clients” I also recommend researching Zero Trust principles if you’re interested in developing security-conscious architectures, with the key principle is that you don’t implicitly trust anyone or anything, but rather explicitly trust things as you implement proper security mechanisms.
GiteaMirror commented 2026-04-12 11:10:00 -05:00
Author
Owner
Copy Link

@samheutmaker commented on GitHub (Feb 3, 2024):

+1 on allowing chrome extensions in default CORS settings.

<!-- gh-comment-id:1925237750 --> @samheutmaker commented on GitHub (Feb 3, 2024): +1 on allowing chrome extensions in default CORS settings.
GiteaMirror commented 2026-04-12 11:10:00 -05:00
Author
Owner
Copy Link

@krngd2 commented on GitHub (Jun 22, 2024):

Hello everyone,
Its still not working for me 😢

image

I tried allowing "chrome-extension://MY_EXTENSION_ID"
Also this "chrome-extension://*"
also this "0.0.0.0"
restarted Ollama everytime, did not work

image

1st request is from PostMan works good,
2nd and 3rd requests from Chrom Extention, get tags works but not generate "POST"

<!-- gh-comment-id:2184161157 --> @krngd2 commented on GitHub (Jun 22, 2024): Hello everyone, Its still not working for me 😢 <img width="402" alt="image" src="https://github.com/ollama/ollama/assets/10483437/5771dc04-6f38-414d-bb93-d8900b96c555"> I tried allowing "chrome-extension://MY_EXTENSION_ID" Also this "chrome-extension://*" also this "0.0.0.0" restarted Ollama everytime, did not work <img width="684" alt="image" src="https://github.com/ollama/ollama/assets/10483437/0ad456ff-593e-4f53-a795-39efd64ad03d"> 1st request is from PostMan works good, 2nd and 3rd requests from Chrom Extention, get tags works but not generate "POST"
GiteaMirror commented 2026-04-12 11:10:01 -05:00
Author
Owner
Copy Link

@christophrothmann commented on GitHub (Jun 25, 2024):

@krngd2 ,
did you try to start the ollama server like mentioned here?

<!-- gh-comment-id:2189483365 --> @christophrothmann commented on GitHub (Jun 25, 2024): @krngd2 , did you try to start the ollama server like mentioned [here](https://github.com/ollama/ollama/issues/2308#issuecomment-1923630384)?
GiteaMirror commented 2026-04-12 11:10:01 -05:00
Author
Owner
Copy Link

@krngd2 commented on GitHub (Jun 26, 2024):

@krngd2 , did you try to start the ollama server like mentioned here?

That actually worked, I forgot to update the thread. Thanks a lot

<!-- gh-comment-id:2191108407 --> @krngd2 commented on GitHub (Jun 26, 2024): > @krngd2 , did you try to start the ollama server like mentioned [here](https://github.com/ollama/ollama/issues/2308#issuecomment-1923630384)? That actually worked, I forgot to update the thread. Thanks a lot
GiteaMirror commented 2026-04-12 11:10:01 -05:00
Author
Owner
Copy Link

@nikleonard commented on GitHub (Jun 26, 2024):

It appears that Windows Ollama is ignoring the ollama_origins=chrome-extension//* env variable, but not always. I'm using ollama windows ver. 0.1.46, and ollama-ui chrome extension (chrome-extension://cmgdpmlhgjhoadnonobjeekmfcehffco). If I load localhost and switch to the remote server ip, it actually loads the model list, but any inference call is responded with a 403. If I reload the page, the /api/tags endpoint also returns 403. My server.log file looks like this:

2024/06/26 17:52:07 routes.go:1064: INFO server config env="map[CUDA_VISIBLE_DEVICES: GPU_DEVICE_ORDINAL: HIP_VISIBLE_DEVICES: HSA_OVERRIDE_GFX_VERSION: OLLAMA_DEBUG:false OLLAMA_FLASH_ATTENTION:false OLLAMA_HOST:http://0.0.0.0:11434 OLLAMA_INTEL_GPU:false OLLAMA_KEEP_ALIVE: OLLAMA_LLM_LIBRARY: OLLAMA_MAX_LOADED_MODELS:1 OLLAMA_MAX_QUEUE:512 OLLAMA_MAX_VRAM:0 OLLAMA_MODELS:C:\\Users\\****\\.ollama\\models OLLAMA_NOHISTORY:false OLLAMA_NOPRUNE:false OLLAMA_NUM_PARALLEL:1 OLLAMA_ORIGINS:[chrome-extension://* http://localhost https://localhost http://localhost:* https://localhost:* http://127.0.0.1 https://127.0.0.1 http://127.0.0.1:* https://127.0.0.1:* http://0.0.0.0 https://0.0.0.0 http://0.0.0.0:* https://0.0.0.0:* app://* file://* tauri://*] OLLAMA_RUNNERS_DIR:C:\\Users\\****\\AppData\\Local\\Programs\\Ollama\\ollama_runners OLLAMA_SCHED_SPREAD:false OLLAMA_TMPDIR: ROCR_VISIBLE_DEVICES:]"
time=2024-06-26T17:52:07.097-04:00 level=INFO source=images.go:730 msg="total blobs: 34"
time=2024-06-26T17:52:07.098-04:00 level=INFO source=images.go:737 msg="total unused blobs removed: 0"
time=2024-06-26T17:52:07.100-04:00 level=INFO source=routes.go:1111 msg="Listening on [::]:11434 (version 0.1.46)"
time=2024-06-26T17:52:07.101-04:00 level=INFO source=payload.go:44 msg="Dynamic LLM libraries [cpu_avx2 cuda_v11.3 rocm_v5.7 cpu cpu_avx]"
time=2024-06-26T17:52:07.213-04:00 level=INFO source=types.go:98 msg="inference compute" id=GPU-(GUID) library=cuda compute=8.6 driver=12.5 name="NVIDIA GeForce RTX 3060" total="12.0 GiB" available="11.0 GiB"
[GIN] 2024/06/26 - 17:52:32 | 403 |            0s |    192.168.1.93 | GET      "/api/tags" <-first attempt
[GIN] 2024/06/26 - 17:52:48 | 200 |      3.5745ms |    192.168.1.93 | GET      "/api/tags" <-second attempt, it actually reads
[GIN] 2024/06/26 - 17:53:01 | 403 |            0s |    192.168.1.93 | POST     "/api/generate" <-fails on generate
[GIN] 2024/06/26 - 17:53:41 | 200 |      4.0133ms |    192.168.1.93 | GET      "/api/tags" <- changed to localhost, returns and loads
[GIN] 2024/06/26 - 17:53:52 | 403 |            0s |    192.168.1.93 | POST     "/api/generate" <- fails anyways
<!-- gh-comment-id:2192695609 --> @nikleonard commented on GitHub (Jun 26, 2024): It appears that Windows Ollama is ignoring the ollama_origins=chrome-extension//* env variable, but not always. I'm using ollama windows ver. 0.1.46, and ollama-ui chrome extension (chrome-extension://cmgdpmlhgjhoadnonobjeekmfcehffco). If I load localhost and switch to the remote server ip, it actually loads the model list, but any inference call is responded with a 403. If I reload the page, the /api/tags endpoint also returns 403. My server.log file looks like this: ``` 2024/06/26 17:52:07 routes.go:1064: INFO server config env="map[CUDA_VISIBLE_DEVICES: GPU_DEVICE_ORDINAL: HIP_VISIBLE_DEVICES: HSA_OVERRIDE_GFX_VERSION: OLLAMA_DEBUG:false OLLAMA_FLASH_ATTENTION:false OLLAMA_HOST:http://0.0.0.0:11434 OLLAMA_INTEL_GPU:false OLLAMA_KEEP_ALIVE: OLLAMA_LLM_LIBRARY: OLLAMA_MAX_LOADED_MODELS:1 OLLAMA_MAX_QUEUE:512 OLLAMA_MAX_VRAM:0 OLLAMA_MODELS:C:\\Users\\****\\.ollama\\models OLLAMA_NOHISTORY:false OLLAMA_NOPRUNE:false OLLAMA_NUM_PARALLEL:1 OLLAMA_ORIGINS:[chrome-extension://* http://localhost https://localhost http://localhost:* https://localhost:* http://127.0.0.1 https://127.0.0.1 http://127.0.0.1:* https://127.0.0.1:* http://0.0.0.0 https://0.0.0.0 http://0.0.0.0:* https://0.0.0.0:* app://* file://* tauri://*] OLLAMA_RUNNERS_DIR:C:\\Users\\****\\AppData\\Local\\Programs\\Ollama\\ollama_runners OLLAMA_SCHED_SPREAD:false OLLAMA_TMPDIR: ROCR_VISIBLE_DEVICES:]" time=2024-06-26T17:52:07.097-04:00 level=INFO source=images.go:730 msg="total blobs: 34" time=2024-06-26T17:52:07.098-04:00 level=INFO source=images.go:737 msg="total unused blobs removed: 0" time=2024-06-26T17:52:07.100-04:00 level=INFO source=routes.go:1111 msg="Listening on [::]:11434 (version 0.1.46)" time=2024-06-26T17:52:07.101-04:00 level=INFO source=payload.go:44 msg="Dynamic LLM libraries [cpu_avx2 cuda_v11.3 rocm_v5.7 cpu cpu_avx]" time=2024-06-26T17:52:07.213-04:00 level=INFO source=types.go:98 msg="inference compute" id=GPU-(GUID) library=cuda compute=8.6 driver=12.5 name="NVIDIA GeForce RTX 3060" total="12.0 GiB" available="11.0 GiB" [GIN] 2024/06/26 - 17:52:32 | 403 | 0s | 192.168.1.93 | GET "/api/tags" <-first attempt [GIN] 2024/06/26 - 17:52:48 | 200 | 3.5745ms | 192.168.1.93 | GET "/api/tags" <-second attempt, it actually reads [GIN] 2024/06/26 - 17:53:01 | 403 | 0s | 192.168.1.93 | POST "/api/generate" <-fails on generate [GIN] 2024/06/26 - 17:53:41 | 200 | 4.0133ms | 192.168.1.93 | GET "/api/tags" <- changed to localhost, returns and loads [GIN] 2024/06/26 - 17:53:52 | 403 | 0s | 192.168.1.93 | POST "/api/generate" <- fails anyways ```
GiteaMirror commented 2026-04-12 11:10:02 -05:00
Author
Owner
Copy Link

@Archemike commented on GitHub (Oct 20, 2024):

on windows with the .exe installer i did this and was a more permanent solution.

$env:OLLAMA_ORIGINS="chrome-extension://*"

then

[System.Environment]::SetEnvironmentVariable('OLLAMA_ORIGINS', 'chrome-extension://*', [System.EnvironmentVariableTarget]::User)

then

ollama serve

and my chrome extension is now getting 200 and responses. Only issue is how can users of chrome extension do all this as majority won't be able to figure this out, I hope this gets fixed.

<!-- gh-comment-id:2424765853 --> @Archemike commented on GitHub (Oct 20, 2024): on windows with the .exe installer i did this and was a more permanent solution. $env:OLLAMA_ORIGINS="chrome-extension://*" then [System.Environment]::SetEnvironmentVariable('OLLAMA_ORIGINS', 'chrome-extension://*', [System.EnvironmentVariableTarget]::User) then ollama serve and my chrome extension is now getting 200 and responses. Only issue is how can users of chrome extension do all this as majority won't be able to figure this out, I hope this gets fixed.
GiteaMirror commented 2026-04-12 11:10:02 -05:00
Author
Owner
Copy Link

@sulimu2 commented on GitHub (May 30, 2025):

Hell yeah, I finally figured it out. I looked into the server.log file from Ollama ~/.ollama/logs/server.log and there was a useful error message. Bildschirmfoto 2024-02-02 um 12 35 11

The solution was to start the Ollama Service in the terminal with following command: OLLAMA_ORIGINS=chrome-extension://* ollama serve

Thanks for your help guys! @mxyng , @remy415 , @tomjorquera

Thanks!!!! it's helpful for me

<!-- gh-comment-id:2921399859 --> @sulimu2 commented on GitHub (May 30, 2025): > Hell yeah, I finally figured it out. I looked into the server.log file from Ollama `~/.ollama/logs/server.log` and there was a useful error message. ![Bildschirmfoto 2024-02-02 um 12 35 11](https://github.com/ollama/ollama/assets/58110317/86deb19e-5cf2-4a18-a1fc-004fbbf363b8) > > The solution was to start the Ollama Service in the terminal with following command: `OLLAMA_ORIGINS=chrome-extension://* ollama serve` > > Thanks for your help guys! [@mxyng](https://github.com/mxyng) , [@remy415](https://github.com/remy415) , [@tomjorquera](https://github.com/tomjorquera) Thanks!!!! it's helpful for me
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#1331
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?