Repository navigation
Description
[Bug] Project edit dialog does not persist name or icon changes (Windows Desktop v1.17.4)
Description
When editing a project's name or display image via the Edit dialog (right-click project in sidebar → Edit), clicking Save does not persist the changes. After restarting the desktop app, the project reverts to its original name and icon.
Environment
- OS: Windows 11
- OpenCode Desktop version: 1.17.4
- Database location:
%USERPROFILE%\.local\share\opencode\opencode.db - App data location:
%APPDATA%\ai.opencode.desktop\
Steps to Reproduce
- Open OpenCode Desktop on Windows
- Right-click any project in the left sidebar
- Select "Edit"
- Change the project name
- Optionally upload a new icon image
- Click "Save"
- The name appears to update temporarily in the sidebar
- Restart the desktop app
- The project name reverts to the directory name; the custom icon is gone
Investigation Findings
Storage analysis
Project/workspace metadata is stored in two separate locations, neither of which is properly written by the Edit dialog's Save handler:
1. SQLite database (%USERPROFILE%\.local\share\opencode\opencode.db → project table)
Fields: id, worktree, name, icon_url_override, icon_color
Only a single entry (id='global', worktree='/') exists by default, with name=NULL. Per-project entries are never created for user workspace directories, even after editing via the UI.
2. Settings file (%APPDATA%\ai.opencode.desktop\opencode.global.dat)
This is a flat JSON key-value store (written via electron-store or similar). The key layout.page.workspaceName is an object mapping workspace directory paths to display names:
"layout.page": "{\"workspaceName\":{}}"The workspaceName object is always empty {}, confirming the Save button does not write to this key.
Workaround tested
Manually editing the JSON data in global.dat to populate workspaceName does make custom names appear in the sidebar after restarting the app. However:
- The running app overwrites
global.datduring operation (confirmed via file byte comparison), so manual edits are short-lived - This confirms the app reads from
layout.page.workspaceNamefor display, but the Edit dialog's save handler fails to write to it
Other findings
- The renderer logs show no errors related to saving project metadata
- The
serverkey inglobal.dattracks workspace list (paths) but does not store names or icon references - No icon-related storage key was found in
global.dator the SQLiteprojecttable for user workspaces (only theglobalentry exists)
Expected Behavior
The Edit dialog should persist the project name to layout.page.workspaceName in global.dat (and icon to project.icon_url_override in the SQLite DB, or wherever the app expects it), so changes survive app restarts.
Actual Behavior
The Save button triggers no observable write to any storage location. Changes are silently lost on restart.
Additional Context
Similar issues were previously reported:
- Project edit dialog does not persist name or icon changes #24744 (v1.14.28) - Project edit dialog does not persist name or icon changes
- Web: Workspace icon preview updates but Save does not persist icon (fallback initials remain) #26888 - Web: Workspace icon preview updates but Save does not persist
- Project profile image not displayed after upload #27882 (v1.15.3) - Project profile image not displayed after upload
- OpenCode Desktop 1.14.22 ignores project.icon_url_override after webview refresh. #24197 (v1.14.22) - Desktop ignores
icon_url_overrideafter webview refresh
These were purportedly fixed by PR #28855 (fix(app): respect custom opencode project icons), but the issue persists in v1.17.4 on Windows.
Activity
github-actions commentedon Jun 13, 2026
This issue might be a duplicate of existing issues. Please check:
If your issue is distinct from all of the above, please clarify what's different. Otherwise, consider adding your findings (especially the storage analysis) as a comment on one of the existing issues.
Bl0ck154 commentedon Jun 25, 2026
I dug into the Windows Desktop v1.17.4 bundle and confirmed this is still a frontend rendering/propagation issue in addition to persistence/refresh behavior.
What changed in v1.17.4:
I put together a workaround patch that adapts to hashed bundle filenames and is idempotent across updates:
If helpful, I can also summarize the exact bundle-level diff / matching blocks I found in v1.17.4.
yiyinideshang commentedon Jul 16, 2026
Hi, buddy. I just wanted to bring up this issue as well. I didn't expect you to have mentioned it in v1.17.4. But to be honest, why hasn't this bug been fixed for so long? Does the official of opencode_ai think it's unimportant?
github-actions commentedon Sep 15, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.