[BUG] File viewer loses scroll position and selected file when switching sessions and back (Desktop, Code tab)

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?

What happens
In the desktop app's Code tab, the file viewer pane does not retain its state across a session switch. Open a file, scroll to a position in it, switch to another session in the sidebar, then switch back — the file viewer has lost where it was.

This is disruptive during review work: reading a long file while consulting a second session means re-locating the same position in the file on every return trip. With several sessions open and frequent switching, the re-scrolling dominates the actual work.

Steps to reproduce
Open the desktop app, Code tab, with at least two sessions in the sidebar.
In session A, open a long file in the file viewer (several hundred lines, so that scroll position is meaningful).
Scroll to a position well down the file — say line 400.
Click session B in the sidebar.
Click session A again.
Expected
Session A's file viewer is restored as it was: same file open, same scroll position, so work resumes where it left off. Per-session UI state persists alongside the per-session conversation and worktree.

Actual
The file viewer state is not restored. Position in the file is lost and has to be re-found manually.

Not a duplicate of the chat-scroll issues
This is specifically about the file viewer pane, not the conversation transcript. Existing reports such as #66272 ("Reopening a long chat-tab session scrolls to the first message; no jump-to-latest control") and #68977 concern chat history scrolling, and #66272 was closed as invalid. A search of open and closed issues found nothing covering the file viewer's own state across session switches.

The distinction matters because the desirable behaviour differs. For chat, "jump to latest" is arguably the right default. For a file viewer, there is no equivalent — the position you were reading is the only sensible place to return to, and it cannot be inferred.

Why this seems worth fixing
The desktop app's model is that each session is independent: its own conversation, its own git worktree, its own permission state. Per-session UI state is a natural part of that, and the sidebar invites frequent switching — the feature works against itself if switching is expensive.

Related state that may have the same underlying cause, if it helps scope the fix: which file is open, scroll position within it, cursor/selection position, and pane layout.

Workaround in use
Holding Cmd and clicking a second session opens it in a split pane, which avoids the switch entirely and so preserves both panes. This works but does not scale past two sessions and consumes screen width.

Environment
Claude Code 2.1.212
Desktop app, Code tab, local session
macOS 26.5.2 (build 25F84), Apple Silicon (arm64)

What Should Happen?

Session A's file viewer is restored as it was: same file open, same scroll position, so work resumes where it left off. Per-session UI state persists alongside the per-session conversation and worktree.

Error Messages/Logs

Steps to Reproduce

Open the desktop app, Code tab, with at least two sessions in the sidebar.
In session A, open a long file in the file viewer (several hundred lines, so that scroll position is meaningful).
Scroll to a position well down the file — say line 400.
Click session B in the sidebar.
Click session A again.

Claude Model

_No response_

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Code 2.1.212

Platform

AWS Bedrock

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_