[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
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:
/resumeshows 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
- Launch
claude(any of the three versions above), in any entrypoint - Send any message, e.g.
hello - Exit (Ctrl-D)
- 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.jsonhas no history/save/sync/telem keys) CLAUDE_CODE_SKIP_PROMPT_HISTORY=1env 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:
- Restore local
.jsonlwrite for CLI sessions (recommended), or - Provide a documented, user-controllable option to enable local persistence, or
- Ensure
teleported-fromsessions 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:
/resumecan list and restore past sessions- The VSCode extension's Session History panel shows my past chats
- Reloading the VSCode window does not lose the current conversation
- 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
- Install Claude Code CLI (verified on versions 2.1.113, 2.1.114, and 2.1.227).
- 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
- Start a new session and send a message, e.g.:
> hello
Wait for the assistant reply.
- Optionally send a second message to confirm the session is active:
> this is a test
- 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_
3 Comments
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 withCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1andDISABLE_TELEMETRY=1. In every case the~/.claude/projects/<project>/<sessionId>.jsonlcontained 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 inheritsCLAUDE_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=1overrides 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-varsCould 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)'(andtmux show-environment -g | grep CLAUDE) show anything? (3) if neither, please attach one of the metadata-only.jsonlfiles (redacted is fine). That will tell us whether this is the known environment-inheritance case or something new.🤖 Generated with Claude Code
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.
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.