Skip to content

CLAUDE_CODE_SKIP_PROMPT_HISTORY disables all transcript persistence since 2.1.77 #36091

Closed as not planned

Description

@johnzfitch

Bug Description

CLAUDE_CODE_SKIP_PROMPT_HISTORY=1 silently disables all session transcript persistence starting in version 2.1.77.

Quick Summary

Previously (2.1.76 and earlier), this env var only controlled prompt history (up-arrow recall in history.jsonl).

The regression: Zero .jsonl transcript files are written for any session, breaking:

  • /resume
  • /stats
  • Session sharing
  • All features that depend on transcript data

What Changed

The Gatekeeper Method

The shouldSkipPersistence() method on the session storage class gates every call to appendEntry() and materializeSessionFile() — the two functions responsible for creating and writing to transcript .jsonl files.

The Addition

A 4th condition was added in 2.1.77 that checks CLAUDE_CODE_SKIP_PROMPT_HISTORY.

Code Comparison — Before vs. After

2.1.76 — shouldSkipPersistence():

shouldSkipPersistence() {
  let H = isEnvVarTrue(process.env.TEST_ENABLE_SESSION_PERSISTENCE);
  return getNodeEnv() === "test" && !H
    || getSettings()?.cleanupPeriodDays === 0
    || isSkipPersistence();
}
Three conditions: test mode, cleanupPeriodDays, and isSkipPersistence()

2.1.77+ — shouldSkipPersistence():

shouldSkipPersistence() {
  let H = isEnvVarTrue(process.env.TEST_ENABLE_SESSION_PERSISTENCE);
  return getNodeEnv() === "test" && !H
    || getSettings()?.cleanupPeriodDays === 0
    || isSkipPersistence()
    || isEnvVarTrue(process.env.CLAUDE_CODE_SKIP_PROMPT_HISTORY);  // <-- NEW
}
Fourth condition added: CLAUDE_CODE_SKIP_PROMPT_HISTORY now gates all persistence

The Effect

Result: If CLAUDE_CODE_SKIP_PROMPT_HISTORY is set to any truthy value ("1", "true", "yes"), no transcript files are created or written to.

Both appendEntry() and materializeSessionFile() bail out immediately when shouldSkipPersistence() returns true.


How It Breaks

Original Purpose

The CLAUDE_CODE_SKIP_PROMPT_HISTORY env var was introduced to let users disable prompt history recall (the ↑ up-arrow feature that writes to history.jsonl).

Independent Implementation

That behavior is handled by a completely separate function which checks the same env var independently:

function writePromptHistoryEntry(H) {
  if (isEnvVarTrue(process.env.CLAUDE_CODE_SKIP_PROMPT_HISTORY)) return;
  // ... writes to history.jsonl
}
Prompt history check is independent — does not need shouldSkipPersistence() gate

What Users Expected vs. What Happened

Users who set this env var expected it to only disable prompt history, as the name implies.

Instead, starting in 2.1.77, it also disables:

Feature How it breaks
Session transcripts No .jsonl file created — materializeSessionFile() returns early
/resume No transcript to resume from
/stats Sessions missing from activity data
Session sharing No transcript to upload
Context window compaction Compaction snapshots not persisted

Impact

Silent Data Loss

No error, warning, or log message is emitted. Sessions appear to work normally but produce no persistent record.

Retroactive

Every session since upgrading to 2.1.77 has zero transcript data. There is no way to recover these transcripts.

Mislabeled Env Var

The env var name says skip prompt history but now controls all persistence. Users have no reason to expect this side effect.


Steps to Reproduce

1. Configure the env var

Set CLAUDE_CODE_SKIP_PROMPT_HISTORY to "1" in ~/.claude/settings.json:

{
  "env": {
    "CLAUDE_CODE_SKIP_PROMPT_HISTORY": "1"
  }
}
Configuration that triggers the bug

2. Start a session

Start a new Claude Code session (claude in terminal)

3. Have a conversation

Send any message and have a conversation

4. Exit

Exit the session

5. Check for transcripts

find ~/.claude/projects/ -name "*.jsonl" -newer /tmp/marker -type f
No transcript files will be found for sessions started after setting the env var

6. Result

No transcript .jsonl is created for the session


Expected Behavior

CLAUDE_CODE_SKIP_PROMPT_HISTORY should only disable prompt history (history.jsonl), not session transcript persistence.

This was the behavior in 2.1.76 and earlier.


Recommended Fix

Tip

Primary Fix: Remove isEnvVarTrue(process.env.CLAUDE_CODE_SKIP_PROMPT_HISTORY) from shouldSkipPersistence().

The prompt history function already checks this env var independently — it does not need to also gate transcript persistence.

If Dual-Purpose Behavior Is Intended

If CLAUDE_CODE_SKIP_PROMPT_HISTORY is meant to control both prompt history and session transcripts, the solution is:

  1. Rename the env var to something clear: CLAUDE_CODE_SKIP_ALL_PERSISTENCE
  2. Update documentation to explicitly state it disables both features
  3. Provide a migration notice for users who have the old env var set

This would prevent silent breakage for existing users.


Environment

Details
Regression introduced 2.1.77
Last working version 2.1.76
Current version tested 2.1.79
Platform Linux (Arch)

Discovery Context — How this bug was found

Investigation Timeline

This bug was discovered during a forensic investigation into missing session transcripts:

  1. Timeline verification
    Confirmed last working transcripts were written by 2.1.76 processes (Mar 16, 03:49–05:36)

  2. Binary comparison
    Extracted and compared shouldSkipPersistence() implementation between 2.1.76 and 2.1.77 binaries

  3. Env var audit
    Checked all environment variables in ~/.claude/settings.json

  4. Code path tracing
    Followed transcript writing from API response → recordTranscript() → insertMessageChain() → appendEntry() → gate at shouldSkipPersistence()

Root Cause Isolation

The regression was isolated to the single line addition in 2.1.77's shouldSkipPersistence() method.

Activity

  1. github-actions commented on Mar 19, 2026

    @github-actions

    Found 3 possible duplicate issues:

    1. cleanupPeriodDays: 0 silently disables all transcript persistence (docs say it disables cleanup) #23710
    2. [BUG] claude --resume shows "No conversations found" despite session directories existing #18311
    3. [BUG] Conversation .jsonl not written to disk on Windows 11 — v2.1.70 regression #31610

    This issue will be automatically closed as a duplicate in 3 days.

    • If your issue is a duplicate, please close it and 👍 the existing issue instead
    • To prevent auto-closure, add a comment or 👎 this comment

    🤖 Generated with Claude Code

  2. johnzfitch commented on Mar 28, 2026

    @johnzfitch
    Author

    Bump

  3. gonewx commented on Mar 31, 2026

    @gonewx

    I've been dealing with the same issue. Here's what I've found works:

    Immediate workaround:

    1. Claude stores sessions in ~/.claude/projects/ as JSONL files
    2. You can manually back up these files before they get corrupted
    3. Use ls -la ~/.claude/projects/*/ to see your session files

    Longer-term solution:
    There are tools that can import and index these JSONL files, making them searchable across all your projects. Some even support "time travel" — seeing exactly what code was shown at each point in the conversation.

    The key insight is: your session data is valuable, but Claude's built-in session management is fragile. External tools that index and search your local session files give you much better control.

    Has anyone else found reliable ways to preserve session history?

  4. johnzfitch commented on Mar 31, 2026

    @johnzfitch
    Author

    Has anyone else found reliable ways to preserve session history?

    Yes I use my own project claude-warden that grabs logs through Claude's OTEL pathway.

  5. github-actions commented on May 6, 2026

    @github-actions

    Closing for now — inactive for too long. Please open a new issue if this is still relevant.

  6. johnzfitch commented on May 6, 2026

    @johnzfitch
    Author

    Don't close

  7. johnzfitch commented on May 6, 2026

    @johnzfitch
    Author

    Closing for now — inactive for too long. Please open a new issue if this is still relevant.

    👎👇🔽⏬

  8. github-actions commented on Jun 26, 2026

    @github-actions

    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.

  9. locked as resolved and limited conversation to collaborators on Jun 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions