Data loss: conversation history, credentials, and staged files silently destroyed

Bug Category

Data loss is the #8 bug category (~4 issues). User data is silently destroyed without recovery path.

Representative issues

• Conversation history JSONL files silently lost (#29923) — session files disappear while file-history backups survive, suggesting a write-then-delete race
• OAuth credentials wiped on failed token refresh (#29896) — a transient auth failure permanently deletes credentials, forcing full re-authentication
• Cowork wiped tasks and history on cache clear (#30092) — clearing browser/app cache destroys persistent data that should survive cache operations
• Agent overwrote staged files with Write tool (#29809) — agent used Write tool to overwrite files the user had staged in git, then ran git stash without permission, corrupting the staging area

Root cause

1. No write-ahead log: file operations are not journaled, so a crash between "delete old" and "write new" loses both
2. Credentials stored in volatile location: failed refresh deletes the credential before attempting re-auth, so if re-auth fails, the credential is gone
3. Cache vs. data conflation: user-visible data (tasks, history) stored alongside cache data that's expected to be disposable

Proposed mitigations

1. Atomic file operations:
Use write-to-temp + rename for all persistent data (session files, credentials, settings). This is a POSIX guarantee — rename is atomic within a filesystem.

2. Never delete before confirming replacement:
For credential refresh: attempt new auth first, only delete old credential after new one is confirmed valid.

3. Separate cache from data:
Use distinct directories for disposable cache vs. persistent data. A "clear cache" operation should never touch persistent data.

4. Git staging awareness:
Before overwriting a file, check if it has staged changes (git diff --cached --name-only). If so, warn the user or refuse the write.

Related issues

#29923, #29896, #30092, #29809