github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-05-06 10:58:17 -05:00
Code Issues 1.3k Packages Projects Releases 126 Wiki Activity

[GH-ISSUE #22851] issue: Generation stops after integrated tool call for non-admin users #35356

New Issue
Closed
opened 2026-04-25 09:34:36 -05:00 by GiteaMirror · 4 comments
GiteaMirror commented 2026-04-25 09:34:36 -05:00
Owner
Copy Link

Originally created by @moritzderallerechte on GitHub (Mar 19, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/22851

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 (your issue might already be addressed on the development branch!).
  • I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.8.10

Ollama Version (if applicable)

No response

Operating System

Ubuntu 24.04.4 LTS

Browser (if applicable)

Chrome 146.0.7680.72

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 (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
  • I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
  • Start with the initial platform/version/OS and dependencies used,
  • Specify exact install/launch/configure commands,
  • List URLs visited, user input (incl. example values/emails/passwords if needed),
  • Describe all options and toggles enabled or changed,
  • Include any files or environmental changes,
  • Identify the expected and actual result at each stage,
  • Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

When having models call integrated tools, OpenWebUI should do a follow up call to the model, including the results of the tool call.

Actual Behavior

When using an admin account, this works as expected (generation continues).
However with normal user accounts, the generation just stops.
The results of the tool call is correctly shown in the UI, but there is no subsequent request.

Steps to Reproduce

  1. Enable native tool calling
  2. Ask a model to call list_knowledge_bases
  3. See if the model responds after the tool call

Logs & Screenshots

user log:

2026-03-19 09:43:27.804 | INFO | function_openrouter_kosten:pipe:142 - pipe:function_openrouter
2026-03-19 09:43:27.804 | INFO | function_openrouter_kosten:pipe:143 - task: None
2026-03-19 09:43:28.466 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 10.10.14.70:50944 - "POST /api/chat/completions HTTP/1.1" 200
2026-03-19 09:43:28.581 | INFO | function_openrouter_kosten:pipe:142 - pipe:function_openrouter
2026-03-19 09:43:28.581 | INFO | function_openrouter_kosten:pipe:143 - task: title_generation
2026-03-19 09:43:28.645 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 10.10.14.70:55705 - "POST /api/chat/completed HTTP/1.1" 200

admin log:

2026-03-19 09:41:50.748 | INFO | function_openrouter_kosten:pipe:142 - pipe:function_openrouter
2026-03-19 09:41:50.748 | INFO | function_openrouter_kosten:pipe:143 - task: None
2026-03-19 09:41:52.097 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 10.10.14.70:59453 - "POST /api/chat/completions HTTP/1.1" 200
2026-03-19 09:41:52.360 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 10.10.14.70:59453 - "GET /api/v1/chats/?page=1 HTTP/1.1" 200
2026-03-19 09:41:52.382 | INFO | function_openrouter_kosten:pipe:142 - pipe:function_openrouter
2026-03-19 09:41:52.382 | INFO | function_openrouter_kosten:pipe:143 - task: None
2026-03-19 09:41:54.987 | INFO | function_openrouter_kosten:pipe:142 - pipe:function_openrouter
2026-03-19 09:41:54.987 | INFO | function_openrouter_kosten:pipe:143 - task: title_generation
2026-03-19 09:41:55.814 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 10.10.14.70:59453 - "POST /api/chat/completed HTTP/1.1" 200

Additional Information

I am using a manifold pipe to connect to OpenRouter, however the issue most definitely does not lay there.
The pipe does not do any permission checking or discriminate in any way between users. In fact, no information about the users is ever used for requests.
The request generated by the pipe looks exactly the same for every user. I tested with the following example:

{
    'stream': True,
    'model': 'qwen/qwen3.5-35b-a3b',
    'messages': [{
        'role': 'user',
        'content': [{
            'type': 'text',
            'text': 'Ruf die Funktion list_knowledge_bases auf und sag mir danach, was der Inhalt der Rückgabe ist.'
        }]
    }],
    'tools': [{
        'type': 'function',
        'function': {
            'name': 'list_knowledge_bases',
            'description': "List the user's accessible knowledge bases.",
            'parameters': {
                'properties': {
                    'count': {
                        'default': 10,
                        'description': 'Maximum number of KBs to return (default: 10)',
                        'type': 'integer'
                    },
                    'skip': {
                        'default': 0,
                        'description': 'Number of results to skip for pagination (default: 0)',
                        'type': 'integer'
                    }
                },
                'type': 'object'
            }
        }
    }, {
        'type': 'function',
        'function': {
            'name': 'search_knowledge_bases',
            'description': "Search the user's accessible knowledge bases by name and description.",
            'parameters': {
                'properties': {
                    'query': {
                        'description': 'The search query to find matching knowledge bases',
                        'type': 'string'
                    },
                    'count': {
                        'default': 5,
                        'description': 'Maximum number of results to return (default: 5)',
                        'type': 'integer'
                    },
                    'skip': {
                        'default': 0,
                        'description': 'Number of results to skip for pagination (default: 0)',
                        'type': 'integer'
                    }
                },
                'required': ['query'],
                'type': 'object'
            }
        }
    }, {
        'type': 'function',
        'function': {
            'name': 'query_knowledge_bases',
            'description': 'Search knowledge bases by semantic similarity to query.\nFinds KBs whose name/description match the meaning of your query.\nUse this to discover relevant knowledge bases before querying their files.',
            'parameters': {
                'properties': {
                    'query': {
                        'description': "Natural language query describing what you're looking for",
                        'type': 'string'
                    },
                    'count': {
                        'default': 5,
                        'description': 'Maximum results (default: 5)',
                        'type': 'integer'
                    }
                },
                'required': ['query'],
                'type': 'object'
            }
        }
    }, {
        'type': 'function',
        'function': {
            'name': 'search_knowledge_files',
            'description': 'Search files across knowledge bases the user has access to.',
            'parameters': {
                'properties': {
                    'query': {
                        'description': 'The search query to find matching files by filename',
                        'type': 'string'
                    },
                    'knowledge_id': {
                        'description': 'Optional KB id to limit search to a specific knowledge base',
                        'type': 'string'
                    },
                    'count': {
                        'default': 5,
                        'description': 'Maximum number of results to return (default: 5)',
                        'type': 'integer'
                    },
                    'skip': {
                        'default': 0,
                        'description': 'Number of results to skip for pagination (default: 0)',
                        'type': 'integer'
                    }
                },
                'required': ['query'],
                'type': 'object'
            }
        }
    }, {
        'type': 'function',
        'function': {
            'name': 'query_knowledge_files',
            'description': 'Search knowledge base files using semantic/vector search. Searches across collections (KBs),\nindividual files, and notes that the user has access to.',
            'parameters': {
                'properties': {
                    'query': {
                        'description': 'The search query to find semantically relevant content',
                        'type': 'string'
                    },
                    'knowledge_ids': {
                        'description': 'Optional list of KB ids to limit search to specific knowledge bases',
                        'items': {
                            'type': 'string'
                        },
                        'type': 'array'
                    },
                    'count': {
                        'default': 5,
                        'description': 'Maximum number of results to return (default: 5)',
                        'type': 'integer'
                    }
                },
                'required': ['query'],
                'type': 'object'
            }
        }
    }, {
        'type': 'function',
        'function': {
            'name': 'view_knowledge_file',
            'description': 'Get the full content of a file from a knowledge base.',
            'parameters': {
                'properties': {
                    'file_id': {
                        'description': 'The ID of the file to retrieve',
                        'type': 'string'
                    }
                },
                'required': ['file_id'],
                'type': 'object'
            }
        }
    }],
    'reasoning': {
        'effort': 'none'
    }
}

At the very top of the pipe() function, I log the request body generated by OpenWebUI and the task variable.
The logs make it clear as day, that after the first call with task=None there is no effort to keep the generation running, as the next call is with task=title_generation when using a user account.
With an admin account, there is a follow-up call with task=None.
Since the request is completely the same, the request by OpenRouter obviously doesn't differ in any significant way either.
In both cases the response ends like so:

{
    'id': 'gen-xxxxx',
    'object': 'chat.completion.chunk',
    'created': 1773913407,
    'model': 'qwen/qwen3.5-35b-a3b-20260224',
    'provider': 'Parasail',
    'choices': [{
        'index': 0,
        'delta': {
            'content': '',
            'role': 'assistant'
        },
        'finish_reason': 'tool_calls',
        'native_finish_reason': 'tool_calls'
    }]
}

I stripped the usage field generated by OpenRouter since it is irrelevant.

I am certain that there is no issue with my pipe implementation and that there is some permission check in a place where it shouldn't be.
I have looked at every permission setting existing, but nothing corresponds to the problem.
The tool calling itself is obviously not prohibited, since the UI shows the correct responses, as to be seen here:

Image
Originally created by @moritzderallerechte on GitHub (Mar 19, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/22851 ### 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 (your issue might already be addressed on the development branch!). - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.8.10 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu 24.04.4 LTS ### Browser (if applicable) Chrome 146.0.7680.72 ### 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** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior When having models call integrated tools, OpenWebUI should do a follow up call to the model, including the results of the tool call. ### Actual Behavior When using an admin account, this works as expected (generation continues). However with normal user accounts, the generation just stops. The results of the tool call is correctly shown in the UI, but there is no subsequent request. ### Steps to Reproduce 1. Enable native tool calling 2. Ask a model to call list_knowledge_bases 3. See if the model responds after the tool call ### Logs & Screenshots user log: > 2026-03-19 09:43:27.804 | INFO | function_openrouter_kosten:pipe:142 - pipe:function_openrouter > 2026-03-19 09:43:27.804 | INFO | function_openrouter_kosten:pipe:143 - task: None > 2026-03-19 09:43:28.466 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 10.10.14.70:50944 - "POST /api/chat/completions HTTP/1.1" 200 > 2026-03-19 09:43:28.581 | INFO | function_openrouter_kosten:pipe:142 - pipe:function_openrouter > 2026-03-19 09:43:28.581 | INFO | function_openrouter_kosten:pipe:143 - task: title_generation > 2026-03-19 09:43:28.645 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 10.10.14.70:55705 - "POST /api/chat/completed HTTP/1.1" 200 admin log: > 2026-03-19 09:41:50.748 | INFO | function_openrouter_kosten:pipe:142 - pipe:function_openrouter > 2026-03-19 09:41:50.748 | INFO | function_openrouter_kosten:pipe:143 - task: None > 2026-03-19 09:41:52.097 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 10.10.14.70:59453 - "POST /api/chat/completions HTTP/1.1" 200 > 2026-03-19 09:41:52.360 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 10.10.14.70:59453 - "GET /api/v1/chats/?page=1 HTTP/1.1" 200 > 2026-03-19 09:41:52.382 | INFO | function_openrouter_kosten:pipe:142 - pipe:function_openrouter > 2026-03-19 09:41:52.382 | INFO | function_openrouter_kosten:pipe:143 - task: None > 2026-03-19 09:41:54.987 | INFO | function_openrouter_kosten:pipe:142 - pipe:function_openrouter > 2026-03-19 09:41:54.987 | INFO | function_openrouter_kosten:pipe:143 - task: title_generation > 2026-03-19 09:41:55.814 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 10.10.14.70:59453 - "POST /api/chat/completed HTTP/1.1" 200 ### Additional Information I am using a manifold pipe to connect to OpenRouter, however the issue most definitely does not lay there. The pipe does not do any permission checking or discriminate in any way between users. In fact, no information about the users is ever used for requests. The request generated by the pipe looks exactly the same for every user. I tested with the following example: ``` { 'stream': True, 'model': 'qwen/qwen3.5-35b-a3b', 'messages': [{ 'role': 'user', 'content': [{ 'type': 'text', 'text': 'Ruf die Funktion list_knowledge_bases auf und sag mir danach, was der Inhalt der Rückgabe ist.' }] }], 'tools': [{ 'type': 'function', 'function': { 'name': 'list_knowledge_bases', 'description': "List the user's accessible knowledge bases.", 'parameters': { 'properties': { 'count': { 'default': 10, 'description': 'Maximum number of KBs to return (default: 10)', 'type': 'integer' }, 'skip': { 'default': 0, 'description': 'Number of results to skip for pagination (default: 0)', 'type': 'integer' } }, 'type': 'object' } } }, { 'type': 'function', 'function': { 'name': 'search_knowledge_bases', 'description': "Search the user's accessible knowledge bases by name and description.", 'parameters': { 'properties': { 'query': { 'description': 'The search query to find matching knowledge bases', 'type': 'string' }, 'count': { 'default': 5, 'description': 'Maximum number of results to return (default: 5)', 'type': 'integer' }, 'skip': { 'default': 0, 'description': 'Number of results to skip for pagination (default: 0)', 'type': 'integer' } }, 'required': ['query'], 'type': 'object' } } }, { 'type': 'function', 'function': { 'name': 'query_knowledge_bases', 'description': 'Search knowledge bases by semantic similarity to query.\nFinds KBs whose name/description match the meaning of your query.\nUse this to discover relevant knowledge bases before querying their files.', 'parameters': { 'properties': { 'query': { 'description': "Natural language query describing what you're looking for", 'type': 'string' }, 'count': { 'default': 5, 'description': 'Maximum results (default: 5)', 'type': 'integer' } }, 'required': ['query'], 'type': 'object' } } }, { 'type': 'function', 'function': { 'name': 'search_knowledge_files', 'description': 'Search files across knowledge bases the user has access to.', 'parameters': { 'properties': { 'query': { 'description': 'The search query to find matching files by filename', 'type': 'string' }, 'knowledge_id': { 'description': 'Optional KB id to limit search to a specific knowledge base', 'type': 'string' }, 'count': { 'default': 5, 'description': 'Maximum number of results to return (default: 5)', 'type': 'integer' }, 'skip': { 'default': 0, 'description': 'Number of results to skip for pagination (default: 0)', 'type': 'integer' } }, 'required': ['query'], 'type': 'object' } } }, { 'type': 'function', 'function': { 'name': 'query_knowledge_files', 'description': 'Search knowledge base files using semantic/vector search. Searches across collections (KBs),\nindividual files, and notes that the user has access to.', 'parameters': { 'properties': { 'query': { 'description': 'The search query to find semantically relevant content', 'type': 'string' }, 'knowledge_ids': { 'description': 'Optional list of KB ids to limit search to specific knowledge bases', 'items': { 'type': 'string' }, 'type': 'array' }, 'count': { 'default': 5, 'description': 'Maximum number of results to return (default: 5)', 'type': 'integer' } }, 'required': ['query'], 'type': 'object' } } }, { 'type': 'function', 'function': { 'name': 'view_knowledge_file', 'description': 'Get the full content of a file from a knowledge base.', 'parameters': { 'properties': { 'file_id': { 'description': 'The ID of the file to retrieve', 'type': 'string' } }, 'required': ['file_id'], 'type': 'object' } } }], 'reasoning': { 'effort': 'none' } } ``` At the very top of the _pipe()_ function, I log the request body generated by OpenWebUI and the __task__ variable. The logs make it clear as day, that after the first call with _task=None_ there is no effort to keep the generation running, as the next call is with _task=title_generation_ when using a user account. With an admin account, there is a follow-up call with _task=None_. Since the request is completely the same, the request by OpenRouter obviously doesn't differ in any significant way either. In both cases the response ends like so: ``` { 'id': 'gen-xxxxx', 'object': 'chat.completion.chunk', 'created': 1773913407, 'model': 'qwen/qwen3.5-35b-a3b-20260224', 'provider': 'Parasail', 'choices': [{ 'index': 0, 'delta': { 'content': '', 'role': 'assistant' }, 'finish_reason': 'tool_calls', 'native_finish_reason': 'tool_calls' }] } ``` I stripped the usage field generated by OpenRouter since it is irrelevant. I am certain that there is no issue with my pipe implementation and that there is some permission check in a place where it shouldn't be. I have looked at every permission setting existing, but nothing corresponds to the problem. The tool calling itself is obviously not prohibited, since the UI shows the correct responses, as to be seen here: <img width="1012" height="524" alt="Image" src="https://github.com/user-attachments/assets/c25b2b9c-9e96-449e-95bf-722fc901d70e" />
GiteaMirror added the bug label 2026-04-25 09:34:36 -05:00
GiteaMirror commented 2026-04-25 09:34:38 -05:00
Author
Owner
Copy Link

@moritzderallerechte commented on GitHub (Mar 19, 2026):

I had already mentioned this here but the original post points out a slightly different issue and doesn't mention the permission problem

<!-- gh-comment-id:4089193331 --> @moritzderallerechte commented on GitHub (Mar 19, 2026): I had already mentioned this [here](https://github.com/issues/recent?issue=open-webui%7Copen-webui%7C20896) but the original post points out a slightly different issue and doesn't mention the permission problem
GiteaMirror commented 2026-04-25 09:34:39 -05:00
Author
Owner
Copy Link

@moritzderallerechte commented on GitHub (Mar 19, 2026):

Another note:
I have tried setting the environment variable BYPASS_ADMIN_ACCESS_CONTROL=false, as to emulate user access with an admin account.
This however still results in the same behaviour, being that admin accounts have properly working tool calls and user accounts do not.

<!-- gh-comment-id:4089268166 --> @moritzderallerechte commented on GitHub (Mar 19, 2026): Another note: I have tried setting the environment variable BYPASS_ADMIN_ACCESS_CONTROL=false, as to emulate user access with an admin account. This however still results in the same behaviour, being that admin accounts have properly working tool calls and user accounts do not.
GiteaMirror commented 2026-04-25 09:34:40 -05:00
Author
Owner
Copy Link

@fkeloks commented on GitHub (Mar 19, 2026):

Hello,

I'm experiencing the same issue. Granting the user permissions directly within the tool works, but this results in the "Tools" tab appearing on the interface for all models (instead of being seamlessly integrated into the current model).

<!-- gh-comment-id:4091069800 --> @fkeloks commented on GitHub (Mar 19, 2026): Hello, I'm experiencing the same issue. Granting the user permissions directly within the tool works, but this results in the "Tools" tab appearing on the interface for all models (instead of being seamlessly integrated into the current model).
GiteaMirror commented 2026-04-25 09:34:41 -05:00
Author
Owner
Copy Link

@tjbck commented on GitHub (Mar 25, 2026):

Unable to reproduce, likely a misconfiguration.

<!-- gh-comment-id:4130196550 --> @tjbck commented on GitHub (Mar 25, 2026): Unable to reproduce, likely a misconfiguration.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label bug
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/open-webui#35356
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?