[FEATURE] Option to disable cross-session command history in up-arrow

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

Technical note: ~/.claude/history.jsonl already stores sessionId per entry:

{"sessionId":"c6f463fa-76ba-405f-97a6-530a12dc32dc","display":"fix bug",...}
{"sessionId":"a1b2c3d4-0000-0000-0000-000000000000","display":"different session",...}

The data model already supports per-session history. The CLI just is not filtering by current sessionId when populating up-arrow results. Should be a straightforward fix—filter on read, not a schema change.

Additional context: --fork-session creates a new sessionId, but the forked session still sees the parent's history (and sibling sessions' history) via up-arrow. This defeats the purpose of forking for users running multiple concurrent sessions.

Confirmed on Linux, Claude CLI v2.1.19.

This is a recurring issue. Related tickets that have been closed as duplicates:

• #7702 - "Two Claude Code sessions in the same folder share chat history when they should be separate" (closed not_planned)
• #15630 - Same title as this issue (closed duplicate)
• #20064 - "Input history should be scoped to session, not shared across all sessions" (closed duplicate)
• #21465 - Privacy concern about URLs leaking across sessions (still open)

The core argument: The entire point of --fork-session is to create an independent branch. If I fork a session, I expect:

• ✅ Separate conversation context (this works)
• ❌ Separate input history (this is broken)

A fork that shares input history with its parent and siblings is not a true fork—it's a fork with entangled state. When I press up-arrow in a forked session, I should see that session's commands, not commands from the session I forked from or parallel sessions running in other terminals.

The fix is simple: The sessionId field already exists in history.jsonl. Just filter by it when populating readline history. This has been requested for months across multiple issues.

+1 for this

+1

+1

@claude propose a fix

Workaround: per-session history search via tmux + fzf

While waiting for a native fix, I built a small open-source tool that solves this:

claude-session-history — press prefix + H in tmux to search input history scoped to your current Claude Code session.

How it works:

• A SessionStart hook saves the session's start timestamp + project path to tmux env vars
• prefix + H triggers a script that matches the sessionId in ~/.claude/history.jsonl using those values
• Results are shown in a fzf popup — Enter copies to clipboard

Requirements: tmux, Python 3, fzf

git clone https://github.com/pjs7678/claude-session-history.git
cd claude-session-history && ./install.sh

Not a replacement for native per-session ↑ arrow, but it makes multi-session workflows usable today.

+1, this breaks running multiple sessions under screen or tmux

+1, I thought I was going mad running similar prompts in two sessions that seemed be doing the wrong things. FFS

+1 this is really annoying and seems like a simple fix.

The history file (~/.claude/history.jsonl) already stores a sessionId field per entry — the infrastructure to support this exists. Please ether change the default or add a setting (env var or settings.json option) to filter up-arrow history by the current sessionId instead of just by project directory.

This is urgently needed! It's chaos with multiple concurrent sessions!

Seeing this again today. And also getting permission prompts from one session in a different session.
Along with /clear deleting session history now, it seems like someone really fubared the session handling.

/clear has always done that (or at least, has since I started using claude). Got bit by that once, never used it again.

I use /clear, /rename, and /fork constantly to manage context. It's never done this for me before. At least for several months. I stay on 'stable', though.

Adding a more severe case: conversation context bleeding between concurrent sessions

I experienced a more serious variant of this issue that goes beyond up-arrow history mixing.

Setup: Two Claude Code chat windows open simultaneously in VS Code, same project directory.

What happened:

I opened Chat A fresh to work on a specific task (Raspberry Pi setup)
I opened Chat B separately to investigate an unrelated issue (project file path resolution), intentionally keeping it separate to avoid contaminating Chat A
After finishing work in Chat B and returning to Chat A, the model in Chat A had detailed knowledge of the conversation that happened in Chat B — including reasoning, decisions made, and the full conversation flow — without me ever sharing that information in Chat A
Chat A's visual history showed a clear gap (none of those messages appeared there), yet the model responded as if it had been present in Chat B's conversation the whole time

This is not just up-arrow history. The model's active context was contaminated with content from a parallel session. I deliberately isolated my investigation to Chat B to keep Chat A clean — that isolation was completely defeated.

This matches what @Reithan reported: "Also getting permission prompts from one session in a different session" — session boundaries are leaking at multiple levels.

Platform: macOS, VS Code extension, claude-code

+10
critical feature