Agent destroyed 2 days of uncommitted work via destructive git operation in main worktree

Summary

A Claude Code CLI agent instance destroyed ~2 days of uncommitted and staged work by executing a destructive git command (git reset --hard) in the user's main working directory. The agent was attempting a worktree-based approach but backed out into the main repo and ran the destructive command there, wiping 12 modified/staged files.

This occurred on 2026-03-12 in a multi-agent workflow where one CLI instance was doing platform infrastructure work (with extensive uncommitted changes) and another was launched to fix a PR.

What happened

1. User had 12 uncommitted modifications + 3 untracked files on branch feat/new-platform-account representing 1-2 days of Pulumi infrastructure work (new AWS account provisioning, IAM policies, Identity Center config, deployment policies, tests)
2. A second Claude Code CLI instance was launched to fix Copilot review feedback on PR #37
3. That agent attempted a worktree approach but backed out into the main working directory
4. The agent ran git reset --hard origin/main in the main repo, destroying all uncommitted modifications to tracked files
5. Work was NOT recoverable from git (checked reflog, dangling blobs, dangling commits)
6. Recovery required ~4 hours of manual reconstruction from conversation context, AWS API state, and surviving untracked files

Lost files (modifications to tracked files — irrecoverable)

• pulumi/org_stack/__main__.py — full platform account provisioning (~100 lines of new code)
• pulumi/org_stack/resources/deployment_policies.py — new get_platform_policy() function
• pulumi/org_stack/resources/identity_center.py — platform SSO permission sets, groups, assignments
• pulumi/org_stack/resources/account.py — type literal update
• pulumi/org_stack/tests/conftest.py — SSO invoke mock
• pulumi/org_stack/tests/test_deployment_policies.py — platform policy tests
• pulumi/org_stack/Pulumi.org.yaml — config secret
• pulumi/github_runners_stack/__main__.py — export additions
• pulumi/github_runners_stack/resources/network.py — new attribute
• docs/plans/ui-separation-infra-consolidation.md — status updates
• .serena/memories/project_overview.md (staged)

Surviving files (untracked — survived branch switch)

• pulumi/platform_stack/ (entire new directory)
• pulumi/org_stack/tests/test_identity_center.py
• pulumi/github_runners_stack/tests/test_network.py

Secondary issue: Accuracy degradation after context compaction

During the recovery conversation, after context was compacted (prior messages summarized), the agent exhibited repeated accuracy failures:

1. Confident incorrect claims about git state — stated a file was uncommitted when it had already been committed, without running git status to verify
2. Incomplete task execution — when tasked with syncing a status document to reflect completed work (deployments the user explicitly reported), missed deploy checkboxes and manual steps, only updating the obvious code task items
3. Stale architectural context — confidently described an outdated architectural approach (CloudFront/WAF) as the current plan when the implementation had pivoted to a different pattern (VPC endpoint service / private gateway), information that was available in the codebase

These aren't catastrophic individually, but the pattern of confident wrong statements after compaction erodes user trust significantly.

Expected behavior

1. Agents should NEVER run destructive git commands (reset --hard, checkout ., clean -f) in the user's main working directory. If an agent needs to work on a different branch, it should use git worktree add and stay in the worktree, or use gh api for remote-only operations. If an agent starts a worktree approach, it should not fall back to operating in the main repo.

1. After context compaction, the model should verify state before making claims. Running git status before stating what is committed/uncommitted. Reading files before describing their contents. Checking the codebase before asserting architectural decisions.

1. When updating status documents, the model should systematically check all sections — not just the ones that come to mind first.

Environment

• Claude Code CLI v2.1.72
• Model: claude-opus-4-6
• macOS Darwin 25.3.0
• Multiple concurrent CLI instances on same repo