open-webui/computer

Fork 0

mirror of https://github.com/open-webui/computer.git synced 2026-11-05 01:17:24 +00:00

`) are never intercepted — parsed as plain chat text #149

New issue

Open

opened 2026-10-18 14:03:23 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

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

Owner

Originally created by @Chengzhi-Yang on GitHub (Aug 24, 2026).
Original GitHub issue: https://github.com/open-webui/computer/issues/235

Body:

Summary

Commands sent to a messaging bot (Discord/Telegram/etc.) that take an argument — /workspace <name> and /model <id> — are never intercepted by the bot's command layer. They fall through to normal message dispatch and reach the agent as plain text, so the documented behavior (/workspace <name> switches the bot's workspace and starts a new chat) never happens.

Bare commands without arguments (/new, /stop, /retry, /help, /workspaces) work fine.

Environment

cptr version: 0.9.21 (pip package cptr, installed via venv)
Platform: Discord bot (bug is in the shared bridge core, so it affects all platforms: Telegram, Discord, Slack, WhatsApp, Signal)
Docs that document the command: https://docs.openwebui.com/ecosystem/computer/automate/messaging-bots/ ("Commands" table lists /workspace <name> — Switch workspace (fuzzy match) and start a new chat)

Steps to reproduce

Create a bot in Settings → Admin → Bots (platform: Discord, workspace: /projects), start it.
In the Discord channel, send: /workspace jellyfin-storage
Observe: no "✨ Switched to ... New conversation started." reply. Instead, the message is treated as a normal user message — the agent receives /workspace jellyfin-storage as plain text and responds to it conversationally.
Same result for /model <id>.

Root cause

In cptr/utils/bridge.py, BotManager._handle_message, the command is extracted like this:

# Normalize: strip Discord bot mention prefix (<@123456>)
# and Telegram command suffix (/cmd@BotName → /cmd)
import re
clean = re.sub(r"<@!?\d+>\s*", "", text).strip()
cmd = clean.split("@")[0].lower() if clean.startswith("/") else ""

clean.split("@")[0] only strips a Telegram-style @BotName suffix — it does not split on whitespace. So:

/workspace jellyfin-storage → cmd = "/workspace jellyfin-storage" → cmd == "/workspace" is False → falls through to chat dispatch
/model gpt-4o → cmd = "/model gpt-4o" → cmd == "/model" is False → falls through

The command handler for /workspace exists and is correct (it matches by name/path suffix, updates the bot config, and starts a new chat) — it's just unreachable because the parser never produces a bare /workspace.

Suggested fix

One line in cptr/utils/bridge.py:

cmd = clean.split()[0].split("@")[0].lower() if clean.startswith("/") else ""

Verified: this yields cmd == "/workspace" for /workspace jellyfin-storage, still strips @BotName suffixes (/cmd@BotName → /cmd), and leaves bare commands and non-slash messages unchanged.

Workaround (for users on affected versions)

Set the bot's workspace directly in Settings → Admin → Bots instead of using /workspace, or patch the single line above (note: it lives in the container's writable layer and is lost on container rebuild).

Originally created by @Chengzhi-Yang on GitHub (Aug 24, 2026). Original GitHub issue: https://github.com/open-webui/computer/issues/235 **Body:** ## Summary Commands sent to a messaging bot (Discord/Telegram/etc.) that take an argument — `/workspace <name>` and `/model <id>` — are never intercepted by the bot's command layer. They fall through to normal message dispatch and reach the agent as plain text, so the documented behavior (`/workspace <name>` switches the bot's workspace and starts a new chat) never happens. Bare commands without arguments (`/new`, `/stop`, `/retry`, `/help`, `/workspaces`) work fine. ## Environment - cptr version: 0.9.21 (pip package `cptr`, installed via venv) - Platform: Discord bot (bug is in the shared bridge core, so it affects all platforms: Telegram, Discord, Slack, WhatsApp, Signal) - Docs that document the command: https://docs.openwebui.com/ecosystem/computer/automate/messaging-bots/ ("Commands" table lists `/workspace <name>` — Switch workspace (fuzzy match) and start a new chat) ## Steps to reproduce 1. Create a bot in **Settings → Admin → Bots** (platform: Discord, workspace: `/projects`), start it. 2. In the Discord channel, send: `/workspace jellyfin-storage` 3. Observe: no "✨ Switched to ... New conversation started." reply. Instead, the message is treated as a normal user message — the agent receives `/workspace jellyfin-storage` as plain text and responds to it conversationally. 4. Same result for `/model <id>`. ## Root cause In `cptr/utils/bridge.py`, `BotManager._handle_message`, the command is extracted like this: ```python # Normalize: strip Discord bot mention prefix (<@123456>) # and Telegram command suffix (/cmd@BotName → /cmd) import re clean = re.sub(r"<@!?\d+>\s*", "", text).strip() cmd = clean.split("@")[0].lower() if clean.startswith("/") else "" ``` `clean.split("@")[0]` only strips a Telegram-style `@BotName` suffix — it does **not** split on whitespace. So: - `/workspace jellyfin-storage` → `cmd = "/workspace jellyfin-storage"` → `cmd == "/workspace"` is `False` → falls through to chat dispatch - `/model gpt-4o` → `cmd = "/model gpt-4o"` → `cmd == "/model"` is `False` → falls through The command handler for `/workspace` exists and is correct (it matches by name/path suffix, updates the bot config, and starts a new chat) — it's just unreachable because the parser never produces a bare `/workspace`. ## Suggested fix One line in `cptr/utils/bridge.py`: ```python cmd = clean.split()[0].split("@")[0].lower() if clean.startswith("/") else "" ``` Verified: this yields `cmd == "/workspace"` for `/workspace jellyfin-storage`, still strips `@BotName` suffixes (`/cmd@BotName` → `/cmd`), and leaves bare commands and non-slash messages unchanged. ## Workaround (for users on affected versions) Set the bot's workspace directly in **Settings → Admin → Bots** instead of using `/workspace`, or patch the single line above (note: it lives in the container's writable layer and is lost on container rebuild).

bsakaguchi commented

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

Author

Owner

@owui-terminator[bot] commented on GitHub (Aug 24, 2026):

🔍 Related Issues Found

I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:

🟢 #234 issue: messaging/Discord missed responses/limitations
Related because it is the only nearby messaging-bot issue and discusses Discord integration limitations in the same bridge/core area. However, it focuses on delivery of responses from timers/scheduled jobs rather than command parsing.
by rs189

💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.

This comment was generated automatically. React with 👍 if helpful, 👎 if not.

@owui-terminator[bot] commented on GitHub (Aug 24, 2026):  🔍 **Related Issues Found** I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions: 1. 🟢 [#234](https://github.com/open-webui/computer/issues/234) **issue: messaging/Discord missed responses/limitations** *Related because it is the only nearby messaging-bot issue and discusses Discord integration limitations in the same bridge/core area. However, it focuses on delivery of responses from timers/scheduled jobs rather than command parsing.* *by rs189* --- 💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead. *This comment was generated automatically.* React with 👍 if helpful, 👎 if not.

bsakaguchi referenced this issue

2026-10-18 14:04:33 +00:00

[PR #149] [MERGED] 0.9.9 #304

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#149

No description provided.

Rows
Columns

[GH-ISSUE #235] bug: Messaging bot commands with arguments (/workspace <name>, /model <id>) are never intercepted — parsed as plain chat text #149