[BUG] CLI does not persist conversation to local .jsonl in 2.1.113/2.1.114/2.1.227; /resume shows empty; cloud history also missing

Status Fixed / completed
Reported on v2.1.113
Maintainer reply ✓ Yes — bcherny
Activity 3 comments · opened Aug 11, 2026 · closed Aug 17, 2026
💡 Likely answer: A maintainer (bcherny, collaborator) 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

Claude Code CLI (verified on 2.1.113, 2.1.114, 2.1.227) no longer writes conversation content to local ~/.claude/projects/<project>/<sessionId>.jsonl. Only metadata is written. As a result:

  • /resume shows an empty list
  • Session history in the VSCode extension is empty
  • Reloading the VSCode window loses the current chat with no way to recover
  • Cloud-side (claude.ai/code) also has no record of these sessions

This appears to be a regression or intentional behavior change with no user-facing configuration to opt out.

Environment

  • OS: Linux (RHEL 9.8, kernel 5.14) — HPC login node
  • Shell: bash
  • Claude Code versions tested (all affected): 2.1.113, 2.1.114, 2.1.227
  • Entrypoints tested (all affected): claude-vscode (extension), cli (VSCode integrated terminal), cli (independent SSH)
  • Account: Claude Pro

Reproduction

  1. Launch claude (any of the three versions above), in any entrypoint
  2. Send any message, e.g. hello
  3. Exit (Ctrl-D)
  4. Inspect ~/.claude/projects/<encoded-cwd>/

Expected: A .jsonl file named <sessionId>.jsonl containing user + assistant messages.

Actual: No .jsonl for the new session ID. Only pre-existing files are present, and they contain only pointer metadata:

{"type":"teleported-from","remoteSessionId":"session_01QWrUrzERK82QrU3Ga6z4f9","messageCount":0}

or

{"type":"ai-title","sessionId":"...","aiTitle":"..."}

~/.claude/sessions/<pid>.json contains only process metadata (pid/cwd/version/entrypoint), no messages.

Diagnostics performed

Ruled out:

  • Disk full / quota (2.2T free, 32G quota remaining)
  • Directory permissions (verified writable)
  • Corrupted config (~/.claude.json has no history/save/sync/telem keys)
  • CLAUDE_CODE_SKIP_PROMPT_HISTORY=1 env var — present when spawned from VSCode extension/Desktop, but absent in independent SSH; behavior is identical
  • Version regression — three consecutive versions affected

Confirmed via a second user on the same HPC cluster using Claude Desktop (entrypoint=claude-desktop, version 2.1.219): same env vars injected, same non-persistence.

Expected fix

Either:

  1. Restore local .jsonl write for CLI sessions (recommended), or
  2. Provide a documented, user-controllable option to enable local persistence, or
  3. Ensure teleported-from sessions are actually retrievable from cloud with a documented way to list/restore them

What Should Happen?

When I use claude CLI to have a conversation, the messages should be written to ~/.claude/projects/<encoded-cwd>/<sessionId>.jsonl so that:

  1. /resume can list and restore past sessions
  2. The VSCode extension's Session History panel shows my past chats
  3. Reloading the VSCode window does not lose the current conversation
  4. I have a local record I can inspect, back up, or feed to other tools

Currently on 2.1.113 / 2.1.114 / 2.1.227, no .jsonl with actual message content is ever written (only pointer/metadata files with messageCount: 0), regardless of entrypoint (VSCode extension, VSCode integrated terminal, or independent SSH). This makes local session recovery impossible.

Error Messages/Logs

Steps to Reproduce

  1. Install Claude Code CLI (verified on versions 2.1.113, 2.1.114, and 2.1.227).
  1. Open a shell (any of these entrypoints all reproduce the bug):
  • VSCode extension chat panel
  • VSCode integrated terminal running claude
  • Independent SSH session running claude
  1. Start a new session and send a message, e.g.:

> hello

Wait for the assistant reply.

  1. Optionally send a second message to confirm the session is active:

> this is a test

  1. Exit the CLI (Ctrl-D or /exit). Note the sessionId shown in ~/.claude/sessions/<pid>.json, e.g.:

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.114 (Claude Code) Also reproduced on: 2.1.113 (Claude Code) and 2.1.227 (Claude Code)

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_

View original on GitHub ↗

3 Comments

bcherny collaborator · 2 months ago

Thanks for the detailed report. I tried to reproduce this on 2.1.233 on Linux with a fresh CLAUDE_CONFIG_DIR: claude -p "say hi", plus an interactive session in tmux with two prompts, and a run with CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 and DISABLE_TELEMETRY=1. In every case the ~/.claude/projects/<project>/<sessionId>.jsonl contained the full user/assistant messages and the session was resumable — so I can't reproduce a general loss of persistence.

What your symptoms do match is a documented mechanism: Claude Code skips transcript saving when it inherits CLAUDE_CODE_SKIP_PROMPT_HISTORY, or when an interactive session inherits CLAUDE_CODE_CHILD_SESSION (set in subprocesses Claude Code spawns — it can leak through a long-lived tmux/screen server or launcher that was first started from inside a Claude session, and corporate wrapper scripts can also export these). On your older versions this loss was silent; since 2.1.217 the session shows a "Transcript saving is off" warning above the prompt, and since 2.1.178 the common tmux leak is detected and ignored automatically. CLAUDE_CODE_FORCE_SESSION_PERSISTENCE=1 overrides the inherited marker — it's a client-side environment issue, not a server-side gate. Docs: https://code.claude.com/docs/en/errors and https://code.claude.com/docs/en/env-vars

Could you check on 2.1.227+: (1) does the warning banner appear above the prompt? (2) in the exact shell/tmux pane where you run claude, does printenv | grep -E 'CLAUDE_CODE_(CHILD_SESSION|SKIP_PROMPT_HISTORY)' (and tmux show-environment -g | grep CLAUDE) show anything? (3) if neither, please attach one of the metadata-only .jsonl files (redacted is fine). That will tell us whether this is the known environment-inheritance case or something new.

🤖 Generated with Claude Code

github-actions[bot] · 2 months ago

We weren't able to reproduce this. Could you provide steps to trigger the issue — what you ran, what happened, and what you expected? This issue will be closed automatically if there's no activity within 7 days.

github-actions[bot] · 9 days ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.