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

Open 💬 0 comments Opened Jul 10, 2026 by alexgetu

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)

  1. 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.

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

inherited the markers from the Node server.

  1. 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

Related

  • #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 ↗