tsx · August 28, 2026

Claude Code Lens makes local session history easier to inspect without sending it elsewhere

Claude Code Lens is a local-first viewer for Claude Code session JSONL, turning scattered transcripts and tool payloads into browsable conversations, collapsed tool calls, diffs, and display-layer secret masking.

MM.liaichi·@muliaichi·5 min read
TypeScriptNode.jsVitesql.jsSQLiteWebAssemblytsx
View on GitHub
claude-code-lensMuLIAICHI/claude-code-lens
Last commitRecently
Primary languageTypeScript
Stars0

The hard part of reviewing an AI coding session is often the record, not the conversation

Claude Code session history can be useful long after a task ends: it may explain why a file changed, preserve a debugging trail, or help someone revisit an earlier line of inquiry. But the repository describes those sessions as JSONL files under ~/.claude/projects/, spread across files and crowded with tool payloads. That format is practical for a tool, but not necessarily for a human trying to reconstruct what happened.

Claude Code Lens is built around that gap. It is a local-first viewer for Claude Code session history, intended to turn those stored records into a more legible interface. The project may be useful to developers who want to review their own Claude Code work without uploading transcripts to a third-party service, particularly when tool output or pasted configuration may have placed sensitive material in the history.

Its central promise is deliberately narrow: inspect local session data locally. The README states that Lens makes zero network calls, has no telemetry, cloud service, or account requirement, and runs its dashboard on localhost.

From sharded JSONL to a browsable session view

The documented workflow begins with the session files Claude Code stores in the user’s home directory. Lens scans that history and presents a session list grouped by project. The list can be sorted by date, duration, or message count, giving users several ways to locate a conversation.

Opening a session moves from file-oriented records to a chat-oriented view. Prompts and assistant replies are presented as a conversation, while tool calls are collapsed until a reader chooses to expand them. File edits are rendered as diffs, which is a useful distinction: a diff shows the lines added and removed rather than leaving the reader to interpret a raw tool payload.

The repository also documents separate commands for different stages of this workflow. npm run scan provides terminal statistics. npm run index rebuilds the index incrementally. npm run serve starts the dashboard on a localhost port and opens it. This division suggests a practical separation between inspecting the corpus, maintaining a local index, and using the visual browser.

The project stores its SQLite index at ~/.claude-code-lens/index.db, rather than alongside the original session data. Keeping derived data separate from source records is a small but important design choice. It makes it clearer which files are the original history and which are Lens’s local working state.

Privacy is treated as a testable behavior

Session transcripts can include more than prose. Tool calls may contain environment values, commands, file contents, or credentials pasted during a debugging session. Lens addresses that risk with a secret scanner in its display layer.

According to the README, the renderer masks several recognizable patterns: API-key shapes, .env-style values, JSON Web Tokens, private-key blocks, and passwords embedded in URLs. The masking occurs in the displayed view, with a per-session reveal toggle. The source session files are not meant to be rewritten.

That last detail is a meaningful tradeoff. Display-only redaction can make review safer without changing the historical record. At the same time, it is not a claim that the underlying files are encrypted or scrubbed. Someone with direct access to the stored JSONL can still access its original contents. Lens’s role is to make the viewing experience safer and clearer, not to replace access control for the files themselves.

The README goes beyond describing privacy goals and identifies tests intended to enforce them. A no-network test wraps the socket layer and fails when scanning and rendering attempt a non-loopback connection. Another test scans the built frontend for http(s):// references, aiming to rule out external assets. The server is documented to bind 127.0.0.1, not 0.0.0.0, which limits access to the local machine rather than exposing the dashboard to a local network. A hash comparison test checks that session files remain unchanged after scanning and rendering.

These are useful implementation lessons for local tooling. “Local-first” is easy to state, but it has several failure modes: analytics requests, remote fonts, an overly broad server bind address, or a transformation step that quietly mutates source data. The repository’s documented tests map those broad assurances to concrete checks.

A compact TypeScript application with local SQLite

The repository is primarily written in TypeScript. Its package manifest confirms a Node.js requirement of version 20 or newer, with scripts for building, type checking, serving, scanning, indexing, and testing.

The build combines the TypeScript compiler with Vite. TypeScript provides the project’s typed application code, while Vite is used for the frontend build. The command-line entry points are run with tsx, including the serve, scan, and index commands. Tests use Node’s test execution through tsx --test.

For the local index, Lens depends on sql.js version 1.14.1. The README describes this SQLite engine as WebAssembly-based and says there are no native build steps. In practical terms, that avoids requiring a platform-specific SQLite compilation step during installation, while still giving the application a SQLite-backed local index.

The project is published under the MIT license in its manifest. Its README labels the current scope as a completed parser and session browser, while analytics, full-text search, and export are listed as planned follow-ups. Those boundaries are helpful for setting expectations: Lens is currently focused on finding and reading session history, not on claiming a finished analytics or export system.

A focused way to revisit local AI-assisted work

Claude Code Lens does not try to turn session history into a cloud product or a collaboration platform. Its documented value is more direct: make locally stored coding conversations reviewable, preserve the original files, and avoid introducing network traffic as part of that review.

For builders who have accumulated Claude Code sessions and want a cleaner way to inspect them, the design is worth examining. Explore the verified repository at github.com/MuLIAICHI/claude-code-lens.

Your repository, explained

Turn your GitHub repository into a story worth sharing.

Connect a public repository, generate a reviewable draft, and publish it with Reather.

Create your storyMore from M.liaichi
Claude Code Lens makes local session history easier to inspect without sending it elsewhere · Reather