Summary

Ollama currently supports custom origins via OLLAMA_ORIGINS, including browser extension origins like chrome-extension://*. However, this approach is too coarse and lacks a first-class onboarding flow for browser extensions.

This makes it difficult to build secure, local-first integrations (e.g., Chrome extensions) without relying on fragile workarounds. I am currently building a browser extension which uses Ollama for filling out Forms online. i.e job applications . This is disrupting the onboarding experience as they have to run a command in the terminal to allow chrome explicitly which is a pain for non technical users and its turning them away.

https://apply.offlyn.ai

Problem

Browser extensions cannot reliably POST to Ollama due to strict Origin validation:

Origin: chrome-extension://<extension-id>

Unless users manually configure OLLAMA_ORIGINS, requests are rejected.

Current limitations

• No first-class support for browser extensions
• Coarse control (e.g., chrome-extension://* allows all extensions)
• No user-facing approval/onboarding flow
• No way to list/revoke allowed extensions
• Forces workaround patterns (hidden tabs, injected scripts)

Real-world impact

To make extensions work today, developers must:

• Create a hidden tab at http://localhost:11434
• Inject a script and call fetch() from that page context

This workaround:

• Adds complexity
• Breaks streaming (must use stream: false)
• Introduces lifecycle/race issues
• Feels like a hack rather than a supported path

Proposal

Introduce a first-class trusted browser extension model with explicit onboarding and per-extension allowlisting.

1) Extension ID–based allowlist

Allow explicit configuration of trusted extensions:

OLLAMA_ORIGINS=chrome-extension://abc123...

Encourage specific extension IDs instead of wildcards like chrome-extension://*.

2) Interactive onboarding (recommended)

When an unknown extension attempts access, prompt the user:

A browser extension is requesting access to Ollama:

Origin: chrome-extension://abc123... Requested endpoints: /api/generate, /api/embeddings

Allow? [ ] Allow once [ ] Always allow [ ] Deny

Benefits:

• Explicit user consent
• Visibility into who is accessing Ollama
• Aligns with browser/OS permission models

3) Persistent trusted extension registry

Store approved extensions locally (file or config):

{ "trusted_extensions": [ { "origin": "chrome-extension://abc123...", "permissions": ["generate", "embeddings"], "added_at": "2026-04-18T00:00:00Z" } ] }

4) Management commands

Examples:

ollama extensions list ollama extensions allow chrome-extension://abc123... ollama extensions revoke chrome-extension://abc123...

Optional: lightweight local UI

5) (Optional) Permission scoping

Per-extension scopes:

• generate (chat/completions)
• embeddings
• pull (model downloads)
• list (model listing)

Why this matters

• Enables local-first browser extension ecosystem
• Safer than allowing all extensions
• Eliminates hidden-tab/injection workarounds
• Restores full API functionality (including streaming)
• Improves developer experience

Backward compatibility

• Existing OLLAMA_ORIGINS behavior remains unchanged
• New functionality is additive and opt-in

Alternative considered

Hidden tab + injected script proxy:

• Works today but is complex, fragile, and breaks streaming
• Not suitable as a long-term solution

Ask

Would you be open to supporting a first-class trusted extension flow (ID-based allowlist + optional onboarding prompt)?

Happy to contribute implementation if aligned.