[BUG]

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Title

Claude Code on the web: container restart during an active session restores a
stale provisioning snapshot (rolls back local .git/HEAD) instead of re-syncing
to the latest pushed branch tip

Environment

• Product: Claude Code on the web (<claude.ai/code>), remote/cloud execution environment
• Repo: private; working on a long-lived feature branch (not main)
• Workflow: agent commits to the feature branch and git pushes throughout the session

Summary

During a single active session, the execution container was restarted multiple
times (~4×). On each restart the container's filesystem — including the entire
.git directory — was restored to the commit the session was provisioned at
(the previous session's branch tip), NOT to the latest commit I had pushed to the
remote during this session.

Effect: local HEAD silently rewinds to a stale baseline, edits to tracked files
revert, and the git reflog is rolled back so there's no in-repo trace. Pushed
commits remain safe on the remote, but the local checkout is left behind the
remote with no warning, mid-task.

Steps to reproduce

1. Start a web session on a feature branch whose remote tip is, say, commit BASE.
2. Over the session, make several commits and git push them (remote advances to

BASE+1 … BASE+n).

1. Leave the container idle long enough to be reclaimed (or otherwise trigger a

restart); resume the session.

1. Observe local state.

Observed behavior

• Local HEAD is back at BASE (the provisioning snapshot), while

origin/<branch> is at BASE+n.

• Edits to tracked files made during the session are reverted; newly-created

untracked files happen to survive (no git clean is run).

• git reflog shows a clean gap: it jumps from the provisioning commit straight

to my post-restore commands — the intervening session commits and the rewinds
themselves are absent, i.e. .git/logs/HEAD was restored from the snapshot.

Evidence collected (forensics)

• cat /proc/uptime → container up ~11 minutes, while the session's own activity

spanned several hours → the container was restarted mid-session.

• PID 1 (process_api) start time matched the ~11-minute uptime (fresh process tree).
• Branch reflog jumped directly from the provisioning commit (prior day) to my

recovery reset — no record of the ~5 commits I'd made and pushed in between,
nor of the rewinds → confirms a filesystem-level restore of .git, not a
git reset/checkout run inside the repo.

• .git/logs/HEAD mtime equaled my latest post-restore commit (the reflog only

contains entries written after the last restore).

• .claude/settings.json contained no SessionStart/reset hook → not config-induced.
• Recovery each time: git fetch origin <branch> && git reset --hard origin/<branch>

restored everything, which only works because the remote was unaffected.

Expected behavior

On resume/restart, the working checkout should be re-synced to the latest pushed
tip of the working branch (effectively git fetch && git reset --hard
origin/<branch> when there are no unpushed local commits), or at minimum the
session should surface a clear warning that local state was rolled back behind the
remote. Restoring the original provisioning snapshot — which is behind the remote
the session itself advanced — is the defect.

Impact

• Silent and mid-task; the only symptoms are local HEAD/SHA changing and (in my

case) test counts dropping.

• Data-loss risk: any local commit not yet pushed, and any uncommitted edit to a

tracked file, is discarded on the next restart. (Survives only if pushed.)

• Misleading: presents as "remote drift" / mysterious lost changes; costs real time

to detect and re-sync repeatedly.

Suggested fix

1. On container resume, re-anchor the checkout to origin/<session-branch> (latest

pushed tip) rather than the provisioning snapshot.

1. Failing that, detect local HEAD behind origin/<branch> on resume and warn

loudly (and/or auto-fetch).

1. Consider preserving the in-session .git (incl. reflog) across restarts so local

commits aren't silently dropped.

Severity

High — silent potential for losing unpushed work; recurring within a single session.

What Should Happen?

Shouldn’t have potential for work to regress.

Error Messages/Logs

Steps to Reproduce

See bug report.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.176

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Running on iOS