Activity

1. github-actions

   assigned

   Hona

   on Sep 26, 2026
2. github-actions commented on Sep 26, 2026

   

   github-actionsBot

   on Sep 26, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be related to existing issues. Please check:

   • Desktop scoped-store cleanup can race later writes on Windows #45154: Desktop scoped-store cleanup can race later writes on Windows, causing store-file EPERM errors.
   • cli: concurrent session.json writes race on Windows → EPERM, TUI loses current session #47497: Concurrent Windows CLI state-file writes can fail on atomic rename with EPERM, dropping persisted state.
3. waterundman commented on Oct 7, 2026

   

   waterundman

   on Oct 7, 2026

   Author

   More actions

   Keeping this one open — it's the issue tracked by PR #51474, which is still awaiting a maintainer to approve the workflow run.

   Two notes for anyone arriving here from the duplicate-detection comment above.

   Why this isn't a duplicate of #45154 / #47497:

   • cli: concurrent session.json writes race on Windows → EPERM, TUI loses current session #47497 (closed) was about the CLI writing session.json. This report is about the Desktop app's persisted renderer state (store-set / store-delete / store-clear over IPC).
   • Desktop scoped-store cleanup can race later writes on Windows #45154 (open) is adjacent but a different mechanism: it describes a scoped-store cleanup racing later writes. The failure reported here is one layer up — the three IPC handlers call electron-store directly, so a transient rename failure (EPERM / EBUSY / EACCES) is thrown straight back into the renderer with no retry at all, and the write is silently dropped. The log line in the description is a plain store-set failing on the final rename.

   They are complementary rather than overlapping: making the handlers retry (PR #51474) does not replace fixing the cleanup race in #45154, and vice versa. Linking the two threads here so that's visible.

   Status of the fix: PR #51474 — fix(desktop): retry store writes on Windows EPERM — addresses this report (retry with backoff, then an in-place writeFileSync fallback, so the user's change is never silently discarded). It is currently blocked pending a maintainer workflow approval, not on any code issue.
4. waterundman

   changed the title [-]Windows: store-set can fail with EPERM on rename, silently dropping persisted state[/-] [+]Windows: desktop settings and window-state writes can fail with EPERM on rename, silently dropping persisted state[/+] on Oct 11, 2026
5. waterundman commented on Oct 11, 2026

   

   waterundman

   on Oct 11, 2026

   Author

   More actions

   V2 port: #54530.

   store-set no longer exists in V2 (renderer state went to SQLite), so this is aimed at the two main-process writers that still keep JSON with the same temporary-file rename - storage/store.ts and windows/window-state.ts. Both now share one helper: retry the rename, then write through the open handle if the target is still locked, and remove the .tmp either way.

   A Windows-only bun:ffi test reproduces the failure against the pre-fix helper with the same EPERM, and the dwShareMode measurements are in the PR. CI is action_required pending approval.
6. finfanger commented on Oct 15, 2026

   

   finfanger

   on Oct 15, 2026

   More actions

   Related to #51470, but with a different failure mode — the errno is wrong, and the failure is deterministic rather than a race.

   What I'm seeing

   OpenCode v2.0.29 fails to start at all on my machine, because the background service bootstrap can't persist its config:

   Starting background server...
   Error: Server process exited with code 1
   PlatformError: Unknown: FileSystem.rename (C:\Users<user>.config\opencode\service.json.tmp)
   at MA (B:/~BUN/root/chunk-2qa1wxmc.js:2:956)
   ...
   [cause]: Error: EXDEV: cross-device link not permitted, rename
   'C:\Users<user>.config\opencode\service.json.tmp'
   -> 'C:\Users<user>.config\opencode\service.json')
   at service.ensure (B:/~BUN/root/chunk-r5wq91nb.js:3:732)
   at cli.server-connection.resolve

   Note the path: source and destination are in the same directory, so EXDEV ("cross-device link not permitted") is semantically wrong. This is not a cross-volume move.

   Key difference from the existing reports: it's 100% reproducible

   #51470 / #47497 / #45154 describe EPERM/EBUSY caused by a transient lock from a scanner or indexer. That is a race — retrying usually works.

   On this machine it never works. Minimal repro, no OpenCode involved:

   const d = "C:/Users/<user>/ocdata/";
   fs.writeFileSync(d + "b1.tmp", "x");
   fs.renameSync(d + "b1.tmp", d + "b1.json");
   // Node: EXDEV: cross-device link not permitted
   // shell mv: succeeds
   

   Same directory, same volume, same session. fs.renameSync fails 100% of the time; mv on the identical pair succeeds. Once the destination file already exists, the error changes from EXDEV to EPERM — which suggests the syscall is being intercepted rather than the filesystem genuinely being cross-device.

   Things I ruled out:

   • OPENCODE_CONFIG_DIR pointed at unrelated directories — same failure
   • Node's own fs.renameSync with no wrapper involved — same failure
   • rename targets across several different directories (including a freshly created one) — all fail

   I have not identified the exact cause. I checked for third-party filesystem filters: FltMgr reports 0 registered minifilters, and the only non-Windows kernel driver present is Sandboxie's SbieDrv. So it may be something else entirely — possibly a kernel-mode filter I can't enumerate, or a low-level hook. I'm posting the observable behavior in case it's useful, since the signature (same-directory rename always failing, errno flipping between EXDEV/EPERM) is quite specific.

   Why this needs a different fix than #54530

   A retry-with-backoff strategy won't help here — the operation is not transient, so every retry fails and the CLI never becomes usable. That leaves --standalone as the only working option, which is fine for me but means the shared background service is unavailable.

   Two suggestions that would make this class of environment usable:

   1. Don't fail hard when the service config can't be persisted. Fall back to in-process/standalone operation instead of exiting, so the CLI stays usable.
   2. Treat EXDEV as "retry via copy+unlink" rather than a fatal error. That's the conventional POSIX meaning of EXDEV, and handling it that way would make this work transparently — from the caller's perspective a same-directory move is a case where copy+delete is a valid, if slower, substitute.

   Small doc discrepancy

   The troubleshooting docs say the private service config lives at ~/.config/opencode/service.json and the shared server registers at ~/.local/state/opencode/service.json. On v2.0.29 the failing temp file is ~/.config/opencode/service.json.tmp, so the write path is under .config as documented — but I never got a successful service.json to appear in either location, so I couldn't verify the final layout.

   Environment

   • opencode v2.0.29 (installed via npm, @opencode/cli)
   • Windows 10 Pro, 22H2, 10.0.19045.6466
   • Terminal: Windows Terminal / Windows PowerShell 5.1
   • Workaround that works today: opencode --standalone (and opencode run --standalone)