›_ Claude Code Issues
Claude Code Issues / #98347

[BUG] Code tab (SSH-host sessions): previous chats show empty after restart, despite intact session data on host

Status Open
Reported on v2.1.284
Maintainer reply ✓ Yes — amorriscode
Activity 3 comments · opened Sep 30, 2026
💡 Likely answer: A maintainer (amorriscode, contributor) responded on this thread — see the highlighted reply below.

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?

Summary

Previously working chat sessions in the Code tab appear completely empty when reopened, even after fully quitting and relaunching the desktop app (Cmd-Q + reopen). This has happened repeatedly ("mal wieder" / recurring), most recently overnight between one day and the next.

Environment

  • Claude Code Desktop app, Code tab
  • App version (from session metadata): 2.1.284
  • Session type: SSH-host sessions (sessions run on a remote host via SSH, not locally on the Mac)
  • Client: macOS (MacBook Pro)
  • Host: Linux (QNAP NAS, Container Station)

What I verified before filing (so this shouldn't need back-and-forth)

  1. Session transcript files on the SSH host are fully intact. Checked directly on disk under ~/.claude/projects/<project-hash>/*.jsonl. Example: one session's file is 33 MB / 9,465 lines of valid JSONL transcript data, ending in a well-formed final line with correct sessionId/timestamp/cwd metadata.
  2. None of the affected sessions are archived. auto_archive_inactive_days is set to 0 (never), auto_archive_on_pr_close is off. Checked 7 sessions total, all isArchived: false.
  3. The backend's own session-listing (available to Claude via the ccd_session_mgmt tool) returns correct, complete metadata for all 7 sessions (titles, cwd, last activity timestamps ranging from several days ago to same-day) — so the data is reachable and parseable from at least one code path.
  4. The .claude.json state file on the host is intact (54 KB, consistent size across recent auto-backups in ~/.claude/backups/), though it doesn't appear to store session content itself (only caches/feature flags), so it's likely not relevant to this bug.
  5. A full app restart (Cmd-Q, then reopen) did not resolve the issue — chats still show empty afterward.

Expected behavior

Reopening a previous session in the Code tab should load and display its full message history, matching what's actually stored in the session's .jsonl file on the SSH host.

Actual behavior

The session opens but shows no messages / appears empty, despite the underlying data being present and complete on the host.

Suspected area

Given the data is confirmed intact on the host and reachable via at least one backend code path, this looks like a client-side (desktop app) issue with loading/rendering session history for SSH-host sessions — possibly related to session file size (largest affected files are in the 11–33 MB range) or a stale/failed resync after the client was offline (e.g. Mac asleep overnight, SSH connection dropped).

Happy to provide the specific session UUIDs / more diagnostic detail if useful.

What Should Happen?

Reopening a previous session in the Code tab should load and display its full message history, matching what's actually stored in the session's .jsonl file on the SSH host.

Error Messages/Logs

Steps to Reproduce

  1. Use the Code tab desktop app with a session running on an SSH host (not local) for regular work over several days
  2. Leave the app running/idle overnight (Mac goes to sleep / network changes)
  3. Reopen the app the next morning
  4. Click into a previously active chat session in the sidebar
  5. Observed: the session shows as empty (no message history), even though the underlying .jsonl transcript file on the SSH host is confirmed intact and complete
  6. Fully quit the app (Cmd-Q) and reopen it
  7. Observed: sessions still show empty — restart does not resolve it

Note: I don't have a 100%-reliable single-action repro (e.g. a specific click that always triggers it) — this is the pattern that has preceded it happening, on a recurring basis over several days/sessions.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.284

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Diagnostic checks done before filing (so this hopefully doesn't need back-and-forth):

  1. Session transcript files on the SSH host (QNAP NAS) are fully intact — checked directly on disk under ~/.claude/projects/<project-hash>/*.jsonl. Example: one affected session's file is 33 MB / 9,465 lines of valid JSONL, ending in a well-formed final line with correct sessionId/timestamp/cwd metadata.
  2. None of the affected sessions are archived (auto_archive_inactive_days = 0/"never", auto_archive_on_pr_close = off). Checked 7 sessions, all isArchived: false.
  3. The app's own session-listing returns correct, complete metadata (titles, cwd, last-activity timestamps) for all 7 sessions — so the data is reachable via at least one code path.
  4. Affected session files range from ~470 KB to ~33 MB — the larger ones (11–33 MB) are the ones most consistently affected, which may be relevant (possible timeout/size-related loading issue).
  5. This is recurring, not a one-off — happened before with the same pattern (works fine during active use, appears empty after being away/overnight).

Environment: client is macOS (MacBook Pro), session backend is a Linux host (QNAP NAS) reached via SSH — this is a "Code tab, SSH-host session" setup, not a local-only session.

Happy to provide the specific session UUIDs or run further diagnostics on the host side if useful.

View original on GitHub ↗

3 Comments

pixolli · 14 days ago

From the remote-connection daemon log on the SSH host (~/.claude/remote/run/<id>/remote-server.log), covering the relevant overnight window:

2026/09/29 22:55:05 [Server] Connection closed: @
2026/09/29 22:55:28 [Server] New connection from: @
(this connection then stayed open with no further log activity for ~10 hours)
2026/09/30 09:03:00 [Server] Connection closed: @
2026/09/30 09:04:34 [Server] New connection from: @
2026/09/30 09:04:34 [Server] Connection closed: @
2026/09/30 09:04:34 [Server] New connection from: @

So a single connection was held open from 22:55 the previous night until 09:03 the next morning (~10h), then closed, followed by a rapid open/close/open right around the time I started using the app again that morning — consistent with a stale/zombie connection over the Mac's sleep period that wasn't detected until active use resumed.

Separately, from an earlier occurrence of the same issue (2026-09-23), the same log shows an explicit write failure that looks like the underlying failure mode:

2026/09/23 03:22:47 [Server] writeResponse: wrote 0/632 bytes, error=write unix /share/homes/Pixolli/.claude/remote/run/<id>/rpc.sock->@: use of closed network connection
2026/09/23 03:22:47 [Server] Failed to write response: write unix /share/homes/Pixolli/.claude/remote/run/<id>/rpc.sock->@: use of closed network connection

This suggests that when the client reconnects after being away, the daemon can attempt to write a response (e.g. session history) over a connection that's already closed on its end, which would produce exactly this symptom — the app opens a session but the response never arrives, so it renders empty.

amorriscode contributor · 6 days ago

Thanks for the careful report: the checks on the host rule out a lot. The history you see in the Code tab is drawn from a copy of each transcript that the app keeps on your Mac, so the Mac's side is what we need next. Four quick things, the first matters most:

  1. On the Mac: ls -la ~/.claude/projects/ssh-*/ . Is there a folder for each affected session (named ssh- plus the session's id, the .jsonl's name on the host), and how big is the .jsonl inside it?
  2. When a session opens blank, what does the pane say: "No messages yet", or "Couldn't load this conversation" with a Retry?
  3. From the Mac's terminal, in one line, with your host's name: ssh <host> 'find -L ~/.claude/projects -name "*.jsonl" -print -quit; echo exit=$?' . What does it print?
  4. Which version does Claude > About Claude show today? A fix for one way this can happen went out in 2.26454.0 on Oct 6. It stops new cases; it does not bring back sessions that were already blank. Do sessions started since that update still go blank?
pixolli · 5 days ago

Hi there,

thanks for the quick follow up: Here are the answers

Subject: Blank SSH sessions (“No messages yet”) after restart — data intact on host, likely find -quit on BusyBox

Environment

Claude for Mac 2.31226.0 (eb794d), 8 Oct 2026, 07:55 — newer than the 2.26454.0 fix.
Remote host over SSH: QNAP TVS-1282T (model TS-X82), QTS 5.2.10 (build 20260731), Linux 5.10.60-qnap. Login shell of the SSH user is /bin/sh.
Answers to your four questions

There is no ~/.claude/projects/ folder on the Mac at all, so no ssh-* folders. ~/.claude/sessionsexists but is empty (modified 9 Oct 02:11).
A blank session shows “No messages yet” (not “Couldn’t load this conversation” with Retry).
Your command fails on my host:
ssh <user>@<NAS-IP> 'find -L ~/.claude/projects -name "*.jsonl" -print -quit; echo exit=$?'
prints find: unrecognized: -quit and exit=1. Cause: find over SSH is /usr/bin/find, a BusyBox v1.24.1 applet (build 31 Jul 2026) without -quit. The non-interactive SSH PATH is only /usr/bin:/bin:/usr/sbin:/sbin.
Version is 2.31226.0 (above). Sessions started after the update do go blank — see the reproduction below.
Reproduction on 2.31226.0
I started a brand-new SSH test session today, wrote a short message and got a reply. The chat displayed correctly while switching between sessions. After quitting and relaunching the app, that test session shows “No messages yet”.

Host side
All 8 transcripts (plus the new test session one) are intact in ~/.claude/projects/-share-CACHEDEV1-DATA-PS-Container-Station-ps-homelab/*.jsonl (the largest is 157 MB, the current session; the others range from 0.5 to 33 MB). The test transcript is unchanged after the restart: 52aad418-e3a2-4060-bc09-a343f6956e7e.jsonl, 455,694 bytes, 33 entries, last written 09:57. So the data is written correctly and only the reload after a restart fails.

Question
Could the app’s session detection or reload use the same find ... -quit call over SSH, so it finds nothing on this host and shows “No messages yet”? If so, is there a workaround for hosts with BusyBox find, or will you make the check independent of -quit? I’d rather not replace system binaries on the NAS.

Hope that helps,

Best Regards,

Oliver

oliverkremer | Dipl.-Ing. | @. @.> | festnetz: +49 6474 881426 | mobil: +49 15201902074 | Am Falkenstein 23 | 65606 Villmar | Germany

Am 09.10.2026 um 00:47 schrieb Anthony Morris @.***>: amorriscode left a comment (anthropics/claude-code#98347) <https://github.com/anthropics/claude-code/issues/98347#issuecomment-6070568370> Thanks for the careful report: the checks on the host rule out a lot. The history you see in the Code tab is drawn from a copy of each transcript that the app keeps on your Mac, so the Mac's side is what we need next. Four quick things, the first matters most: On the Mac: ls -la ~/.claude/projects/ssh-/ . Is there a folder for each affected session (named ssh- plus the session's id, the .jsonl's name on the host), and how big is the .jsonl inside it? When a session opens blank, what does the pane say: "No messages yet", or "Couldn't load this conversation" with a Retry? From the Mac's terminal, in one line, with your host's name: ssh 'find -L ~/.claude/projects -name ".jsonl" -print -quit; echo exit=$?' . What does it print? Which version does Claude > About Claude show today? A fix for one way this can happen went out in 2.26454.0 on Oct 6. It stops new cases; it does not bring back sessions that were already blank. Do sessions started since that update still go blank? — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/98347?email_source=notifications&email_token=CQC7KFSQSX2SC22VW3TFHRL5TAKPBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMBXGA2TMOBTG4YKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-6070568370>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CQC7KFXRTAQK7NTWZEDFEL35TAKPBAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TKNRUGI3DKMRWG442C5QC>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CQC7KFV2OPARZWRU6HJG3R35TAKPBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMBXGA2TMOBTG4YKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/CQC7KFS2XFHX2U3Y74ZP4JL5TAKPBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMBXGA2TMOBTG4YKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Browse all Claude Code issue topics →