A dashboard over ~/.claude/ that can only ever show you the last thirty days

The dashboard can only ever show about thirty days of sessions

The file carries one warning block, and it sits directly under the pitch. Claude Code keeps session data for about 30 days, older JSONL files in ~/.claude/projects/ are cleaned up automatically, and because Karma reads those files directly, deleted sessions disappear from the dashboard too. There is no import, no archive and no copy step anywhere in the project, so the dashboard is a window onto a moving target rather than a store. That matters because the rest of the file promises time series. The cross-project analytics section offers velocity trends, cache hit rates, a coding rhythm and a view of how your usage patterns change over time. Individual tools get a usage trend over time. Agents get usage trends and average duration. Plugins get activity trends and top-used components. Skills get a full session history of every time they were used. Roughly six views are built on a window that closes behind them.

Four badges, a logo and a hero screenshot are all empty anchors

The header is built from HTML paragraphs and anchors, and the empty ones are the identity of the project. Four badges point at the Apache licence page, python.org, nodejs.org and kit.svelte.dev, and every one of them is an anchor with nothing between the opening and closing tags, so a renderer produces four unlabelled links where the licence, the language and the front-end framework should be named. The logo slot above the title is an empty centred paragraph. The hero screenshot is a link to docs/screenshots/home.png with target blank and no image inside it. The same pattern then repeats about two dozen times down the page: a centred empty paragraph under the session browser, under the timeline, under each of the six session detail tabs, under projects, analytics, tools, agents, hooks, plugins and skills. The documentation is structured as a screenshot gallery whose screenshots are not present in the file.

Python is the recorded language and the interface is a separate tree

The repository records Python as its primary language, which fits a project with an api/ directory at the root and a backend that reads and parses JSONL. Alongside it sit frontend/ for the interface, schema/ for something structured, scripts/, hooks/ and skills/, and a captain-hook/ directory whose name points at the git hook manager rather than at anything Claude Code specific. Three of the four empty badges, Python, Node.js and Svelte, name the languages in that stack, so the intended shape is a Python service with a separately built front end. What the file does not do is say how to start any of it. There is no clone command, no install step, no run instruction and no port number in the 1063 words of the README, which points instead to SETUP.md for setup, CONTRIBUTING.md for contribution guidance, a CHANGELOG.md, a FEATURES.md, a SECURITY.md, a CODE_OF_CONDUCT.md and a CLAUDE.md.

A .DS_Store is committed next to a .superpowers directory

The top-level listing opens with .DS_Store, the metadata file macOS Finder writes into every directory a person browses, and it sits in version control alongside a .gitignore. That is a small thing and a revealing one: the file is a Finder artefact of whoever was looking at the repository on a Mac, and nothing removed it. Right after it come two dot-directories with very different jobs. .github/ is the ordinary automation directory. .superpowers/ has no explanation anywhere in the file, and neither does schema/, captain-hook/ or skills/ as a root directory, even though the interface clearly displays skills per session and per plugin. So of the eight directories at the root, the file explains three of them and leaves five unnamed.

Two releases exist, one is tagged beta, and the newest is four months old

The release history has two entries. The first is tagged beta rather than a version number, with the release name First Release v0.1.0, and it was published on 2026-03-01. The second is v0.2.0, named for session to ticket linking, published on 2026-05-19. The default branch, main, was last pushed on 2026-09-21. That leaves four months of commits past the newest tag, and a project whose version scheme never left the zero series. The gap also covers the period in which the file's largest feature, ticket linking, would have been extended beyond the three linking routes it describes. There is a CHANGELOG.md in the tree, so the record of those four months exists inside the repository; the release page simply does not point at it.

Ticket linking is read-only, and one of the three routes costs an MCP server

The linking feature states its own boundary before describing anything else: Karma stays read-only, it stores the link and caches the title and status, and it never writes back to the ticket provider. Three routes reach the same stored record. You can paste a URL or a key into the Tickets section on any session page. You can type /link-ticket-to-session with an identifier such as ABC-123 in any Claude Code session, or ask the agent for it in natural language, and that route works by using your Linear, Atlassian or GitHub MCP server to fetch the title. So the second route depends on a server the dashboard does not ship. The third is an opt-in SessionStart hook that watches branch names for keys such as feat/LINEAR-123-foo and links silently in the background. Browse side, a /tickets index is filterable by provider and project, a ticket detail page lists every session linked to it, and GitHub entries get sub-pill filtering across All, Issues and PRs.

Linking aggregates per git repository, not per checkout

One detail in the linking section decides whether the feature is useful in a monorepo. There is a Tickets tab on every project page, and it aggregates across all checkouts of the same git repository, so a ticket linked from a frontend subdirectory also appears on the main project page for that repository. The example uses a frontend folder and its parent, and the rule generalises: what gets linked is a property of the repository, not of the working directory, so the same ticket does not fragment into three records because someone had the feature branch open in two places. The Projects page is organised the same way, grouping sessions by git repository with a session count and a last-active time on each card, and expanding a repository to reveal the individual project directories inside it. Projects view and Tickets view therefore agree on what counts as one project, which is not something either had to state twice.

The session browser raises a terminal window rather than replacing it

Two features show what the project expects its relationship to Claude Code to be. The session browser puts live sessions at the top with real-time status badges, and beside each one sits a button written as a prompt marker that raises the terminal window the live session is running in. So the dashboard is a monitor that coexists with the terminal rather than a shell that replaces it, and it can reach outside its own window to bring that terminal forward. The other feature is discovery: any session that writes to ~/.claude/ shows up automatically, with no import step and no agent-side hook, for both Claude Code CLI sessions and Claude Desktop sessions in Claude Code mode. That is what makes the thirty-day ceiling a property of Claude Code rather than of Karma, and it is also why the file can claim to work with either client without a compatibility setting.

Editorial conclusion

Claude Code Karma is a good fit if you run Claude Code heavily, work across several git checkouts, and want to see which hooks, skills, subagents and MCP servers a session actually leaned on rather than what you intended to use. Its read-only design is the right call for a tool that reads your session transcripts, and the ticket linking aggregates per repository rather than per folder, which is more useful than it first sounds. It is a poor fit if you want history, because the data it renders is deleted upstream after about thirty days and there is no import or archive step, so every velocity trend and coding-rhythm chart is bounded by Claude Code's own retention. Before you lean on the analytics, confirm that your settings do not clean up faster than thirty days, and if you need a durable record, copy ~/.claude/projects/ somewhere else on a schedule.

Frequently asked questions

Official sources

1. Issues
2. JayantDevkar/claude-code-karma on GitHub
3. License: Apache-2.0
4. README
5. Releases