Repository navigation
fix(tui): retry writeJsonAtomic on transient EPERM rename collisions on Windows #61119
Description
Description
In packages/tui/src/util/persistence.ts, writeJsonAtomic creates a temporary file and replaces the destination using rename(temporary, filePath).
On Windows NTFS, atomic renames fail immediately with Error: EPERM: operation not permitted when another handle (such as anti-virus, indexing, or a concurrent async tick) holds an open handle or is replacing the destination file. Because packages/tui/src/context/local.tsx calls void writeJsonAtomic(filePath, ...), this rejection is unhandled and logs:
level=ERROR message="unhandled rejection" cause="Error: EPERM: operation not permitted, rename '.../session.json.<pid>.<uuid>.tmp' -> '.../session.json'" role=cli
When this occurs in bursts (e.g., during startup or event stream reconnects), the pending session.json state updates are lost.
Adding a short retry loop with exponential backoff for transient EPERM / EBUSY rename errors on win32 prevents lost writes.
Plugins
none
OpenCode version
2.2.5 (dev)
Steps to reproduce
- On Windows, run OpenCode in an environment where multiple state writes occur in quick succession.
- Check
~/.local/share/opencode/log/opencode.logfor unhandled rejections during startup. - Observe concurrent
rename '.../session.json.<pid>.<uuid>.tmp' -> '.../session.json'throwingEPERM.
Screenshot
Not applicable (filesystem concurrency and unhandled rejection issue).
Operating System
Windows 11, Windows 10
Terminal
Windows Terminal, PowerShell
Activity
opencodejr commentedon Nov 2, 2026
Thanks for the clear report. I couldn't reproduce this here because it needs Windows file locking. This sandbox is Linux, where renaming over a file another process has open always succeeds, so the
EPERMcan't happen. A maintainer with a Windows machine will need to confirm it.On the latest
dev(8bca532),writeJsonAtomicinpackages/tui/src/util/persistence.tsstill renames the temporary file oversession.jsononly once, with no retry. If the rename fails, it deletes the temporary file and passes the error on. Thesession.jsonwrite inpackages/tui/src/context/local.tsxdoesn't catch that error, which fits the unhandled rejection and the lost write you're seeing.Related:
EPERMon thesession.jsonrename on Windows. It was closed, but the code still has no retry.EPERMin the desktop app's settings and window-state files, with a PR that adds a retry.Bearmancer commentedon Nov 2, 2026
@opencodejr Thanks for confirming the mechanism on dev (8bca532).
Indeed, on Windows NTFS, file handles held by anti-virus scanners, Windows search indexers, or rapid concurrent async ticks cause atomic renames to fail with EPERM rather than waiting. Adopting the exact retry-with-backoff pattern already implemented for the desktop app's state persistence in #51470 / #54530 will make writeJsonAtomic resilient on win32.