[FEATURE] Sync conversation history between CLI and Claude Code desktop app

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/15881
2. https://github.com/anthropics/claude-code/issues/21744
3. https://github.com/anthropics/claude-code/issues/15542

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

This is one of the most frequently hit friction points with Claude Code — the CLI and Desktop contexts are completely siloed, so work done in one is invisible in the other.

The underlying issue is there's no shared session identity layer between the two surfaces. The JSONL files exist on disk, but without a unified index that tracks sessions across both environments, you're left doing manual reconciliation.

I've been using Mantra (mantra.gonewx.com) as a cross-surface persistence layer for exactly this — it maintains a unified session timeline that works across Claude Code CLI, Cursor, and Gemini CLI, so you get a single view of all sessions regardless of which tool created them. The 'sync between CLI and Desktop' problem effectively disappears because the canonical record lives outside both.

Would be great to see this solved natively at the session ID level, but until then, a cross-surface aggregation layer is the only reliable workaround I've found.

Being able to seamlessly move between CLI and desktop app would be incredible. Right now the two feel like separate islands.

For what it's worth, claude-brain at least solves the config continuity piece — your settings, skills, and CLAUDE.md stay in sync across environments via git hooks. Conversation history sync would need native support from Anthropic, but having consistent config across both surfaces is a good start.

Do it!!!

In the new desktop app the local conversations show up briefly then disappear again:
https://www.loom.com/share/fb220281fe4c491799d8741f37e30b8b

Please enumerate the local CLI sessions from ~/.claude/projects directly. This would have massive benefit for containerised sandboxed conversations that share a common .claude directory between host and the container.

+1

For me, on Win10, desktop app code chats appear in the CC CLI (but not vice versa).

+1
On Win10, CC CLI projects/sessions don't appear in CC Desktop, would be super useful to have this

+1

+1, please add this feature

I just realized that this started working for me after i signed out and back in to my claude desktop app

+1 need this feature

+1

As an Enterprise user who uses both Claude Code CLI and the desktop app, the lack of shared session history between the two creates real friction. I prefer working in the desktop but the cli has its own advantages and i end up switching between the two. Sometimes I am forced to switch from desktop app to cli because the desktop app would simply not respond. If i forget to start conversation in the desktop app then i have to stay in cli for that problem. the remote control feature does give me a workaround but two way syncing would immensely help

O mundo todo está esperando por isso

+1

+1

As a temp workaround, I created this (vibe coded) script.

How it works:

CLI sessions (~/.claude/projects/) and Desktop app sessions are stored separately and don't sync automatically. This script bridges that gap by creating Desktop-compatible metadata entries that point to your existing CLI session files — no data is copied or duplicated.

1. Scans ~/.claude/projects/ for CLI session JSONL files
2. For each session, reads the title, model, timestamps, and working directory
3. Writes a local_<uuid>.json metadata file into ~/Library/Application Support/Claude/claude-code-sessions/ — the same format the Desktop app uses for its own sessions
4. On next restart, the Desktop app picks them up and displays them in the sidebar, where you can read history and continue the conversation

Download & run:

  # Download
  curl -o ~/sync-cc-sessions https://gist.githubusercontent.com/harryi3t/ea591e5bd510f5fd5f6c4f7b4d6f1567/raw/sync-cc-sessions
  chmod +x ~/sync-cc-sessions

  # Sync last 7 days (default), then restart Desktop app
  ~/sync-cc-sessions

  # Options
  ~/sync-cc-sessions -d 30      # last 30 days
  ~/sync-cc-sessions -d all     # everything
  ~/sync-cc-sessions --dry-run  # preview without writing

+1

+1

Open the Claude Desktop App & tell it you want all your local chats in the sidebar with project or repowise grouping, and it will do it for you. I have done it for myself using Opus 4.8 (effort max, bypass permissions mode). Hope it solves your issue.

+1

Adding a concrete SSH scenario: with Claude Desktop connected to a remote host via the built-in SSH environment feature, sessions created directly on that same remote host (plain terminal claude, or claude remote-control) never show up in Desktop's SSH session list — even after restarting Desktop and reselecting the connection.

From a quick look at both sides' ~/.claude directories, these seem to be three separate mechanisms with no shared discovery: Desktop's SSH sessions are stored locally on the client machine, plain terminal sessions live on the remote host keyed by working directory, and remote-control sessions have their own registry on the remote host. The JSONL format looks the same across all three, so it seems like a discovery gap rather than a format incompatibility — worth a look if someone wants to dig in further.

New:
<img width="968" height="574" alt="Image" src="https://github.com/user-attachments/assets/9b0462f6-a0d5-43d8-af19-bdd8320abc82" />

When this is resolved, it should be an opt-in feature. There are some random benefits to siloing history like technically it's more organized and easier to look through than a shared history, particularly since I make general requests on the app and just use Claude code in the CLI.

Beyond this, as a user I would prefer to be given the option instead of having the choice made for me. Thanks.

New: <img alt="Image" width="968" height="574" src="https://private-user-images.githubusercontent.com/7262715/621645175-9b0462f6-a0d5-43d8-af19-bdd8320abc82.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODQ2OTE1MDYsIm5iZiI6MTc4NDY5MTIwNiwicGF0aCI6Ii83MjYyNzE1LzYyMTY0NTE3NS05YjA0NjJmNi1hMGQ1LTQzZDgtYWYxOS1iZGQ4MzIwYWJjODIucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI2MDcyMiUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNjA3MjJUMDMzMzI2WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9ZTYwZDkwYzVkNjRmYTRkMGI1NzUxZmI3MTVjNmJhNjE1ZjZmMTRiYzVkNjBkYWQ0ZjY1MTM2N2Q3OTk5MzVmMyZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmcmVzcG9uc2UtY29udGVudC10eXBlPWltYWdlJTJGcG5nIn0.RunS3jTlK2r_oLA7BljqDQ7gMHYc4_OtJGNXLtzmFpI">

Thank you so much! It works like a charm!

My experience on Linux (Ubuntu) — CLI sessions invisible in desktop, partial sync after /web-setup

Setup: Used Claude Code CLI for 2 months (~10 sessions across 4 projects). Then installed the desktop app when it became available for Linux.

What happened:

• The desktop Code tab showed zero CLI sessions
• At some point I ran /web-setup (or similar command) and one specific session started appearing and syncing bidirectionally between CLI and desktop
• Even though I opened other sessions via claude --resume while the desktop was running, only that one session appeared — the rest never showed up

Root cause found:
The desktop maintains a separate session index at ~/.config/Claude/claude-code-sessions/<org-id>/<user-id>/ with its own JSON files. CLI sessions in ~/.claude/projects/*.jsonl are not auto-discovered by the desktop.

Workaround:
Manually creating entries in the desktop index pointing to existing CLI .jsonl sessions:

{
  "sessionId": "local_<new-uuid>",
  "cliSessionId": "<cli-session-id-from-jsonl>",
  "cwd": "/path/to/project",
  "isArchived": false,
  "title": "Session title"
}

Suggestion: Desktop should scan ~/.claude/projects/ on startup and auto-index existing CLI sessions, the same way claude --resume discovers them.

Strong +1 on this. The concrete workflow I keep hitting: I start a task in the CLI, then want to pick it up in the desktop app later — exactly the flow Codex supports (start in CLI, continue in the GUI). Today CLI sessions in ~/.claude/projects never surface in the desktop/web app, and --cloud/--teleport only cover new sessions, not the existing local history.

This has been filed several times and closed without a fix — #66229 (explicitly "Codex parity"), #56038, #57210, and #62515 (Desktop Recents not surfacing CLI sessions). Worth consolidating those signals here since this is the open thread with the most traction.

Even a read-only import of existing local CLI sessions into the desktop Recents would cover most of the value; bidirectional resume would be the ideal.

Another +1. It would be nice to pick up conversations in either the VS Code extension or the desktop app.

Existing CLI transcript files can be brought into the Desktop session list today, but it is a local import rather than native bidirectional sync. Desktop needs a metadata file whose cliSessionId points at each transcript under ~/.claude/projects/; without that index, the files can be healthy and still remain invisible in Desktop.

I built BasedGPT/claude-code-session-recovery for this missing-index case. On Windows or macOS, run python tools/diagnose.py first and follow the exact command it prints. If it finds orphaned transcript files, the guarded path is a dry run of synth_session_metadata.py; review the proposed entries, quit Desktop fully, then apply the printed command. Tony-Rain's Linux mapping demonstrates the same layer, but I would keep using the manual mapping there because the toolkit's metadata writer is not qualified for Linux.

That only covers importing existing local CLI sessions into Desktop. It does not provide continuous cloud sync, the reverse Desktop-to-CLI direction, or notifications, so those parts still need a native implementation.

Hope this helps, if my tools are able to help you, would appreciate a ⭐ :)

Any news about this ? I just lost my entire hisory in the desktop app...
Json file are here but I have to manually import all of them :'(

Hey Adamou02, if those JSON files are the CLI .jsonl transcripts, the data is already on disk. The missing piece is the Desktop metadata entry that points each cliSessionId at its transcript.

I built BasedGPT/claude-code-session-recovery for this local import case. Run python tools/diagnose.py first and follow the exact command it prints. If it routes you to metadata synthesis, review the dry run before applying it, then quit Desktop fully before the write step. That can make the sessions visible in the Desktop session list; it is a local import rather than continuous two-way sync.

Hope this helps, if my tools are able to help you, would appreciate a ⭐ :)

So I had a similar issue which I couldn't fix with "Troubleshooting → Import ". I did a long headless claude -p job overnight in WSL and wanted to read it in Desktop the next morning instead of scrolling a terminal log. It wasn't there, and Help → Troubleshooting → Import says "No CLI sessions to import". WSL has its own home dir, and I think the importer only scans C:\Users\<you>\.claude\projects\.

Desktop in general handles WSL paths fine though: its own entries use wslConfig + sshRemoteTranscriptPath, so you can point it at a transcript inside WSL. Wrote a script that generates that metadata for any WSL CLI session. they then show up in the sidebar and can be resumed from Desktop, appending to the same transcript on both sides (WSL and Desktop):
If it helps anyone - https://github.com/viliusjask/claude-wsl-session-importer

Would be nice if the native importer just scanned installed distros tho

A manual local import can bridge the CLI/Desktop gap today, even though native two-way synchronisation is still an upstream feature request.

Desktop needs a metadata file whose cliSessionId points to each transcript under ~/.claude/projects/. I built BasedGPT/claude-code-session-recovery for that missing-index case. On Windows or macOS, run:

python tools/diagnose.py

Follow the exact command it prints. If it routes to metadata synthesis, review the dry-run output first, then fully quit Desktop before applying the printed command. Keep a copy of the metadata and transcript directories before any write step.

This imports existing local sessions into the Desktop session list. It does not provide continuous two-way synchronisation, Desktop-to-CLI discovery, or notifications, which still need native support.

Hope this helps, if my tools are able to help you, would appreciate a ⭐ :)

Related/duplicate request: #87686 (shared/exportable conversation history between Claude desktop app and Claude Code). Closing that one as a duplicate of this.

Feature Request: Shared Situational Awareness Between Chat and Terminal in Claude Desktop

One-line summary

Let Claude Desktop's Chat tab and a pop-out/dockable terminal session overhear each other's outputs and periodically reconcile state, so a human directing both doesn't have to manually relay context between them.

Problem

Claude Desktop already runs Chat, Cowork, and Code (terminal) as tabs sharing the same engine, settings, and MCP config. But the sessions themselves are blind to each other. If I tell the terminal session "I moved the config to /etc," Chat has no idea that happened unless I copy it over myself. As I use both surfaces side by side for the same task, I end up as the sole relay of information between two otherwise-isolated processes.

Related but distinct from anthropics/claude-code#49775 ("Unified session history across CLI, Desktop app, VS Code, and Web") — that issue is about being able to browse past sessions from any surface. This request is about live, concurrent awareness between two active sessions, not history retrieval.

Proposed model: human-in-the-loop orchestration, not autonomous multi-agent negotiation

Important scoping decision: the two sessions should not negotiate task ownership or resolve conflicts themselves. The human is the orchestrator/hub — I decide what each session works on. What's missing is just the awareness layer underneath that, so neither session is operating on stale information about what I told the other one.

Mechanism: broadcast outputs, not shared raw context

• Each session keeps its own private context — the specific back-and-forth in chat, or the specific commands/output in the terminal.
• Each session's finished output (a chat reply, a terminal command's result) gets appended to the other session's context as an attributed, timestamped note — e.g., [terminal, 14:02] ran migrate.py, exit 0.
• This is broadcasting outputs, not merging inputs — what I type into one box stays private to that box. Only what Claude actually says/does gets shared, the way two people in a room hear what's said aloud but not each other's inner thoughts.
• Noisy outputs (e.g., a long build log) need a compression step before broadcast — a short "gist" line rather than the raw dump — to avoid flooding the other session's context.

Reconciliation checkpoints

• Not continuous — triggered at natural checkpoints (before either session takes a consequential action, or on request).
• Each session states its believed current state; the two are diffed, not silently overwritten.
• On mismatch (e.g., terminal changed a file chat didn't know about), surface it to the human rather than silently picking a winner.

UI ask

A pop-out or dockable terminal sidebar within Claude Desktop's existing Code tab/terminal, rather than a separate always-detached window — so the awareness layer above has an obvious place to live, and switching between "talk to chat" and "drop into terminal" doesn't mean losing sight of the other.

What this explicitly is NOT

• Not fully shared/merged memory between sessions (too expensive in tokens, and creates ownership ambiguity over shared context).
• Not autonomous task negotiation between the two sessions (no token-passing/ring protocol needed at 2 nodes — the human already arbitrates who does what).
• Not a replacement for #49775's session-history ask — this is about live sessions, that issue is about past ones.

Open design questions

• What's the right trigger granularity for reconciliation checkpoints (every N actions? before file-modifying commands? on demand only)?
• How much compression is applied to terminal output before it's broadcast to chat's context, and can that be tuned?
• Does this stay 1:1 (chat ↔ terminal) or generalize if a third concurrent surface (e.g., a background agent) is added later — at that point topology (star vs. mesh vs. ring) becomes a real design choice rather than a moot one.

Suggested minimal first version

Skip reconciliation and compression tuning entirely for v1. Just: every finished output in one surface gets a one-line, timestamped, attributed note appended silently to the other surface's context. No UI needed beyond what already exists — just wire the two contexts together. That alone would remove most of the manual copy-pasting between tabs today.