I have searched the existing issues and discussions.
Problem Description
I want a tool server to be able to disambiguate calls associated with distinct chats.
Concrete example use case: Suppose I want to be able to make a "publish this conversation to GitHub as a gist" tool available via a tool server. I want that tool to be able reach back to OWUI to gather the other messages in current conversation. Setting aside the complications of authenticated access to the conversation history (not the focus here), the current system design doesn't give the tool server any way to know which conversation is this conversation. (This is a simplification of my real use case.)
Desired Solution you'd like
I can see at least two distinct designs that would work:
Expose {{CHAT_ID}} as a prompt template variable
This would give the assistant knowledge of the current chat identifier, making it available to be passed (when appropriate) in tool arguments.
A downside of this approach is that we'd rely on the model to accurately copy the value of {{CHAT_ID}} into tool arguments. If a model makes a mistake in that process, it could be tricky to debug.
An upside is that, because we don't have a chat id for temporary chats (the chat id is "local"), this would also allow us to write system prompts that make the model sensitive to whether the current conversation is off the record or not, which might have additional uses beyond what I'm considering today.
Another upside of this approach is that it is save/private by default. The prompt writer opts into this feature by using {{CHAT_ID}} in the system prompt just like they do for {{USER_NAME}} and {{USER_EMAIL}} or whatever. Unless these are explicitly included, these details won't leak.
Offer a X-OpenWebUI-Chat-ID headers tool server fetch request
In this design, the chat id is communicated exactly to the tool server without risking model hallucinations. It seems natural that the tool integrator would get the configuration option to include this header or not (perhaps disabled by default to avoid even this minor data leak).
I can't think of major downsides to this approach, and it is probably the better option.
The thing where it might be nice for the model to know if the the chat is a temporary one or not could be more directly achieved by having a simple and direct {{IS_TEMPORARY_CHAT}} variable. (This avoids distracting the model with the details of the chat GUID.)
Alternatives Considered
See above.
Additional Context
I'm working towards a new design for Brace that is based on tool servers rather than tool code that runs inside of the OWUI container. I'd like some of my tools to be sensitive to the conversation state, but I don't want to explore designs where the entire conversation history is blasted out to the tool server on each call. Just having the chat id would be sufficient for my tools to reach back to OWUI and gather (or maybe even inject) any other context they need. For example, from the chat id, I'd be able to look up the user, etc.
Originally created by @rndmcnlly on GitHub (May 21, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/14142
### Check Existing Issues
- [x] I have searched the existing issues and discussions.
### Problem Description
I want a tool server to be able to disambiguate calls associated with distinct chats.
Concrete example use case: Suppose I want to be able to make a "publish this conversation to GitHub as a gist" tool available via a tool server. I want that tool to be able reach back to OWUI to gather the other messages in current conversation. Setting aside the complications of authenticated access to the conversation history (not the focus here), the current system design doesn't give the tool server any way to know which conversation is *this* conversation. (This is a simplification of my real use case.)
### Desired Solution you'd like
I can see at least two distinct designs that would work:
### Expose `{{CHAT_ID}}` as a prompt template variable
This would give the assistant knowledge of the current chat identifier, making it available to be passed (when appropriate) in tool arguments.
A downside of this approach is that we'd rely on the model to accurately copy the value of {{CHAT_ID}} into tool arguments. If a model makes a mistake in that process, it could be tricky to debug.
An upside is that, because we don't have a chat id for temporary chats (the chat id is "local"), this would also allow us to write system prompts that make the model sensitive to whether the current conversation is *off the record* or not, which might have additional uses beyond what I'm considering today.
Another upside of this approach is that it is save/private by default. The **prompt writer** opts into this feature by using `{{CHAT_ID}}` in the system prompt just like they do for `{{USER_NAME}}` and `{{USER_EMAIL}}` or whatever. Unless these are explicitly included, these details won't leak.
### Offer a `X-OpenWebUI-Chat-ID` headers tool server fetch request
In this design, the chat id is communicated exactly to the tool server without risking model hallucinations. It seems natural that the **tool integrator** would get the configuration option to include this header or not (perhaps disabled by default to avoid even this minor data leak).
I can't think of major downsides to this approach, and it is probably the better option.
The thing where it might be nice for the model to know if the the chat is a temporary one or not could be more directly achieved by having a simple and direct `{{IS_TEMPORARY_CHAT}}` variable. (This avoids distracting the model with the details of the chat GUID.)
### Alternatives Considered
See above.
### Additional Context
I'm working towards a new design for [Brace](https://brace.tools/) that is based on tool servers rather than tool code that runs inside of the OWUI container. I'd like some of my tools to be sensitive to the conversation state, but I don't want to explore designs where the entire conversation history is blasted out to the tool server on each call. Just having the **chat id** would be sufficient for my tools to reach back to OWUI and gather (or maybe even inject) any other context they need. For example, from the chat id, I'd be able to look up the user, etc.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @rndmcnlly on GitHub (May 21, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/14142
Check Existing Issues
Problem Description
I want a tool server to be able to disambiguate calls associated with distinct chats.
Concrete example use case: Suppose I want to be able to make a "publish this conversation to GitHub as a gist" tool available via a tool server. I want that tool to be able reach back to OWUI to gather the other messages in current conversation. Setting aside the complications of authenticated access to the conversation history (not the focus here), the current system design doesn't give the tool server any way to know which conversation is this conversation. (This is a simplification of my real use case.)
Desired Solution you'd like
I can see at least two distinct designs that would work:
Expose
{{CHAT_ID}}as a prompt template variableThis would give the assistant knowledge of the current chat identifier, making it available to be passed (when appropriate) in tool arguments.
A downside of this approach is that we'd rely on the model to accurately copy the value of {{CHAT_ID}} into tool arguments. If a model makes a mistake in that process, it could be tricky to debug.
An upside is that, because we don't have a chat id for temporary chats (the chat id is "local"), this would also allow us to write system prompts that make the model sensitive to whether the current conversation is off the record or not, which might have additional uses beyond what I'm considering today.
Another upside of this approach is that it is save/private by default. The prompt writer opts into this feature by using
{{CHAT_ID}}in the system prompt just like they do for{{USER_NAME}}and{{USER_EMAIL}}or whatever. Unless these are explicitly included, these details won't leak.Offer a
X-OpenWebUI-Chat-IDheaders tool server fetch requestIn this design, the chat id is communicated exactly to the tool server without risking model hallucinations. It seems natural that the tool integrator would get the configuration option to include this header or not (perhaps disabled by default to avoid even this minor data leak).
I can't think of major downsides to this approach, and it is probably the better option.
The thing where it might be nice for the model to know if the the chat is a temporary one or not could be more directly achieved by having a simple and direct
{{IS_TEMPORARY_CHAT}}variable. (This avoids distracting the model with the details of the chat GUID.)Alternatives Considered
See above.
Additional Context
I'm working towards a new design for Brace that is based on tool servers rather than tool code that runs inside of the OWUI container. I'd like some of my tools to be sensitive to the conversation state, but I don't want to explore designs where the entire conversation history is blasted out to the tool server on each call. Just having the chat id would be sufficient for my tools to reach back to OWUI and gather (or maybe even inject) any other context they need. For example, from the chat id, I'd be able to look up the user, etc.