Windows desktop: unclean session termination corrupts CJK text in the transcript jsonl and pollutes the next session (ghost file-change diffs, fabricated tool output)

Status Open
Reported on v2.1.183
Maintainer reply None cached
Activity 0 comments · opened Jul 16, 2026

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?

When a session dies from a network disconnect instead of exiting cleanly, two defects compound:

  1. The session's transcript jsonl is left corrupted — the last entry is a type=last-prompt stub and CJK strings in the file are mojibake (e.g. cwd C:\知識庫 recorded as C:\?亥?摨俞, lastPrompt value garbled).
  2. The client carries this dirty state across sessions: the NEXT session's file-change detection uses the dead session's stale snapshot as its baseline and emits fabricated "file changed externally" diffs.

Incident 1 (2026-07-09, desktop app v2.1.197): A session disconnected in the morning and died uncleanly (jsonl fingerprint as above). The next session, upon its first edit to a todo file, received a "file was modified externally" notification whose diff (a) showed the file reverted to a stale morning version and (b) contained a whole fabricated instruction line that exists nowhere on disk and in no transcript (verified by searching all 48 session transcripts — zero hits). The real file on disk was intact. The fabricated line looked like an injected instruction, so the assistant initially flagged it as possible prompt injection — i.e. the client itself manufactured what was nearly treated as an attack.

Incident 2 (2026-07-12, same root cause, worse payload): After another disconnect, a Read tool call on a normal local markdown file returned a fake security warning ("API key leaked / tools disabled / go rotate your key") instead of the file content. Reading the same file through an independent channel (.NET File.ReadAllText) showed the file on disk was 100% intact, tools were not disabled, and the account was fine. Retrying Read after the state settled returned normal content. A corrupted channel that spontaneously produces urgent security instructions is a trust/safety problem, not just a data bug: it actively urges the user toward an unnecessary credential rotation.

Related (but distinct): #69994 covers session-local tool-I/O corruption on Windows (fabricated/replayed results, mojibake); #78076 covers file-state desync after successful edits. This report adds the cross-session dimension: an uncleanly-dead session's state polluting the next session's file-change baseline.

What Should Happen?

  1. On abnormal termination, session state/buffers should be discarded or reconciled on next launch — never used as a file-change baseline for a later session.
  2. Transcript jsonl writes should be UTF-8-safe on Windows regardless of system codepage (the mojibake pattern suggests a cp950/double-encoding path).
  3. Tool results shown to the model should never be synthesized from stale client state — a Read should either return real file content or a clear error, never fabricated content.

Error Messages/Logs

Fingerprint of the dead session's transcript jsonl (observed 2026-07-09, desktop v2.1.197):
- last entry is a bare type=last-prompt stub (no clean session close)
- CJK strings are mojibake: cwd "C:\知識庫" recorded as "C:\?亥?摨俞"; lastPrompt value garbled ("?ession?嗅極")

Incident 2 (2026-07-12): a Read tool call returned a fabricated security warning ("API key leaked / tools disabled / rotate your key") instead of the file content; an independent read (.NET File.ReadAllText) showed the file on disk was intact; Read recovered after retry once the state settled.

Steps to Reproduce

  1. Windows 11, Claude Code desktop app, working directory with CJK path segments (e.g. C:\知識庫\...), network where disconnects are routine (VPN).
  2. Start a session and edit some files, then let the network drop mid-session so the session dies without a clean exit.
  3. Inspect the dead session's transcript jsonl: the last entry is a type=last-prompt stub and CJK strings in the file are mojibake. (This part has been consistent in our experience.)
  4. Start a new session in the same project and edit a file the previous session had touched.
  5. Intermittently, the new session receives a "file was modified externally" notification whose diff is based on the dead session's stale snapshot — including content that exists nowhere on disk (in our case a fabricated instruction line) — or tool calls (Read) return corrupted/fabricated results until retried.

Note: step 5 is intermittent (depends on how the session died), but the jsonl corruption in step 3 reproduces consistently for us.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.183 (Claude Code) — output of claude --version today; both incidents were observed on the desktop app at v2.1.197 (2026-07-09 and 2026-07-12)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Why it matters: file-change notifications and tool results are supposed to be trusted system facts. When the client fabricates them from a dead session's corrupted state, the user and the model must forensically distinguish "client ghost" from "real external change or attack" — on unstable networks this happens routinely, and the 07-12 variant (fake security warning) actively pushes users toward harmful action (unnecessary credential rotation).

Environment details: Windows 11 Home, Traditional Chinese locale (system codepage cp950), working directory C:\知識庫\... (CJK path), desktop app, network behind VPN where mid-session disconnects are routine. Happy to provide sanitized excerpts of the corrupted transcript jsonl on request.

View original on GitHub ↗