fix(accounts): accounts.json is safe across gclo processes; an unreadable file is not a corrupt one #155

New Issue

2026-11-10T21:19:18Z

james.maes commented

2026-11-10 21:19:18 +00:00

Found in the 1.1.1 review.

accounts.json is not safe when two gclo processes use it. The store reads the file once and every later change writes that snapshot back. With the desktop app open, an account added from the CLI is erased by the app's next write (recording a sync result is enough), and its token is left behind in the vault with nothing pointing at it. The reverse happens during a long gclo sync --account, and two app instances do the same to each other.

Expected: every change reads the file again and applies only that one change, by account id, while holding a lock that other gclo processes respect.

A file that cannot be read is treated as a corrupt one. Any failure to read accounts.json, including the file being briefly in use, renames the live file aside and starts with no accounts; even gclo accounts list does that. Only content that is not valid JSON should be moved aside. A file that is in use should be tried again, and if it stays unreadable it should be left exactly where it is.

settings.json is written in place, so a crash mid-write can truncate it, and a failed write is neither reported nor logged. The comment about a duration of 0 meaning "absent" describes something that does not happen.

Found in the 1.1.1 review. **`accounts.json` is not safe when two gclo processes use it.** The store reads the file once and every later change writes that snapshot back. With the desktop app open, an account added from the CLI is erased by the app's next write (recording a sync result is enough), and its token is left behind in the vault with nothing pointing at it. The reverse happens during a long `gclo sync --account`, and two app instances do the same to each other. Expected: every change reads the file again and applies only that one change, by account id, while holding a lock that other gclo processes respect. **A file that cannot be read is treated as a corrupt one.** Any failure to read `accounts.json`, including the file being briefly in use, renames the live file aside and starts with no accounts; even `gclo accounts list` does that. Only content that is not valid JSON should be moved aside. A file that is in use should be tried again, and if it stays unreadable it should be left exactly where it is. **`settings.json`** is written in place, so a crash mid-write can truncate it, and a failed write is neither reported nor logged. The comment about a duration of 0 meaning "absent" describes something that does not happen.

james.maes referenced this issue from a commit

2026-11-10 21:24:57 +00:00

fix(accounts): accounts.json is safe across gclo processes; an unreadable file is not a corrupt one

james.maes referenced a pull request that will close this issue

2026-11-10 21:24:58 +00:00

fix(accounts): accounts.json is safe across gclo processes; an unreadable file is not a corrupt one #156

james.maes referenced this issue from a commit

2026-11-10 22:06:06 +00:00

fix(accounts): accounts.json is safe across gclo processes; an unreadable file is not a corrupt one

james.maes referenced this issue from a commit

2026-11-10 22:06:06 +00:00

fix(accounts): address the independent review of the shared accounts file