limitations #146

New issue

Open

opened 2026-10-18 14:03:21 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-18 14:03:21 +00:00

Owner

Originally created by @rs189 on GitHub (Aug 20, 2026).
Original GitHub issue: https://github.com/open-webui/computer/issues/234

Currently, the messaging support, at least with Discord, has some limitations.

For example, asking cptr to create a timer from within Discord creates a timer; however, the response is not sent in Discord after the timer is up.

One way to work around this is to explicitly enable chat alerts in Notifications for "Chat finished" and "Chat failed" alerts.

However, that has several issues:

It may result in duplicate messages.
It always comes with explicit "Chat finished" and "Chat failed" tags.

Similar behavior occurs with scheduled jobs/cron: each run creates a new chat, but the resulting response is not returned to the Discord conversation that created the job.

This plays into a separate issue: with the current design, messaging integrations appear to be scoped to the conversation that originated on that platform, rather than being associated with the Computer workspace as a whole.

For example, if Discord is intended to be the primary interface for a given workspace, activity originating from the Computer web UI, timers, or scheduled tasks does not appear to be automatically delivered to the associated Discord conversation. The notify tool can be used as a workaround, but this requires explicitly instructing the agent to invoke it rather than the messaging integration acting as a general output channel for the workspace.

Desired behavior

I think there should be a way to associate a messaging target, such as a Discord conversation, with a Computer workspace and optionally designate it as the workspace's primary messaging interface.

For example:

Messages sent from Discord should continue to receive normal responses in Discord.
Timers and scheduled tasks created from Discord should be able to return their resulting response to that same Discord conversation.
Conversations started from the Computer web UI could optionally be mirrored to the associated Discord conversation.
Background/scheduled runs should have a way to send their normal assistant response to the associated Discord conversation without requiring to tell the model to explicitly call notify via a system prompt or similar workaround.
The existing notify tool could remain available for messages that are intentionally separate from the normal conversation flow.

In other words, I would like the messaging integration to behave more like a transport/interface for a Computer workspace, rather than only responding to messages that originate from that messaging platform.

I am not sure whether this is intended behavior, a configuration issue, or a missing feature, so clarification on the intended model would also be helpful.

Originally created by @rs189 on GitHub (Aug 20, 2026). Original GitHub issue: https://github.com/open-webui/computer/issues/234 Currently, the messaging support, at least with Discord, has some limitations. For example, asking cptr to create a timer from within Discord creates a timer; however, the response is not sent in Discord after the timer is up. <img width="256" height="350" alt="Image" src="https://github.com/user-attachments/assets/f364e0c6-3ed6-4260-afd8-a7ecca79a62a" /> One way to work around this is to explicitly enable chat alerts in Notifications for "Chat finished" and "Chat failed" alerts. However, that has several issues: * It may result in duplicate messages. * It always comes with explicit "Chat finished" and "Chat failed" tags. <img width="256" height="200" alt="Image" src="https://github.com/user-attachments/assets/1b2f6f8e-f591-4596-b981-e05352a4bfbd" /> <img width="256" height="50" alt="Image" src="https://github.com/user-attachments/assets/facf6543-3ebc-42e8-aa89-8c3e3a6701d9" /> Similar behavior occurs with scheduled jobs/cron: each run creates a new chat, but the resulting response is not returned to the Discord conversation that created the job. --- This plays into a separate issue: with the current design, messaging integrations appear to be scoped to the conversation that originated on that platform, rather than being associated with the Computer workspace as a whole. For example, if Discord is intended to be the primary interface for a given workspace, activity originating from the Computer web UI, timers, or scheduled tasks does not appear to be automatically delivered to the associated Discord conversation. The `notify` tool can be used as a workaround, but this requires explicitly instructing the agent to invoke it rather than the messaging integration acting as a general output channel for the workspace. ### Desired behavior I think there should be a way to associate a messaging target, such as a Discord conversation, with a Computer workspace and optionally designate it as the workspace's primary messaging interface. For example: * Messages sent from Discord should continue to receive normal responses in Discord. * Timers and scheduled tasks created from Discord should be able to return their resulting response to that same Discord conversation. * Conversations started from the Computer web UI could optionally be mirrored to the associated Discord conversation. * Background/scheduled runs should have a way to send their normal assistant response to the associated Discord conversation without requiring to tell the model to explicitly call `notify` via a system prompt or similar workaround. * The existing `notify` tool could remain available for messages that are intentionally separate from the normal conversation flow. In other words, I would like the messaging integration to behave more like a **transport/interface for a Computer workspace**, rather than only responding to messages that originate from that messaging platform. I am not sure whether this is intended behavior, a configuration issue, or a missing feature, so clarification on the intended model would also be helpful.

No labels

enhancement

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

open-webui/computer#146

No description provided.

Rows
Columns