Interrupted settings saves can leave invalid JSON

[wutongyuonce]

The coding-agent settings storage locks writes but writes the settings file in place. Reproduction: start a settings update, then terminate the process after truncation and before the JSON is fully written. On the next launch, the settings file may be empty or incomplete JSON and cannot be parsed. Expected behavior: after any interrupted update, the file remains either the complete previous JSON or the complete new JSON. A small candidate fix writes and flushes a temporary file in the same directory, then renames it over the settings file while preserving its existing permissions. I can provide the patch and test results if maintainers consider this in scope.

[RelaxJonh]

Confirmed by code inspection. The non-atomic write path is in packages/coding-agent/src/core/settings-manager.ts line 277 and packages/coding-agent/src/core/auth-storage.ts line 162 — both use direct writeFileSync without a temporary-file-then-rename pattern.

The project already has the correct atomic-write pattern in packages/coding-agent/src/core/telemetry.ts (lines 239-254):

function writeTelemetryStateAtomically(path: string, state: TelemetryState): void {
    const temporaryPath = `${path}.${process.pid}.${randomUUID()}.tmp`;
    try {
        writeFileSync(temporaryPath, JSON.stringify(state, null, 2), {
            encoding: "utf8",
            flag: "wx",   // fail if temp file already exists
            mode: 0o600,
        });
        renameSync(temporaryPath, path);
    } finally {
        try {
            unlinkSync(temporaryPath);
        } catch {
            // The rename succeeded or the temporary file was never created.
        }
    }
}

On POSIX systems rename is atomic. On Windows, renameSync over an existing file can fail with EPERM if the target is open — the pattern needs a try { unlinkSync(path) } catch {} before the rename on win32, or a CopyFileEx with COPY_FILE_REPLACE_EXISTING. The telemetry code does not handle this Windows edge case either, so a fix for both settings-manager.ts and auth-storage.ts should include the Windows fallback.

The auth-storage.ts path is particularly risky because it writes auth.json (credentials), and the lock acquisition (acquireLockSyncWithRetry) only protects against concurrent writes within the same process — it does not protect against SIGTERM or power loss during writeFileSync.