[BUG] Windows 2.1.267: session state becomes inconsistent after auto-compaction (false continuation, missing attachments, stale sessions appear recent)

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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?

### Preflight Checklist

- [x] I searched existing issues. There are related reports, but I did not find one covering this exact combination on Claude Code 2.1.267.
- [x] This report is about one session-state/history integrity regression with several correlated symptoms.
- [x] Reproduced/observed on Claude Code 2.1.267.

### What's Wrong?

On Windows, Claude Code session state/history became unreliable during a long coding session. Three correlated symptoms appeared:

1. **An active session was silently auto-compacted and then rewritten as if it were a resumed/continued conversation.**
- I started the session normally. I did **not** run `/compact`, `/resume`, or intentionally continue another session.
- About 12 minutes later Claude Code inserted a compaction boundary and a synthetic continuation summary beginning with wording equivalent to:
`This session is being continued from a previous conversation that ran out of context.`
- The local JSONL proves the compaction was automatic:

```text
Timestamp : 2026-09-09T21:26:59.023Z
Trigger : auto
PreTokens : 1096859
PostTokens : 9229
Version : 2.1.267

The original user prompt began at 2026-09-09T21:14:55.253Z, so this happened roughly 12 minutes into the same active session.
This wording is misleading because the user did not manually resume/continue anything.
The original attachment/context set stopped being reliably represented after compaction.
The original request included multiple context files attached to the prompt.
After the automatic compaction/continuation boundary, those original attachment chips/files were no longer available in the session UI the way they had been at the start.
The compaction summary references the old context by name, but the actual attached-file state shown by the client no longer matches what was originally supplied.
Other/stale files have also appeared in session surfaces unexpectedly.
Old sessions are suddenly surfacing at the top of Recent/Ungrouped with fresh-looking activity times even though I did not rerun them.
Sessions/prompts that actually ran several days to about a week earlier have appeared at the top of the recent-session feed showing values like 1h or 5h.
I did not rerun those prompts.
Local transcript search still finds their older original content and timestamps.
I have not yet proven whether these fresh timestamps are only session-file/index metadata touches or whether some background path is actually re-opening/reprocessing the sessions, so I am reporting this observation separately from the proven auto-compaction record above.

This makes the sidebar/session UI unsafe to use as evidence of what actually ran or when. I had to recover the authoritative session by searching ~/.claude/projects/**/*.jsonl manually.

### What Should Happen?

- Auto-compaction inside an active session should be clearly labeled as automatic compaction of the current session, not as if the user intentionally resumed another conversation.
- Compaction should preserve/rebind the original attachment/context state, or clearly show which attachments were dropped and why.
- Old sessions should not be moved to the top of Recent/Ungrouped or shown with fresh-looking activity times merely because background metadata/bookkeeping touched a transcript.
- The session picker should distinguish:
- actual user/assistant activity time,
- metadata/index/file modification time,
- compaction time.
- A user should not need to hand-parse .jsonl files to determine which session actually ran and which transcript contains the real implementation result.

### Error Messages/Logs

```shell
There was no explicit error message when the session compacted or when old sessions later appeared recent.

The strongest reproducible evidence is the compact_boundary record in the local JSONL:

trigger: auto
preTokens: 1096859
postTokens: 9229
Claude Code version: 2.1.267

The generated continuation summary was recorded immediately after that boundary as a user-style compact-summary record.
```

### Steps to Reproduce

There was no explicit error message when the session compacted or when old sessions later appeared recent.

The strongest reproducible evidence is the compact_boundary record in the local JSONL:

trigger: auto
preTokens: 1096859
postTokens: 9229
Claude Code version: 2.1.267

The generated continuation summary was recorded immediately after that boundary as a user-style compact-summary record.

Steps to Reproduce / Evidence Collection

The issue is easiest to verify from the local transcript rather than the sidebar:

Run a long, tool-heavy Claude Code session on a large-context model on Windows.
Do not run /compact or /resume.
Let the session continue until Claude Code auto-compacts it.
Inspect the transcript at:
~/.claude/projects//.jsonl
Find type:"system", subtype:"compact_boundary" and inspect compactMetadata.trigger.
In my case it is auto, followed by a synthetic continuation summary that says the conversation is being continued from a previous conversation that ran out of context.
Compare the attachment/context UI before and after the boundary.
Separately, keep several older sessions in history for days, then inspect Recent/Ungrouped. In my case old sessions reappeared at the top with fresh-looking 1h/5h activity despite no intentional rerun.
Compare those sidebar times with the newest real conversational timestamp in each corresponding .jsonl.

PowerShell used to prove the compaction trigger:

$path = "$HOME\.claude\projects\\.jsonl"

[System.IO.File]::ReadLines($path) | ForEach-Object {
try { $j = $_ | ConvertFrom-Json -ErrorAction Stop } catch { return }

if ($j.type -eq "system" -and $j.subtype -eq "compact_boundary") {
[pscustomobject]@{
Timestamp = $j.timestamp
Trigger = $j.compactMetadata.trigger
PreTokens = $j.compactMetadata.preTokens
PostTokens = $j.compactMetadata.postTokens
Version = $j.version
}
}
}

Observed output:

Timestamp : 2026-09-09T21:26:59.023Z
Trigger : auto
PreTokens : 1096859
PostTokens : 9229
Version : 2.1.267

### Claude Model

Opus

### Is this a regression?

Yes, this worked in a previous version

### Last Working Version

_No response_

### Claude Code Version

2.1.267

### Platform

Anthropic API

### Operating System

Windows

### Terminal/Shell

Other

### Additional Information

Possibly related:

#92434 — auto-compaction/context-window behavior
#92949 — stale context re-injected during auto-compaction
#92209 — Windows local session transcript persistence problems
#90888 — session/chat history missing on Windows
#82914 — pre-compaction history remains on disk but is difficult to access in product UI
Impact

This is high impact for long-running coding/security work because I can no longer trust the client UI to tell me:

which session actually ran,
when it ran,
whether a prompt was rerun,
whether I am looking at the original or compacted context,
or whether the attachment set still corresponds to the original request.

I nearly reran a large implementation prompt because its real result appeared to be missing. The only reason I recovered it was by manually searching the local JSONL transcripts.

Start by inspecting the referenced ~/.claude/projects//.jsonl transcript and the compact_boundary records, using the supplied PowerShell query to confirm automatic compaction. Compare transcript timestamps and attachment state before and after compaction, then compare those records with Recent/Ungrouped timestamps. Done means automatic continuation is accurately represented, attachment state is explained or preserved, and session activity times reflect real activity rather than metadata touches.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.