git stash ran on my working tree with no corresponding tool call in any transcript — 170 uncommitted files wiped mid-session

Summary

A git stash ran against my project's working tree during a long-running Claude Code session, wiping ~170 uncommitted tracked-file modifications from disk mid-session — with no corresponding tool call in any transcript on the machine. All work was recovered from the stash entry, but the command's origin cannot be traced to any agent, hook, script, or human input.

Environment

• Claude Code 2.1.126, Windows 11 Home 10.0.26200
• Long-running interactive session with multiple background workflows/subagents, plus a second concurrent Claude Code session in the same repository
• Repo on branch teamhouse-main, large uncommitted changeset (~170 modified tracked files, ~350 untracked)

Timeline (local, 2026-08-11)

• 04:34:43 — refs/stash updated (a git stash push against the working tree)
• 04:34:45 — reflog records reset: moving to HEAD (the stash's implicit reset)
• .git/objects mtimes cluster at 04:34:43.5–43.9 — consistent with a single stash command
• Effect: all tracked modifications reverted to HEAD on disk; untracked files untouched. Two running subagents observed files change shape mid-task ("file has been modified since read" on Edit; a file read twice minutes apart returned structurally different content).

Forensics performed (both sessions, independently)

• Parsed all 1,667 *.jsonl transcripts under ~/.claude/projects (every project on the machine) for tool_use commands containing git stash / git reset / git clean: zero matches in the event window. 68 tool calls executed 08:33:30Z–08:35:10Z; all were file edits/DB calls from known agents; none were git.
• Codex CLI: no session alive 23:49 → 08:40.
• npm scripts contain no git; the three configured hooks contain no git/exec/spawn.
• PSReadLine history last written 2026-07-27; bash history 2026-02-12 — nothing typed at a terminal.
• No files under ~/.claude modified 04:30–04:40.

Hypothesis (unproven, labeled as such)

Only Claude Code was running. The stash left no trace in any transcript, suggesting an app-level action (checkpoint / rewind / restore / worktree teardown) that shells out to git without writing a transcript entry. If Claude Code has any code path that stashes or resets a user's working tree, it (a) should never run against a tree with uncommitted work without explicit confirmation, and (b) should be logged somewhere user-visible.

Impact and recovery

• ~8 hours of verified work vanished from disk mid-flight; two subagents nearly built on top of the reverted tree before catching the inconsistency.
• Full recovery: the work survived in stash@{0} and was re-applied (git stash apply), verified by typecheck/tests. A subsequent git stash pop attempted by a subagent failed harmlessly against the already-applied content — the stash entry was retained as backup throughout.
• No data ultimately lost, but only because stash (not e.g. checkout -- .) happened to be the mechanism.

Related session IDs

• a049c2ab-45c6-4e88-b9f7-c75e9724e998 (second session in the same repo; filing its own report with its transcript)
• 336d3f3c-2eb0-4272-afc0-b0e656ff56ab (this session — the one whose working tree was hit and which performed the recovery)

Ask

1. Does any Claude Code 2.1.x code path (checkpointing, rewind, worktree management, session teardown) invoke git stash/git reset on the user's repository?
2. If yes: gate it on explicit confirmation when uncommitted changes exist, and log the invocation to the session transcript.
3. If no: interested in what else could produce an untraceable stash under these conditions.