[Bug] File checkpointing silently stashes and hard-resets working tree, destroying uncommitted edits

Bug Description
File checkpointing (tengu_use_file_checkpoints) silently git-stashes + git reset --hards the working tree, repeatedly wiping uncommitted edits. ENVIRONMENT - Claude Code CLI on macOS (Darwin 25.5.0), launched from Warp. - Git repo with: pre-commit framework hooks installed, PreToolUse governance hooks, and an editable-installed (pip install -e .) MCP server running from within the same repo. These may be relevant to why it triggered here — I did not fully isolate the trigger condition. - ~/.claude.json shows "tengu_use_file_checkpoints": true under cachedStatsigGates. SYMPTOM Across one work session, uncommitted edits to a tracked file vanished ~8 times. git reflog showed repeated reset: moving to HEAD entries I did not create (2026-06-11 22:24, 22:26; 2026-06-12 17:05, 17:24, 17:31, 17:33, 17:51, 17:54), and git stash list grew by one each time. Every multi-step commit attempt then failed with "nothing to commit, working tree clean" — because the checkpoint stashed the staged changes microseconds before git commit ran. EVIDENCE (root-caused via a .git/hooks/reference-transaction trap) The destructive op is git stash, whose internal step is git reset --hard -q --no-recurse-submodules. The trap captured the full process ancestry on two separate events: - pytest → pre-tool-governance-check.sh → git stash → git reset --hard - claude (main process) → pre-tool-governance-check.sh → git stash → git reset --hard The hook in the chain is an innocent intermediary (it contains no git commands); the git stash is driven by the Claude Code process around tool calls. It is intermittent (debounced), not per-tool-call. EXPECTED vs ACTUAL Expected: checkpointing snapshots state transparently and restores it. Actual: it leaves the working tree reset to HEAD; the only reason no work was lost is that git stash saves to the stash stack (recoverable, but not restored automatically). Multi-step staged commits are effectively impossible while it's active; the workaround was clean-tree → single atomic apply+commit so the commit lands before the next stash window. TWO DOC/UX GAPS 1. There is no documented user-facing toggle to disable checkpointing (no settings.json key, no env var, no /config option per current docs). Please add one. 2. The checkpointing docs (code.claude.com/docs/en/checkpointing) state checkpoints use Claude Code's own file-editing snapshots and do NOT use git. Observed behavior is git-stash + git-reset-based. Docs and implementation disagree. ASK: (a) a documented off-switch; (b) checkpointing must never leave the tree reset without restoring; (c) reconcile the docs with the git-based implementation.

Environment Info

• Platform: darwin
• Terminal: WarpTerminal
• Version: 2.1.173
• Feedback ID: 7fb327a7-1726-422c-91d2-bc5c9b56a883

Errors

[]