[GH-ISSUE #23970] issue: Automations silently lose web_search / tools available in normal chat #35664

New Issue

GiteaMirror · 2026-04-25T09:51:04-05:00

GiteaMirror commented

2026-04-25 09:51:04 -05:00

Originally created by @belugaming on GitHub (Apr 22, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/23970

Check Existing Issues

I have searched for any existing and/or related issues.
I have searched for any existing and/or related discussions.
I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (closest is #23851 about OAuth token forwarding in scheduled tasks, and #23943 about the create_automation builtin tool — neither covers this).
I am using the latest version of Open WebUI.

Installation Method

Git Clone

Open WebUI Version

v0.9.1

Ollama Version (if applicable)

No response

Operating System

macOS Sonoma

Browser (if applicable)

No response

Confirmation

I have read and followed all instructions in README.md.
I am using the latest version of both Open WebUI and Ollama.
I have included the browser console logs.
I have included the Docker container logs.
I have provided every relevant configuration, setting, and environment variable used in my setup.
I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup.
I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation.

Expected Behavior

When an automation triggers, the model should have access to the same builtin tools (web_search, image_generation, code_interpreter, …) it has when the user talks to it from the chat UI. In particular:

Toggling "Web Search" in the chat input bar enables it for that chat.
Setting webSearch: 'always' in user settings enables it for every chat.
Either of the above should also apply when the same model is invoked from an automation.

Actual Behavior

When the same model is invoked from an automation, it has no web access (and no image generation, no MCP/tool toggling) unless the user has gone to Workspace → Models → <edit model> → Capabilities → Default Features and explicitly checked Web Search, then saved.

This is non-obvious and asymmetric with normal chat:

Path	web_search enabled?
Chat, user clicks the "Web Search" button	✅
Chat, `settings.ui.webSearch === 'always'`	✅
Chat, no toggle, no setting, no `defaultFeatureIds`	❌
Automation, no `defaultFeatureIds` on model	❌
Automation, `defaultFeatureIds: ['web_search']` on model	✅

So users who never customise defaultFeatureIds (the vast majority) will see "automations work but the model can't browse / use tools".

The same gap exists for image_generation, and there is no per-automation way to attach tool_ids / MCP servers either — the AutomationEditor UI only exposes name / prompt / model / schedule.

Steps to Reproduce

Fresh install of Open WebUI v0.9.1, log in as admin.
Admin Settings → Web Search → enable, configure any provider (e.g. DuckDuckGo / Tavily) and confirm it works.
Workspace → Models → create a custom model on top of any chat model (e.g. gpt-4o-mini). Do not touch "Default Features" in the editor. Save.
Open a new chat with that model, click the "Web Search" button in the input bar, ask: What is the weather in Tokyo right now? → model browses and returns live weather. ✅
Go to /automations, create an automation:
- Name: weather test
- Model: the custom model from step 3
- Prompt: What is the weather in Tokyo right now?
- Schedule: "Every 5 minutes" (or click "Run now")
Open the chat the automation generated (from Execution Logs → success entry).
Observe: no Searching the web… status appears, the model answers from training data or refuses with "I cannot access real-time data". ❌

Now go back to step 3, edit the model, scroll to Capabilities → Default Features, tick Web Search, Save. Trigger the automation again → web search works. This proves the only thing missing is that meta.defaultFeatureIds does not contain web_search.

Logs & Screenshots

No errors are emitted — the failure is silent. The automation run is recorded as success in automation_run, the chat is created, the model just doesn't get the tool injected.

Backend log shows nothing about web search being attempted.

Additional Information

Root cause

backend/open_webui/utils/automations.py::_resolve_model_features only considers the model's meta.defaultFeatureIds:

def _resolve_model_features(app, model_id: str) -> dict:
    ...
    default_feature_ids = meta.get('defaultFeatureIds', [])
    if not default_feature_ids:
        return {}
    ...
    for feature_id in default_feature_ids:
        if feature_id in feature_checks:
            if capabilities.get(feature_id) and feature_checks[feature_id]:
                features[feature_id] = True
    return features

It does not consult:

the user's settings.ui.webSearch === 'always' / imageGeneration === 'always'
any per-automation feature/tool selection — the AutomationEditor UI does not expose one, and AutomationData (in backend/open_webui/models/automations.py) only stores prompt, model_id, rrule, terminal.

Downstream, get_builtin_tools in backend/open_webui/utils/tools.py (lines 485–493) gates search_web / fetch_url on features.get('web_search'), so the tool is silently absent from the native function-calling spec.

For comparison, the chat path (src/lib/components/chat/Chat.svelte::getFeatures(), ~line 2094) builds features from any of: model defaults, the input-bar toggle, and the user's settings.ui.webSearch === 'always'.

Suggested Fix

Two layered changes:

Per-automation feature/tool toggles in the AutomationEditor UI. Add features: dict and tool_ids: list[str] fields to AutomationData, and expose toggles in src/lib/components/automations/AutomationEditor.svelte mirroring the chat input bar (Web Search / Image Gen / MCP servers / Tools). This is the proper fix and matches the user's mental model — "an automation is a saved chat".
Fallback to user defaults. In _resolve_model_features, also enable web_search / image_generation when the user's settings.ui.{webSearch,imageGeneration} === 'always' and the global config + capability + permission allow it. This restores parity with normal chats for users who set the global "always" preference, without requiring the new UI.

Happy to send a PR for either or both if maintainers agree on the direction.

Originally created by @belugaming on GitHub (Apr 22, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/23970 ### Check Existing Issues - [x] I have searched for any existing and/or related issues. - [x] I have searched for any existing and/or related discussions. - [x] I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (closest is #23851 about OAuth token forwarding in scheduled tasks, and #23943 about the `create_automation` builtin tool — neither covers this). - [x] I am using the latest version of Open WebUI. ### Installation Method Git Clone ### Open WebUI Version v0.9.1 ### Ollama Version (if applicable) _No response_ ### Operating System macOS Sonoma ### Browser (if applicable) _No response_ ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup**. - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. ### Expected Behavior When an automation triggers, the model should have access to the same builtin tools (`web_search`, `image_generation`, `code_interpreter`, …) it has when the user talks to it from the chat UI. In particular: - Toggling "Web Search" in the chat input bar enables it for that chat. - Setting `webSearch: 'always'` in user settings enables it for every chat. - Either of the above should also apply when the same model is invoked from an automation. ### Actual Behavior When the same model is invoked from an automation, it has **no web access** (and no image generation, no MCP/tool toggling) unless the user has gone to `Workspace → Models → <edit model> → Capabilities → Default Features` and explicitly checked `Web Search`, then saved. This is non-obvious and asymmetric with normal chat: | Path | web_search enabled? | |---|---| | Chat, user clicks the "Web Search" button | ✅ | | Chat, `settings.ui.webSearch === 'always'` | ✅ | | Chat, no toggle, no setting, no `defaultFeatureIds` | ❌ | | Automation, no `defaultFeatureIds` on model | ❌ | | Automation, `defaultFeatureIds: ['web_search']` on model | ✅ | So users who never customise `defaultFeatureIds` (the vast majority) will see "automations work but the model can't browse / use tools". The same gap exists for `image_generation`, and there is no per-automation way to attach `tool_ids` / MCP servers either — the AutomationEditor UI only exposes `name` / `prompt` / `model` / `schedule`. ### Steps to Reproduce 1. Fresh install of Open WebUI v0.9.1, log in as admin. 2. `Admin Settings → Web Search` → enable, configure any provider (e.g. DuckDuckGo / Tavily) and confirm it works. 3. `Workspace → Models` → create a custom model on top of any chat model (e.g. `gpt-4o-mini`). Do **not** touch "Default Features" in the editor. Save. 4. Open a new chat with that model, click the "Web Search" button in the input bar, ask: `What is the weather in Tokyo right now?` → model browses and returns live weather. ✅ 5. Go to `/automations`, create an automation: - Name: `weather test` - Model: the custom model from step 3 - Prompt: `What is the weather in Tokyo right now?` - Schedule: "Every 5 minutes" (or click "Run now") 6. Open the chat the automation generated (from `Execution Logs` → success entry). 7. **Observe**: no `Searching the web…` status appears, the model answers from training data or refuses with "I cannot access real-time data". ❌ Now go back to step 3, edit the model, scroll to `Capabilities → Default Features`, tick `Web Search`, Save. Trigger the automation again → web search works. This proves the only thing missing is that `meta.defaultFeatureIds` does not contain `web_search`. ### Logs & Screenshots No errors are emitted — the failure is silent. The automation run is recorded as `success` in `automation_run`, the chat is created, the model just doesn't get the tool injected. Backend log shows nothing about web search being attempted. ### Additional Information #### Root cause `backend/open_webui/utils/automations.py::_resolve_model_features` only considers the model's `meta.defaultFeatureIds`: ```python def _resolve_model_features(app, model_id: str) -> dict: ... default_feature_ids = meta.get('defaultFeatureIds', []) if not default_feature_ids: return {} ... for feature_id in default_feature_ids: if feature_id in feature_checks: if capabilities.get(feature_id) and feature_checks[feature_id]: features[feature_id] = True return features ``` It does **not** consult: - the user's `settings.ui.webSearch === 'always'` / `imageGeneration === 'always'` - any per-automation feature/tool selection — the AutomationEditor UI does not expose one, and `AutomationData` (in `backend/open_webui/models/automations.py`) only stores `prompt`, `model_id`, `rrule`, `terminal`. Downstream, `get_builtin_tools` in `backend/open_webui/utils/tools.py` (lines 485–493) gates `search_web` / `fetch_url` on `features.get('web_search')`, so the tool is silently absent from the native function-calling spec. For comparison, the chat path (`src/lib/components/chat/Chat.svelte::getFeatures()`, ~line 2094) builds `features` from any of: model defaults, the input-bar toggle, **and** the user's `settings.ui.webSearch === 'always'`. #### Suggested Fix Two layered changes: 1. **Per-automation feature/tool toggles in the AutomationEditor UI.** Add `features: dict` and `tool_ids: list[str]` fields to `AutomationData`, and expose toggles in `src/lib/components/automations/AutomationEditor.svelte` mirroring the chat input bar (Web Search / Image Gen / MCP servers / Tools). This is the proper fix and matches the user's mental model — "an automation is a saved chat". 2. **Fallback to user defaults.** In `_resolve_model_features`, also enable `web_search` / `image_generation` when the user's `settings.ui.{webSearch,imageGeneration} === 'always'` and the global config + capability + permission allow it. This restores parity with normal chats for users who set the global "always" preference, without requiring the new UI. Happy to send a PR for either or both if maintainers agree on the direction.

GiteaMirror closed this issue

2026-04-25 09:51:04 -05:00

GiteaMirror commented

2026-04-25 09:51:05 -05:00

@tjbck commented on GitHub (Apr 24, 2026):

Intended behaviour, defaultFeatureIds should be explicitly configured.

@tjbck commented on GitHub (Apr 24, 2026): Intended behaviour, defaultFeatureIds should be explicitly configured.

GiteaMirror commented

2026-04-25 09:51:07 -05:00

@belugaming commented on GitHub (Apr 24, 2026):

Intended behaviour, defaultFeatureIds should be explicitly configured.

So what if I use the Internet search tool in the automated task? I'm very sorry that I didn't understand what you meant.

@belugaming commented on GitHub (Apr 24, 2026): > Intended behaviour, defaultFeatureIds should be explicitly configured. So what if I use the Internet search tool in the automated task? I'm very sorry that I didn't understand what you meant.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#35664