[BUG] `gitStatus` block says "start of the conversation" but is captured per process launch — silently changes across mid-conversation process restarts

Environment

• Claude Code 2.1.222, desktop app, macOS (Darwin 25.6.0)
• Background / worktree session (isolated git worktree under .claude/worktrees/)

Summary

The injected gitStatus context block is labeled:

This is the git status at the start of the conversation. Note that this status is a snapshot in time, and will not update during the conversation.

But it is captured at process launch, not at conversation start — and a conversation can outlive its process. When a session's process restarts mid-conversation (worktree recycling, for example), the block is re-captured against the new process, so it can contain commits created after the conversation began while still claiming it cannot.

Observed

In a background worktree session:

1. Session began with the branch at commit A. The agent's first command, git log --oneline -1, returned A.
2. Roughly 3 minutes later, commit B was created on that branch (background-session auto-commit at task completion).
3. The session's worktree was subsequently recycled and its original process replaced.
4. From then on, the gitStatus block — still labeled "at the start of the conversation" — listed B as the most recent commit.

Confirmed by process accounting: the session's original PID was gone, and every surviving process for the session had a start time later than commit B's author timestamp. So the block's contents match new-process launch, not conversation start.

Why it matters

There is no signal to the reader that the block was re-anchored. An agent that carefully reconciles the block against live git output sees a start-of-conversation snapshot containing a commit that provably postdates the start of the conversation, and the only consistent explanations left are external ones.

In this case the agent concluded that a concurrent session had committed to its branch without authorization, and reported that to the user as a possible security/workflow problem. It was wrong — the commit was ordinary documented background-session behavior — but the reasoning was sound given a context block that contradicted its own label. The user then spent several turns investigating peer sessions, hooks, and git hooks to chase a non-existent problem.

This is more likely to bite in setups with several concurrent sessions against one repository, where "another session did this" is a genuinely plausible hypothesis.

Expected

Either:

• the wording reflects the real capture scope (per process launch, not per conversation), or
• the block is re-anchored explicitly — flagged or timestamped — when the underlying process restarts, so its contents and its label cannot disagree.

Related

• #62947 — gitStatus snapshot captured at process launch rather than first-prompt-submit (same mechanism, opposite symptom: stale rather than fresher-than-labeled)
• #81361 — Agent tool isolation: "worktree" creating worktrees from a stale session-start snapshot