[GH-ISSUE #198] bug: workspace display name silently reset to the path basename by routine autosaves #116

New issue

Closed

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

bsakaguchi commented

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

Owner

Originally created by @penradioGables on GitHub (Jul 28, 2026).
Original GitHub issue: https://github.com/open-webui/computer/issues/198

Summary

Renaming a workspace does not stick. The name reverts to the raw path basename (cptr for /home/cptr) shortly afterwards, at what looks to the user like a random moment — it is actually the next routine autosave.

Verified still present in v0.9.15 — cptr/routers/state.py is byte-identical between the v0.9.10 and v0.9.15 tags.

Root cause

routers/state.py::put_workspace (PUT /api/state/workspace, L169–180) defaults name to the path basename whenever the request body omits the key:

    name = workspace_data.pop("name", _workspace_display_name(workspace_path))
    workspace_data.pop("path", None)
    # Everything else is workspace data (groups, tabs, etc.)
    await Workspace.upsert(user_id, workspace_path, name, workspace_data)

Routine tab/layout/group autosaves from the frontend never include "name". .pop(key, default) cannot distinguish "the caller omitted this" from "the caller set this", so every such autosave overwrites the stored name with the basename.

Note the read path already does the right thing — workspace.name or _workspace_display_name(path) (L98) — so the fallback exists in both places, and only the write path needs to stop applying it unconditionally.

Why it matters beyond cosmetics

The model id exposed to OpenAI-compatible clients is derived from the workspace, so this churns the advertised model identity too. With two cptr instances attached to the same Open WebUI, both collapse to the same basename-derived id and collide. (Working around that at the OWUI end with a connection prefix_id is what made the underlying reset visible to us in the first place.)

Suggested fix

Only fall back to the basename when no row exists yet; when a row exists and the request omits name, preserve the stored value.

Happy to open a PR.

Originally created by @penradioGables on GitHub (Jul 28, 2026). Original GitHub issue: https://github.com/open-webui/computer/issues/198 ### Summary Renaming a workspace does not stick. The name reverts to the raw path basename (`cptr` for `/home/cptr`) shortly afterwards, at what looks to the user like a random moment — it is actually the next routine autosave. **Verified still present in v0.9.15** — `cptr/routers/state.py` is byte-identical between the `v0.9.10` and `v0.9.15` tags. ### Root cause `routers/state.py::put_workspace` (`PUT /api/state/workspace`, L169–180) defaults `name` to the path basename whenever the request body omits the key: ```python name = workspace_data.pop("name", _workspace_display_name(workspace_path)) workspace_data.pop("path", None) # Everything else is workspace data (groups, tabs, etc.) await Workspace.upsert(user_id, workspace_path, name, workspace_data) ``` Routine tab/layout/group autosaves from the frontend never include `"name"`. `.pop(key, default)` cannot distinguish "the caller omitted this" from "the caller set this", so every such autosave overwrites the stored name with the basename. Note the read path already does the right thing — `workspace.name or _workspace_display_name(path)` (L98) — so the fallback exists in both places, and only the write path needs to stop applying it unconditionally. ### Why it matters beyond cosmetics The model id exposed to OpenAI-compatible clients is derived from the workspace, so this churns the advertised model identity too. With two cptr instances attached to the same Open WebUI, both collapse to the same basename-derived id and collide. (Working around that at the OWUI end with a connection `prefix_id` is what made the underlying reset visible to us in the first place.) ### Suggested fix Only fall back to the basename when no row exists yet; when a row exists and the request omits `name`, preserve the stored value. Happy to open a PR.

bsakaguchi closed this issue

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

bsakaguchi commented

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

Author

Owner

@tjbck commented on GitHub (Jul 31, 2026):

Should be addressed!

@tjbck commented on GitHub (Jul 31, 2026): Should be addressed!

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

No description provided.

Rows
Columns