open-webui/computer

Fork 0

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

[GH-ISSUE #244] bug: gateway renders only the tool name to OpenAI-compatible clients — arguments are available but discarded, and nothing renders on completion #157

New issue

Open

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

bsakaguchi commented

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

Owner

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

Summary

_format_tool_call in cptr/routers/gateway.py renders a tool call to OpenAI-compatible clients as the tool's name and nothing else — no command, no arguments, no output. The arguments are available on the item by the time this function runs; it reads them only to extract title, then discards the rest.

This is the remaining half of #196. That issue fixed capture (input_json_delta fragments are now accumulated) and #197 fixed the name. Both landed. But the gateway still drops everything except the name on the way out, so for an OpenAI-compatible client the original symptom of #196 is unchanged: "You can see that Bash ran; you can never see what command it ran."

Verified in v0.9.21, running live against Open WebUI 0.11.1.

Current behaviour

cptr/routers/gateway.py:

def _format_tool_call(item: dict) -> str | None:
    """Render a tool call as compact markdown for OpenAI-compatible clients."""
    if item.get("type") != "function_call" or item.get("status") != "in_progress":
        return None

    arguments = item.get("arguments")
    title = arguments.get("title") if isinstance(arguments, dict) else None
    name = str(title or item.get("name") or "tool").strip() or "tool"
    return f"\n\n`{name}`\n\n"

arguments is in scope and populated — claude_code.py reassembles it from the accumulated input_json and attaches it alongside title — but only title is read.

Two consequences

1. Arguments are discarded. A turn that runs five commands renders as five identical `Bash` markers with no way to tell them apart, in the response or in the persisted chat.

2. Nothing renders on completion. The guard is status != "in_progress", so the only event that produces output is the tool starting. There is no terminal output, no result, and no success/failure signal — a tool that errored looks exactly like one that succeeded.

Why this matters more than it looks

I'm reporting this on behalf of a totally blind daily user (VoiceOver, macOS) who drives cptr agents through Open WebUI as the frontend — which is the arrangement gateway.py's own docstring describes.

For a sighted user a bare Bash marker is uninformative. For a screen-reader user it is worse than uninformative: the reply reads as a sequence of identical one-word announcements with no content between them, and there is no way to tell whether the agent did what was asked, did something else, or failed. The visual UI at least conveys shape; read aloud, there is nothing there at all.

Suggested direction

Not prescriptive about the form, but two things would resolve it:

Render the arguments, at least the primary one — the command for Bash, the path for Read/Write/Edit. A fenced block keyed on the tool would fit the existing compact-markdown style.
Emit on completion as well as start, so output and failure are visible. The output event already carries the item; the status != "in_progress" guard is what excludes it.

A verbosity setting would be reasonable if full output is considered too noisy for the default — though for the accessibility case the failure signal in particular should probably not be behind a flag.

Happy to open a PR if that would help; I've read the surrounding code and the change looks contained to this function and its two call sites. Given the project's first-time-contributor policy I'd rather be asked than assume.

Originally created by @ThalynLabs on GitHub (Aug 29, 2026). Original GitHub issue: https://github.com/open-webui/computer/issues/244 ### Summary `_format_tool_call` in `cptr/routers/gateway.py` renders a tool call to OpenAI-compatible clients as **the tool's name and nothing else** — no command, no arguments, no output. The arguments are available on the item by the time this function runs; it reads them only to extract `title`, then discards the rest. **This is the remaining half of #196.** That issue fixed *capture* (`input_json_delta` fragments are now accumulated) and #197 fixed the *name*. Both landed. But the gateway still drops everything except the name on the way out, so for an OpenAI-compatible client the original symptom of #196 is unchanged: *"You can see that `Bash` ran; you can never see what command it ran."* **Verified in v0.9.21**, running live against Open WebUI 0.11.1. ### Current behaviour `cptr/routers/gateway.py`: ```python def _format_tool_call(item: dict) -> str | None: """Render a tool call as compact markdown for OpenAI-compatible clients.""" if item.get("type") != "function_call" or item.get("status") != "in_progress": return None arguments = item.get("arguments") title = arguments.get("title") if isinstance(arguments, dict) else None name = str(title or item.get("name") or "tool").strip() or "tool" return f"\n\n`{name}`\n\n" ``` `arguments` is in scope and populated — `claude_code.py` reassembles it from the accumulated `input_json` and attaches it alongside `title` — but only `title` is read. ### Two consequences **1. Arguments are discarded.** A turn that runs five commands renders as five identical `` `Bash` `` markers with no way to tell them apart, in the response or in the persisted chat. **2. Nothing renders on completion.** The guard is `status != "in_progress"`, so the only event that produces output is the tool *starting*. There is no terminal output, no result, and no success/failure signal — a tool that errored looks exactly like one that succeeded. ### Why this matters more than it looks I'm reporting this on behalf of a totally blind daily user (VoiceOver, macOS) who drives cptr agents through Open WebUI as the frontend — which is the arrangement `gateway.py`'s own docstring describes. For a sighted user a bare `Bash` marker is uninformative. For a screen-reader user it is worse than uninformative: the reply reads as a sequence of identical one-word announcements with no content between them, and there is no way to tell whether the agent did what was asked, did something else, or failed. The visual UI at least conveys *shape*; read aloud, there is nothing there at all. ### Suggested direction Not prescriptive about the form, but two things would resolve it: - **Render the arguments**, at least the primary one — the command for `Bash`, the path for `Read`/`Write`/`Edit`. A fenced block keyed on the tool would fit the existing compact-markdown style. - **Emit on completion as well as start**, so output and failure are visible. The `output` event already carries the item; the `status != "in_progress"` guard is what excludes it. A verbosity setting would be reasonable if full output is considered too noisy for the default — though for the accessibility case the failure signal in particular should probably not be behind a flag. Happy to open a PR if that would help; I've read the surrounding code and the change looks contained to this function and its two call sites. Given the project's first-time-contributor policy I'd rather be asked than assume.

bsakaguchi commented

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

Author

Owner

@owui-terminator[bot] commented on GitHub (Aug 29, 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:

🟣 #197 bug: every tool call renders as agent_tool to OpenAI-compatible clients
This is the immediate precursor: it fixed the tool name mapping in the gateway renderer for OpenAI-compatible clients. The new issue is the remaining bug in the same _format_tool_call path, where arguments and completion output are still dropped.
by penradioGables
🟣 #196 Issue #196
This issue is the directly related earlier half of the same bug report. It covered the missing input_json_delta capture that populated arguments; the new issue explicitly says that even after #196, the gateway still discards those captured arguments on render.
by unknown
🟣 #183 issue: many tool call turns look ugly
Related at the UX level: it concerns too many tool-call turns being hard to read in chat, which overlaps with the new report's concern that the gateway renders tool calls poorly for users, especially when multiple tool calls appear.
by Classic298

💡 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 29, 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. 🟣 [#197](https://github.com/open-webui/computer/issues/197) **bug: every tool call renders as `agent_tool` to OpenAI-compatible clients** *This is the immediate precursor: it fixed the tool name mapping in the gateway renderer for OpenAI-compatible clients. The new issue is the remaining bug in the same `_format_tool_call` path, where arguments and completion output are still dropped.* *by penradioGables* 2. 🟣 [#196](https://github.com/open-webui/computer/issues/196) **Issue #196** *This issue is the directly related earlier half of the same bug report. It covered the missing `input_json_delta` capture that populated `arguments`; the new issue explicitly says that even after #196, the gateway still discards those captured arguments on render.* *by unknown* 3. 🟣 [#183](https://github.com/open-webui/computer/issues/183) **issue: many tool call turns look ugly** *Related at the UX level: it concerns too many tool-call turns being hard to read in chat, which overlaps with the new report's concern that the gateway renders tool calls poorly for users, especially when multiple tool calls appear.* *by Classic298* --- 💡 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.

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

No description provided.

Rows
Columns