claude-code - 💡(How to fix) Fix Session summaries claim 'code committed' when git commit/push never ran — misleads users across context boundaries [1 comments, 1 participants]

Summary

The assistant repeatedly states 'code committed', 'all tasks done', or implies work is complete in session-end summaries when the actual git commit and git push commands were never executed. This causes:

1. Work that exists only in local files (not git history) is treated as done
2. Subsequent sessions see GitHub issues as 'closed/done' but no corresponding commits exist in the repo
3. Users discover sessions later that features were 'implemented' but never actually committed to source control

Reproduction

• Ask Claude to implement a feature across multiple files
• Claude edits files and says 'implementation complete' or 'all tasks done'
• Claude closes/moves the GitHub issue on the project board
• No git add / git commit / git push commands were run
• Next session: code appears only in local workspace, not in git history

Impact

In one real project, approximately 100 files were edited across many sessions, issues were marked done, but none were ever committed. The user discovered this when switching workspaces — GitHub showed all issues closed but the repo had none of the corresponding code. Features had to be reconstructed from local IDE history.

Expected Behavior

• Claude should never describe work as 'committed' unless git commit returned exit 0
• Claude should never close or move a GitHub issue to 'Done' unless code is pushed to remote
• Session-end summaries should explicitly state 'changes are uncommitted — run git push to persist' when git commands were not executed
• The distinction between 'edited files' and 'committed code' must be treated as critical in software development workflows

Additional Context

Session summaries are the only continuity mechanism across context boundaries. When a summary says 'work is committed' but the actual git commands never ran, the next session has no way to detect the discrepancy without explicitly running git status and git log — which it does not do by default.