Project edit dialog (rename/avatar) silently does nothing — server API works fine

Description

Project edit dialog (rename/avatar) silently does nothing — server API works fine

Version

• opencode 1.18.21 (server via opencode web, Linux x86_64 installer)
• OpenCode Desktop 1.18.21 (AppImage)
• Also reproduced with a 1.17.19 server + 1.18.21 Desktop client

Environment

Fedora 44, KDE, Wayland (also reproduced under X11 before upgrading).

Summary

Editing a project's name or avatar from the project menu ("Edit") in both the Web UI and the Desktop app appears to succeed (no error is shown) but never persists. The equivalent REST call succeeds, so the server-side write path is functional — the UI never issues a working request.

Repro

1. Start server: opencode web --port 4097
2. In the Web UI (or Desktop connected to that server), open a project's menu → Edit → change the name → save.
3. Observe: name unchanged in the project list, immediately and after refresh/restart.

Expected: the project name updates.
Actual: no visible change, no error, nothing in the server logs.

Evidence

• DB inspection (project table in opencode.db): UI edit attempts leave name / icon_url_override untouched — no write occurs. One project edited via UI showed icon_url_override = '' (empty string), suggesting the avatar payload may be sent but mangled.

• Direct API call succeeds and persists:

  curl -X PATCH http://127.0.0.1:4097/project/<project-id> \
       -H 'Content-Type: application/json' -d '{"name":"New Name"}'
  → HTTP 200, name persisted in DB and served by GET /project
  

  The same works for avatars: {"icon": {"override": "data:image/png;base64,..."}} persists and renders.

• Server log shows no request or error at the timestamps of UI-edit attempts.

• Also affects renaming the global workspace row (used when the open directory isn't a registered project) — same silent no-op via UI, works via PATCH.

• Not version skew alone: reproduced with 1.18.21 on both client and server.

Addendum: failure appears intermittent / state-dependent

In one session, a UI rename landed on a project that already had a name set, while UI edits in the same session to other projects (empty-string name, or the global workspace row) silently failed. This suggests the client may skip or drop the request when the field state is unexpected (NULL/empty), rather than the endpoint being unreachable.

Workaround

PATCH /project/{id} with {"name": ...} and/or {"icon": {"override": ..., "color": ...}}.

Plugins

No response

OpenCode version

No response

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response