[BUG] Desktop app: after auto-update stealth-relaunch, the conversation view rewinds — navigation history is saved with a stale `active` index

[!WARNING] The version attribution in this comment is withdrawn. See the correction below: the fallback point predates the update, so I no longer have evidence that 1.32352.0 introduced this. The observations about the symptom itself still stand.

---

Update: this is a regression in 1.32352.0, and it is worse than first reported

After several more restarts today I can narrow this down considerably. Correcting my original report: the rewind is not limited to the stealth-relaunch path, and it is not pre-existing behaviour.

It started with 1.32352.0

Every restart on 1.32352.x lost conversation view state. No restart before that did — I had been updating and restarting normally for weeks without ever losing a conversation.

2026-08-18 08:53  start   1.30096.5     fine
2026-08-18 09:50  update  -> 1.32352.0  view lost from this point on
2026-08-18 10:45  start   1.32352.0     lost again
2026-08-18 15:55  update  -> 1.32352.1  lost again
2026-08-18 17:33  start   1.32352.1     lost again (manual restart)

Earlier update-restarts on this machine (1.26832.0 -> 1.28929.0 on 08-12, -> 1.30096.1 on 08-14, -> 1.30096.5 on 08-15) did not lose anything. 4/4 reproduction on 1.32352.x, 0/3 before it.

Exact symptom

One long session was open across the 1.32352.0 update. Since then:

• Messages up to a fixed point (roughly where the app updated) still render after every restart.
• Everything after that point disappears from the view on every restart, always returning to the same place.
• The session still works — new messages send and render fine, and the model retains full context.
• Switching to another session and back loses nothing further, but does not recover what disappeared.

The data is intact; only the view is affected

• The CLI transcript is complete and valid: 1,702 lines, 7.1 MB, every line parses as JSON, no truncation.
• claude -r <session-id> from a terminal renders the full history correctly.
• Session size is not a factor: 24 of my 46 sessions are larger than this one (largest is 105 MB) and they are unaffected.

Other sessions are fine, which narrows it down

Opening any pre-update session from the sidebar renders its full history normally on 1.32352.1. So the load-from-disk path works. It appears not to run for the session that was live across the restart: the app keeps the same internal session id across restarts (Mapping internal session local_<uuid> to CLI session <cli-uuid> with an unchanged local_ id since before the restart), so that session seems to be treated as already loaded while its in-memory messages are gone.

Manual restart vs stealth relaunch

The two paths differ, and the manual one is worse:

• Update relaunch logs [stealth-relaunch] Saved navigation history (N entries, active=M) and Restoring navigation, and lands on a stale entry.
• A user-initiated quit and reopen logs no stealth-relaunch lines at all, so nothing is restored.

Ruled out

• Disk layout: all Claude paths (~/.claude, ~/Library/Application Support/Claude, ~/Library/Logs/Claude, /Applications/Claude.app) are real directories on the internal volume, no symlinks.
• Session size (see above).
• Transcript corruption (see above).
• The per-session file under Application Support/Claude/claude-code-sessions/.../local_<uuid>.json holds metadata only (281 KB, no message content), so it is not a truncated message store.

Environment

• Claude desktop 1.32352.1 (regression introduced in 1.32352.0; 1.30096.5 was fine)
• Claude Code 2.1.229
• macOS 26.5 (25F71), Apple Silicon, 32 GB RAM

Correction: withdrawing the "regression in 1.32352.0" claim

My previous comment asserted this was introduced in 1.32352.0. I no longer have the evidence to support that, so I am withdrawing it. Sorry for the noise — please disregard the version attribution while triaging.

Why I withdrew it

I located the exact point the view falls back to. It is line 219 of a 1,702-line transcript, timestamped 2026-08-17T08:39:28Z — the day before the update to 1.32352.0.

2026-08-17 17:11 JST  session created (app on 1.30096.5)
2026-08-17 17:39 JST  <- the view never shows anything past this point
2026-08-17 20:09 JST  app quit
2026-08-18 08:53 JST  app start (still 1.30096.5)
2026-08-18 09:50 JST  update -> 1.32352.0

There is no restart, quit, or update at 17:39 on 08-17. So the cut-off does not line up with the version change, and the persisted view state may already have stopped advancing while the app was still on 1.30096.5. I had inferred the regression from the fact that I first noticed the loss right after the update; that is not the same as it starting there.

I could not determine the mechanism. The cut-off is at 1.52 MB / 219 lines into the transcript, which does not match any obvious cap.

What is still established

These are direct observations and I am confident in them:

• The transcript is intact. 1,702 lines, 7.1 MB, every line parses as JSON. claude -r <session-id> from a terminal renders the full history correctly. Only the in-app view is affected.
• The affected session always falls back to the same point on every restart — both update relaunches and user-initiated quit/reopen. New messages send and render fine, and the model retains full context; only the scrollback above the cut-off is missing.
• Newly created sessions are not affected. I created two new sessions after the update, restarted the app, and both retained their content in full.
• Pre-existing sessions are not affected. Opening any other session from the sidebar renders its full history normally, so the load-from-disk path works.
• Session size is not the factor. 24 of my 46 sessions are larger than the affected one (largest 105 MB) and are fine.
• Not a disk-layout issue. All Claude paths are real directories on the internal volume, no symlinks.
• The per-session file under Application Support/Claude/claude-code-sessions/.../local_<uuid>.json is metadata only (281 KB, no message content), so it is not a truncated message store.

Manual restart vs stealth relaunch

Still worth noting, since the two paths behave differently:

• An update relaunch logs [stealth-relaunch] Saved navigation history (N entries, active=M) followed by Restoring navigation.
• A user-initiated quit and reopen logs no stealth-relaunch lines at all.

Across restarts the app keeps the same internal session id (Mapping internal session local_<uuid> to CLI session <cli-uuid> with an unchanged local_ id), which may be why the affected session is never re-read from disk while other sessions are.

Environment

• Claude desktop 1.32352.1 (the session was created on 1.30096.5 and spanned the update)
• Claude Code 2.1.229
• macOS 26.5 (25F71), Apple Silicon, 32 GB RAM

I hit the same fallback on my main conversation and assumed it had either reached some
invisible limit or gotten corrupted, so 4 days ago I created a fresh one and moved my
work there. That new session has now done exactly the same thing: this morning, after
an app update, the rendered view fell back to a message from 3 days ago, even though I
was still working in it right before the update.

If your two test sessions haven't been through an update yet, they may not be a
negative result so much as a test still pending — worth re-checking them after the
next one.

Same signature as yours: the model still recalls the messages above the cut-off when I
ask it explicitly, new messages send and render fine, only the scrollback is gone. So
on this machine it has happened to two independent sessions, one of them created from
scratch.

Environment: Claude 1.32352.1 (6c6aa5) / MacOS Golden Gate 27.0 Developer Beta 6 / Apple M1 Pro

I found the root cause on my machine. It is not the auto-update — it is a Unicode normalization mismatch that splits one working directory into two different project keys under ~/.claude/projects/.

Root cause

~/.claude/projects/ derives a directory key from the cwd by replacing every non-alphanumeric character with -. On my machine the same folder produces two keys, because the path is normalized differently depending on the code path:

A (NFC): -Users-kishi--------getskishi-gmail-com-------------      mode 755  <- written to (live)
B (NFD): -Users-kishi--------getskishi-gmail-com---------------    mode 700  <- what the view falls back to

My cwd is /Users/kishi/マイドライブ（getskishi@gmail.com）/ゲッツ!!業務フォルダ. The two extra dashes come from the last path segment: ゲ decomposes to ケ+゛ and ダ to タ+゛ under NFD, so two characters become four. Note that only the last segment differs — the parent segment is NFC in both keys (pure NFD would have widened it too), so the two keys are produced by different normalization of different parts of the path.

Each session exists as a JSONL file in both directories. The copy in B stops being appended to shortly after the session starts; A keeps growing.

Evidence

The fallback point matches B's last write exactly, for both sessions:

| session | A (live) | B (stale) |
|---|---|---|
| 2ee53120-… | 1,817 lines, last write 2026-08-18 18:08 | 220 lines, last write 2026-08-17 17:39:28 |
| 01e50348-… | 71 lines, last write 2026-08-19 08:47 | 11 lines, last write 2026-08-18 17:57:35 |

The first session always falls back to 17:39. The second always falls back to its first exchange at 17:57. Both are exactly where the B copy stops.

This also explains the rest of the signature: the data is never lost (A is intact), claude -r <session-id> shows everything, the model still recalls messages above the cut-off, and new messages send and render fine.

Confirmed by intervention. I replaced the two stale files in B with symlinks to their counterparts in A, restarted, and the full scrollback came back in both sessions. So the renderer is definitely reading the B key while the writer appends to the A key.

Corrections to earlier hypotheses in this thread

• It is not the auto-update. I reproduced it with a manual restart while v1.32885.1 was still sitting un-applied in the "Restart to update" button. A plain relaunch — i.e. re-reading the session — is sufficient.
• It is not limited to old sessions. @UzanRuben was right that an un-updated session is a pending test rather than a negative result. My freshly created session broke on its first restart.
• It is not version-related. Earlier versions on my machine behaved the same.

Trigger condition

Paths containing characters that differ between NFC and NFD — for me, Japanese folder names with dakuten/handakuten. On the same machine:

| path | duplicated? |
|---|---|
| …/ゲッツ!!業務フォルダ | yes (A 1,903 lines / B 231 lines) |
| …/ゲッツ!!業務フォルダ/GETS-WEB | yes (A 9,410 lines / B 9,036 lines) |
| ~/app_development/… (ASCII) | no |
| ~/Documents/… (ASCII) | no |

All 45 of my other sessions, all under ASCII paths, are unaffected. This probably explains why the report count is low: it needs a non-ASCII cwd with decomposable characters.

Detection

cd ~/.claude/projects && python3 -c "
import os,glob
from collections import defaultdict
b=os.path.expanduser('~/.claude/projects/')
g=defaultdict(list)
for d in os.listdir(b):
    if os.path.isdir(b+d): g[d.replace('-','')].append(d)
for k,v in g.items():
    if len(v)>1:
        for d in sorted(v,key=len):
            n=sum(sum(1 for _ in open(f,errors='replace')) for f in glob.glob(b+d+'/*.jsonl'))
            print(f'{len(d):3d} {oct(os.stat(b+d).st_mode)[-3:]} {n:6d} lines {d}')
"

Any pair printed under one group is the same folder split in two.

One more thing worth checking on the fix

In one of my two duplicated projects, the B side holds two sessions that do not exist in A at all (1,389 and 1,173 lines). So the split is not always "live copy plus stale shadow" — some conversations may live only under the key that is currently not being written to. A fix that simply prefers one key will need to merge rather than discard.

Suggested fix

Normalize the path to a single form (NFC) before deriving the project key, and on startup merge any existing keys that are normalization variants of each other.

Environment: macOS 26.5 (build 25F71, Darwin 25.5.0) / Apple Silicon / cwd on Google Drive.