Primary finding
saveSession is not atomic on Windows when target exists, and not concurrency-safe across processes
- src/session.ts:44-52
SESSION_TMP and SESSION_FILE are constants shared across all sessions for a user. Two mythos processes running concurrently for the same user will race on latest.tmp — one process can overwrite the other's tmp file between writeFileSync and renameSync, producing a corrupted/incorrect SESSION_FILE that mixes data from two sessions. Even single-process: if writeFileSync throws partway, latest.tmp is left on disk indefinitely (no cleanup). The header comment claims 'atomic writes' but the tmp path is not unique per call (no PID/UUID suffix), violating the typical atomic-write contract.
Recommendation
Use a unique tmp filename per call (e.g., `latest.${process.pid}.${Date.now()}.tmp` or crypto.randomUUID()), wrap in try/finally to unlink the tmp on failure, and consider an advisory file lock (proper-lockfile) for multi-process safety.