[BUG] Interactive session inheriting CLAUDECODE/CLAUDE_CODE_* env vars silently skips ALL persistence (no JSONL, no history, no session registration)

Status Fixed / completed

Maintainer reply ✓ Yes — bcherny

Activity 3 comments · opened Jul 10, 2026 · closed Aug 16, 2026

💡 Likely answer: A maintainer (bcherny, collaborator) responded on this thread — see the highlighted reply below.

Summary

If an interactive claude is launched from a shell that has inherited another
session's environment markers (CLAUDECODE=1, CLAUDE_CODE_ENTRYPOINT,
CLAUDE_CODE_SESSION_ID, ...), the new session runs fully functional but leaves
zero traces on disk:

No <session-id>.jsonl is ever created under ~/.claude/projects/<project>/
No entries are written to ~/.claude/history.jsonl (not even slash commands)
No ~/.claude/sessions/<pid>.json registration is created
Only traces: a scratchpad dir under %TEMP%\claude\...\<session-id> and

lastSessionId/lastCost in .claude.json after exit

The user gets no warning. Everything appears normal. /export is the only way to
save the conversation.

Presumably this is the nested-session detection treating the process as a child
session (cf. #25803, where the same env check blocks subcommands). If so, a
top-level interactive session should not lose persistence just because a stale
CLAUDECODE=1 is sitting in the environment.

How this happened in the real world (non-exotic scenario)

A local helper tool (a Node.js web app that manages/resumes Claude Code

sessions) was restarted from inside a Claude Code session — so the Node
server inherited CLAUDECODE=1 etc.

The tool's "Resume" button spawns cmd /k "claude --resume <id>" — the cmd

inherited the markers from the Node server.

Every claude started in that cmd window (both --resume and plain claude)

ran in the no-persistence state described above. Two sessions were affected
before we noticed.

Any wrapper/launcher/IDE integration that is ever (re)started from within a Claude
session can poison every session it subsequently launches — silently.

Repro (observed on our machine; should be trivial to reproduce)

set CLAUDECODE=1
set CLAUDE_CODE_ENTRYPOINT=cli
set CLAUDE_CODE_SESSION_ID=00000000-0000-0000-0000-000000000000
claude
REM chat a bit, exit, then check:
REM   ~/.claude/projects/<project>/  -> no new .jsonl
REM   ~/.claude/history.jsonl        -> no new entries

Control experiments (same machine, same version, minutes apart)

| Launch context | Transcript written? |
|---|---|
| Interactive claude, clean terminal | ✅ yes (everything normal) |
| Interactive claude, terminal with inherited CLAUDECODE=1 etc. | ❌ nothing persisted (2/2 sessions) |
| Headless claude -p, same polluted environment | ✅ yes (JSONL created normally) |

Command lines were identical (claude.exe, no args); the only difference was the
inherited environment.

Expected behavior

A top-level interactive session should persist normally regardless of stale env

markers, or

If Claude Code decides a session is "nested" and will not persist it, it must

say so at startup — silent total data loss is the worst possible failure mode.

Environment

Claude Code v2.1.204, native Windows (cmd.exe), Windows 11 Pro (build 26200)
Team plan

#76267 — a different trigger (in-session /logout) producing the same silent

no-persistence state, found on the same machine during the same investigation.

View original on GitHub ↗

3 Comments

palguna26 · 2 months ago

This is exactly the kind of failure mode I’m building Termyte to handle.

Termyte is an open-source, local continuity layer for Claude Code, Codex, and OpenCode. It records agent activity independently of the tool’s own transcript persistence, including prompts, tool calls, commands, file changes, task state, decisions, failures, evidence, checkpoints, and handoffs.

Would you be open to testing the full Termyte workflow against this reproduction?

The useful test would be:

Start Termyte in a clean repository and run a normal Claude Code session to confirm activity is captured.
Launch Claude Code with the inherited CLAUDECODE and CLAUDE_CODE_* variables that trigger the no-persistence state.
Continue a real task, make file changes, record decisions, and exit the session.
Verify whether Termyte still retains the session activity, task state, evidence, and checkpoint despite Claude Code producing no JSONL or history entries.
Start a fresh Claude Code, Codex, or OpenCode session and check whether it can resume the unfinished task from Termyte without manually reconstructing what happened.

The project is local-first and open source: https://github.com/termyte-labs/termyte

This would be a valuable real-world test because the failure is silent. I’d especially appreciate blunt feedback on setup, capture reliability, missing events, and whether the resumed session actually understands the previous work.

bcherny collaborator · 1 month ago

Thanks for the detailed report. Two things going on here:

Since v2.1.172, nested-session detection no longer keys on CLAUDECODE / CLAUDE_CODE_SESSION_ID. It only looks at CLAUDE_CODE_CHILD_SESSION, which Claude Code sets in the shells it spawns itself. I tried your exact repro on the released 2.1.233 (macOS): CLAUDECODE=1 CLAUDE_CODE_ENTRYPOINT=cli CLAUDE_CODE_SESSION_ID=0000... claude — the transcript .jsonl and history.jsonl entries were written normally. In your real-world case the Node server restarted from inside a session most likely inherited CLAUDE_CODE_CHILD_SESSION=1 as well, which is what turned persistence off. That exclusion is intentional (it keeps nested verification sessions out of --resume, up-arrow history, and claude agents); CLAUDE_CODE_FORCE_SESSION_PERSISTENCE=1 overrides it. Docs: https://code.claude.com/docs/en/env-vars (see CLAUDE_CODE_CHILD_SESSION).

The silent part is fixed in v2.1.217: when session saving is off because of an inherited environment variable, the prompt now shows a pinned warning ("Transcript saving is off — inherited CLAUDE_CODE_CHILD_SESSION marker · restart with CLAUDE_CODE_FORCE_SESSION_PERSISTENCE=1 ..."). Verified on 2.1.233. Changelog: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md

Closing as fixed — please update and reply here if you still see silent no-persistence on a current version.

🤖 Generated with Claude Code

github-actions[bot] · 10 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.