DEV Community: decker

Cursor Session Management: How to Find, Search, and Organize Your AI Coding Conversations

decker — Mon, 30 Mar 2026 09:14:35 +0000

Have you ever spent 20 minutes looking for a conversation you had with Cursor last week? The one where it helped you fix a tricky async bug — and now you're facing the same issue in a different project, but can't find that thread anywhere?

This isn't a user error. It's a structural limitation in how Cursor handles session history.

The Current State of Cursor Session Management

Cursor includes a built-in conversation history panel. You can browse sessions for the current project and click into any conversation to review the context.

This works fine when you have a handful of sessions. But as usage scales, problems emerge.

Problem 1: Sessions Are Siloed by Project

Cursor ties sessions to the project level. A conversation in project-a doesn't appear when you open project-b.

This makes sense architecturally — each project has its own context. But in practice, many problems are cross-cutting:

You solved a Docker networking issue in one project three months ago and face the same problem in a new codebase
You wrote a useful utility function with AI assistance and want to reuse it elsewhere
You remember getting a great architecture recommendation but can't recall which project it was in

Cursor doesn't offer global search across projects. You have to open each project individually and scroll through its session list manually.

Problem 2: Session Accumulation Without Organization

Developers who use Cursor intensively can generate 20-50 sessions per week. After a month, that's over a hundred conversations.

Cursor's session panel is essentially a chronological feed. It doesn't support:

Keyword filtering
Tagging or categorization
Association with specific code files
Favoriting or bookmarking important sessions

Early sessions become effectively unrecoverable once you've scrolled past them.

Problem 3: Disconnection Between Conversations and Code State

Cursor records the dialogue between you and the AI, but it doesn't link to the actual code state at the time of the conversation.

Suppose two weeks ago the AI suggested refactoring a function from sync to async. You made the change. Now you want to review: what did that function look like before? Which lines changed?

You'd need to find the AI's code snippet in the conversation, then manually dig through Git history to locate the corresponding commit. This is tedious and error-prone.

Problem 4: Data Ownership and Privacy

Where is your session data stored? In what format? If Cursor changes its pricing model or you decide to switch editors, will your conversation history remain accessible?

According to Cursor's documentation, session history is tied to your account and stored on Cursor's servers. This means:

Your conversations pass through Cursor's infrastructure
Access to history may be restricted after subscription cancellation
No native export to a locally readable format

For developers working with sensitive codebases, this is worth considering.

Existing Approaches and Their Limitations

The community has developed several workarounds, each with tradeoffs.

Approach 1: Manual Export to Note-Taking Tools

Some developers periodically copy important conversations into Notion, Obsidian, or similar tools.

Pros: Full data ownership, flexible organization.

Cons:

High manual effort, hard to maintain consistently
Loses code highlighting and context
No code diff capability

Approach 2: Cursor's Built-in Export

Cursor offers a conversation export feature that saves dialogues as text files.

Pros: Officially supported, simple to use.

Cons:

Exports are static text, losing structural information
Still requires manual intervention
Exported files lack indexing, making search difficult

Approach 3: Third-Party Open Source Tools

Several community tools exist for Claude Code session viewing, such as claude-history and claude-replay.

Pros: Some provide search and browsing capabilities.

Cons:

Most only support Claude Code, not Cursor
Limited feature sets, no cross-tool integration
Require command-line proficiency

A More Systematic Approach

The limitations above share a root cause: they're all reactive — the session already exists, and you're trying to manage it after the fact.

A complete session management solution should provide:

1. Global Indexing

Sessions from Cursor, Claude Code, and other tools should be indexed in a unified system with full-text search.

Search should cover:

Conversation content (both user questions and AI responses)
Code snippets
File paths
Time ranges

2. Temporal Correlation

Sessions should be linked to Git commit history. When you look at a two-week-old conversation, you should be able to see the code state at that moment and what changed afterward.

This requires mapping between the session timeline and Git history.

3. Local Storage

Session data should be stored locally in an open, human-readable format. This ensures data portability even if you switch tools.

Sensitive information (API keys, internal paths, etc.) should be automatically redacted during display.

4. Cross-Tool Support

The ideal solution shouldn't be tied to a single tool. Whether you use Cursor for frontend, Claude Code for backend, or Gemini CLI for data analysis, all sessions should be viewable and searchable in one place.

A Tool That Does This

If you're looking for something that addresses these needs, take a look at Mantra.

Mantra is a local-first AI coding session viewer that supports Cursor, Claude Code, Gemini CLI, Codex, and other tools. Its core features include:

Universal Search: Full-text search across projects and tools with sub-50ms response times
Time Travel: Drag a timeline slider to see the exact code state at any point in a conversation
Local Storage: Data lives on your filesystem in JSON format, zero network requests
Privacy Sanitization: Automatic detection and redaction of API keys, sensitive paths, and other PII

Mantra's local features are permanently free with no account required. You can download it from the official site.

Summary

Cursor's session management is adequate for light usage, but becomes a bottleneck as your session count grows into the dozens or hundreds.

The three core pain points are: no cross-project search, lack of session organization, and disconnection between conversations and code state.

There's no perfect native solution yet, but third-party tools or custom indexing can significantly improve the situation. The key principle is retaining control over your session data — local storage, open formats, and cross-tool support.

If you have other Cursor session management tips or workflows, feel free to share in the comments.

Where Is Claude Code Session History? How to Find Your AI Coding Conversations

decker — Mon, 30 Mar 2026 09:13:08 +0000

You spent two hours in Claude Code debugging a complex concurrency issue and finally found the solution. Three days later, another project hits a similar race condition. You vaguely remember handling this before, but you can't find that conversation anywhere.

This is not an isolated case. Claude Code's session history management is a widely overlooked problem.

How Claude Code Stores Sessions

Claude Code stores conversation records in the local file system. The exact location depends on your operating system:

macOS/Linux: ~/.claude/projects/
Windows: %USERPROFILE%\.claude\projects\

Within each project directory, session files are generated in JSON format, with filenames typically being a hash string. These files contain the complete conversation history—every prompt you sent, every response Claude gave, and the associated code context.

The problem: Claude Code doesn't provide a native session browsing interface.

Limitations of Existing Approaches

Approach 1: Manually Browse JSON Files

You can open the JSON files directly in ~/.claude/projects/. But these filenames carry no semantic information—you can't tell which file corresponds to which conversation just by looking at the name. After accumulating dozens of sessions, finding a specific conversation is like searching for a particular page among a stack of untitled manuscripts.

Approach 2: Use grep to Search

grep -r "keyword" ~/.claude/projects/

This finds session files containing specific keywords, but returns raw JSON with poor readability. You can't see conversation context or quickly jump to relevant code snippets.

Approach 3: Rely on Claude's Context Window

Claude Code's context window has some memory capability, but it has token limits. Once a conversation exceeds the context window, early content gets truncated. Cross-session memory doesn't exist—Claude won't automatically link to your conversation from three days ago in a different project.

Common Problems with These Approaches

No visual interface: JSON files aren't designed for human reading
No time dimension: Can't browse session history chronologically
No cross-project search: Each project's sessions are isolated
No code correlation: Can't map conversations to corresponding code states

Why This Matters

AI coding conversations aren't just "chat logs." They contain:

Debugging paths: How you located the problem, eliminated wrong assumptions, and found the root cause
Architecture decisions: Why you chose approach A over B, and what trade-offs were considered
Code review logic: What potential issues the AI pointed out, and which suggestions you accepted
Learning curves: How your understanding of a framework or language evolved

Losing this content means:

Duplicate work: Need to re-debug when encountering similar problems
Knowledge gaps: New team members can't understand historical decision context
Debugging difficulties: Can't trace back "why was it written this way"

A real scenario: You optimized a database query in Claude Code, reducing response time from 2 seconds to 200ms. Two weeks later, a colleague asks why you used a "seemingly complex" subquery. You want to explain the performance test data from that time, but the conversation is buried among dozens of sessions.

Best Practices for Session Management

While waiting for better tooling, there are ways to mitigate this problem:

1. Manually Export Important Conversations

After completing a significant debugging or design session, copy the conversation content into project documentation. It's tedious, but at least ensures key knowledge is preserved.

2. Maintain a Decision Log

Keep a DECISIONS.md file in your project, documenting important architectural decisions and the reasoning behind them. This doesn't depend on any specific tool and is the most reliable way to preserve knowledge.

3. Use Git Commit Messages for Context

After each important AI-assisted coding session, write detailed commit messages describing the context at that time. Git history can supplement session records.

4. Organize Sessions by Project

Claude Code supports organizing sessions by project directory. Make sure you start sessions in the correct project directory so session files are stored in corresponding project paths.

All these methods share a common drawback: they require additional manual effort and are scattered across different tools.

A More Systematic Solution

If there were a tool that could:

Automatically import Claude Code session files without manual organization
Full-text search across all historical conversations, with filtering by time, project, and keywords
Time travel to align conversation timelines with Git commit history, viewing code states when conversations occurred
Cross-tool integration to manage sessions from Claude Code, Cursor, Gemini CLI, and other tools simultaneously

Such a tool would fundamentally change how developers manage AI coding conversations.

Such a tool already exists. Mantra is a local session viewer that specifically solves this problem. It directly reads JSON files from ~/.claude/projects/, builds an index, and enables full-text search. More importantly, it can align conversation timelines with Git history—drag to a conversation node, and the workspace automatically checks out to the corresponding code state.

All of Mantra's data processing happens locally without uploading to any server. For coding conversations containing API keys and internal paths, this matters.

The Future of Session Management

As AI coding tools become more prevalent, session management will become an increasingly important problem. Current tooling is still in early stages—most AI coding assistants focus on "generating better code" rather than "managing existing conversations."

But history tells us that any tool generating large amounts of data eventually needs corresponding management solutions. Just as Git solved code version management, we need similar solutions for AI conversation management.

Until then, understanding where session files are stored, establishing basic knowledge preservation habits, and using dedicated session management tools when needed are things every Claude Code developer should consider.

Mantra is a local session viewer supporting Claude Code, Cursor, Gemini CLI, and Codex. Local features are free forever, no registration required. Learn more at the official website.

AI Coding Tools Comparison 2026: Claude Code vs Cursor vs Gemini CLI vs Codex

decker — Mon, 30 Mar 2026 09:11:35 +0000

In 2026, AI coding tools have evolved from "cool gadgets" to "daily productivity essentials." But with Claude Code, Cursor, Gemini CLI, Codex, and others competing for attention, how do developers choose? This article provides an objective technical comparison and explores an often-overlooked dimension: session management.

1. The 2026 AI Coding Landscape

The AI coding market has matured significantly. Current tools fall into several categories:

Type	Examples	Core Value
IDE-Enhanced	Cursor	Deep AI integration on top of VS Code
Terminal Agents	Claude Code, Gemini CLI	AI coding agents in the terminal
Code Execution	Codex	Automated code task execution

There's no "universally best" choice. Each type excels in different workflows. The key is understanding your specific needs.

2. Deep Dive: The Four Major Tools

2.1 Cursor: The IDE Experience Benchmark

Price: $20-$200/mo

Cursor delivers the most complete AI-native IDE experience. Built on VS Code, it offers multi-model support and deep integration.

Key Strengths:

Composer Mode: Agent-level cross-file editing that plans, executes, and tests multi-step tasks
Tab Completions: Context-aware intelligent completions with exceptional accuracy
Codebase Indexing: Understands your entire repo structure, not just open files
Model Flexibility: Switch between models based on task complexity

Best For: Developers migrating from VS Code, teams needing a complete IDE experience.

Limitations: Premium models burn through quotas quickly; can feel sluggish on large monorepos.

2.2 Claude Code: The Terminal King

Price: From $20/mo

Claude Code is Anthropic's terminal-based AI coding agent. Opus models excel at complex code tasks.

Key Strengths:

Deep Code Understanding: Reads entire repos, understands architecture, respects existing patterns
Agentic Workflow: Plans multi-step changes, runs tests, self-corrects errors
Zero Context Switching: Stays in your terminal, works with git, npm, pytest directly
Extended Thinking: Deep reasoning produces higher-quality code changes

Best For: Terminal-heavy developers, complex refactoring, debugging, architectural changes.

Limitations: Terminal-only interface, no visual IDE; limited to Claude models only.

2.3 Gemini CLI: Google Ecosystem Integration

Price: Free/Paid

Gemini CLI is Google's terminal AI coding tool, deeply integrated with the Google Cloud ecosystem.

Key Strengths:

Free Tier: Generous free usage allowance
Google Ecosystem Integration: Seamless connection with Google Cloud, Firebase, etc.
Multi-modal Support: Supports code, text, image, and other inputs
Long Context Window: Supports ultra-long context for large codebases

Best For: Google Cloud developers, individual developers needing free solutions.

Limitations: Relatively closed ecosystem, fewer third-party integrations.

2.4 Codex: Automated Code Execution

Price: From $20/mo

Codex is OpenAI's code execution tool, focused on automating code tasks.

Key Strengths:

Automated Execution: Can automatically run tests, deploy code
Sandbox Environment: Secure code execution environment
Multi-language Support: Supports various programming languages
API Integration: Easy to integrate with other tools

Best For: Teams needing automated code execution, CI/CD integration.

Limitations: Primarily focused on automation scenarios, weaker interactive coding experience.

3. Comparison Summary: How to Choose

Dimension	Cursor	Claude Code	Gemini CLI	Codex
Interface	IDE	Terminal	Terminal	API/Terminal
Multi-file Editing	Excellent	Excellent	Good	Good
Autocomplete	Best	N/A	Good	N/A
Agent Mode	Excellent	Best	Good	Excellent
Model Choice	Many	Claude only	Gemini only	GPT only
Starting Price	$20/mo	$20/mo	Free	$20/mo
Best For	IDE users	Terminal users	Google ecosystem	Automation

Recommendations:

Best overall experience → Cursor
Terminal power users → Claude Code
Google Cloud users → Gemini CLI
Automation needs → Codex

Multi-tool Practice: The 2026 mainstream approach is combining multiple tools — choosing the most suitable tool based on task type.

4. The Overlooked Dimension: Session Management

The above comparisons focus on "coding capability." But there's another frequently ignored question:

Where do your AI coding conversations go?

Every day, developers generate valuable conversations across these tools. These conversations contain:

Debugging thought processes and investigation paths
Architectural decision reasoning
Code review logic and considerations

But this data faces three problems:

Tool Lock-in: Cursor sessions can only be viewed in Cursor; Claude Code lacks native session management entirely
Subscription Walls: Session history may become a paid feature — cancel subscription = lose memory
Privacy Risks: Session data may be uploaded to the cloud, containing API keys, internal paths, private code

When you solved a complex bug in Claude Code three days ago, then encounter a similar issue in Cursor today, you've completely forgotten the previous solution — because conversations between tools are isolated islands.

5. Mantra: The Session Management Layer for AI Coding

This is the problem Mantra aims to solve.

Mantra is not another AI coding tool — it's the "session management layer" for AI coding.

It supports Claude Code, Cursor, Gemini CLI, and Codex, providing:

5.1 Cross-Tool Session Search

Whether you work in Claude Code, Cursor, Gemini CLI, or Codex, Mantra unifies and indexes all sessions. One search, across all tools.

Search "OAuth token refresh"
→ Find debugging notes from Claude Code 3 days ago
→ Find implementation approach from Cursor 1 week ago
→ Find API documentation references from Gemini CLI

5.2 Time Travel: Code Timeline Replay

Mantra aligns AI conversation timelines with Git commit history. You can precisely see: at a specific commit, what advice did the AI give? When was a particular bug resolved in conversation?

5.3 Local Privacy Sanitization

Mantra runs 100% locally with zero network requests. The built-in Local Sanitizer real-time redacts API keys, sensitive paths, and other information while processing session data.

You can verify with network analysis tools: Mantra sends zero data during operation.

5.4 MCP Gateway

In 2026, MCP (Model Context Protocol) is becoming the standard for AI tool interoperability. Mantra provides a unified MCP gateway for centralized MCP Server configuration management.

6. Mantra's Position: Complementary, Not Competitive

To be clear: Mantra does not replace any AI coding tool.

Your Workflow:
┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│   Cursor    │    │ Claude Code │    │ Gemini CLI  │
│  (Daily)    │    │ (Complex)   │    │ (Free tier) │
└──────┬──────┘    └──────┬──────┘    └──────┬──────┘
       │                  │                  │
       └──────────────────┼──────────────────┘
                          │
                          ▼
                 ┌─────────────────┐
                 │     Mantra      │
                 │  (Session Layer)│
                 │  Search·Replay  │
                 └─────────────────┘

Mantra's value lies in:

Unified View: One interface for all AI coding sessions
Knowledge Preservation: Conversations become searchable assets, not consumables
Privacy Assurance: Runs locally, data never leaves your machine
Permanently Free: Core local features are free forever, no registration required

7. Conclusion

The AI coding tool choice in 2026 is no longer about "which is best" — it's about "how to combine them effectively."

Cursor suits developers needing complete IDE experience
Claude Code suits terminal power users and complex tasks
Gemini CLI suits Google Cloud users and budget-sensitive developers
Codex suits automated code execution needs

And regardless of which tool you choose, session management deserves consideration — are your AI coding conversations becoming searchable, reusable knowledge assets?

Mantra supports Claude Code, Cursor, Gemini CLI, and Codex. It doesn't replace your tools — it makes your tools more valuable.

Mantra is closed-source software with permanently free local features. No registration required. Download from the official website or GitHub Releases.

I Tested 4 Tools for Browsing Claude Code Session History

decker — Wed, 11 Mar 2026 12:56:07 +0000

If you've used Claude Code for more than a week, you've probably had this moment:

"I solved this exact problem last Tuesday. What prompt did I use?"

Claude Code saves every conversation as JSONL files in ~/.claude/projects/. The data is there. But actually finding anything useful in those files? Good luck.

I've been using Claude Code daily since January, and after losing a critical session to an update bug (#29154 on GitHub — you're not alone), I went looking for better ways to manage my session history.

Here's what I found.

The Problem

Claude Code stores sessions across multiple directories:

~/.claude/projects/<project-hash>/sessions/
~/Library/Application Support/Claude/claude-code-sessions/  # Desktop

Each session is a .jsonl file — one JSON object per line, containing every message, tool call, and response. A single afternoon of coding can generate 50MB+ of session data.

The built-in tools give you:

claude --resume — lists recent sessions, lets you pick one
/history — shows conversation entries from history.jsonl

That works fine for "what did I do 10 minutes ago?" but falls apart when you need to search across weeks of sessions or remember how you debugged a specific issue.

What I Tested

I spent a week using four different approaches to browse my Claude Code history:

1. Built-in CLI (`--resume` + `/history`)

What it does: Lists your recent sessions by title and timestamp. You can resume any of them to continue the conversation.

What's good:

Zero setup, always available
Resume lets you pick up exactly where you left off
/history gives a quick chronological view

What's not:

No search. You're scrolling through session titles hoping one rings a bell.
sessions-index.json corruption means sessions vanish from the list (the JSONL files are fine — the index just lost track of them)
Desktop app and CLI can get out of sync

Best for: Resuming a session you just closed. Not for finding something from last week.

2. claude-history (Rust CLI)

What it does: A terminal TUI that gives you fuzzy search across your Claude Code conversations. Written in Rust, so it's fast.

What's good:

Really fast fuzzy search across all sessions (it's Rust, so yeah)
Terminal-native, fits right into the Claude Code workflow
Shows conversation content inline

What's not:

Claude Code only — no Cursor, no Codex
Read-only search — you can find a session, but you're reading raw JSONL
No code diff view — you see what Claude said, but not what changed in your files

Best for: Power users who live in the terminal and just want to search conversation text.

3. Claude Code History Viewer (CCHV)

What it does: A desktop app (Electron-based) that visualizes sessions from Claude Code, Codex, and OpenCode. Shows token usage analytics.

What's good:

Cross-tool support (Claude Code + Codex + OpenCode)
Token usage breakdown — see which sessions burned the most tokens
Clean UI with session browsing

What's not:

No time-travel replay — you see the conversation, not the coding process
No search across session content (browsing only)
No security features for sensitive content

Best for: Getting a bird's-eye view of your token spend and browsing conversations visually.

4. Mantra

What it does: Records and replays AI coding sessions — terminal I/O, code changes, the full timeline. Works with Claude Code, Cursor, Codex, and Gemini CLI.

What's good:

Scrub through the timeline like a video to see what happened
Shows what code changed at each step, not just the conversation
Works across 4 major AI coding tools, not just Claude Code
Detects and redacts API keys, credentials before you share sessions
MCP and Skills management across tools

What's not:

Heavier setup than a CLI tool
Desktop app (not terminal-native)
Newer project — smaller community

Best for: When you need to understand how a session played out, not just read what was said. Also handy if someone else on the team needs to review your AI coding sessions.

The Verdict

No single tool wins across the board. Depends on what you're after:

Need	Best Pick
Quick resume of recent session	Built-in `--resume`
Fast text search across history	claude-history
Token usage analytics	CCHV
Full replay + code changes	Mantra
Multi-tool support	Mantra or CCHV
Sensitive content handling	Mantra

My current setup: I use --resume for quick continuations, and Mantra when I need to understand how a past coding session actually played out — especially for replaying sessions where I solved tricky bugs.

One More Thing

If you've lost sessions after a Claude Code update, check the raw JSONL files before panicking. The data is usually still there — it's the index that breaks. Here's the quick recovery:

# Check if your session files exist
ls ~/.claude/projects/*/sessions/*.jsonl

# Count your sessions
find ~/.claude -name "*.jsonl" -path "*/sessions/*" | wc -l

# For Desktop app, also check:
ls ~/Library/Application\ Support/Claude/claude-code-sessions/

If the files are there but --resume doesn't show them, the sessions-index.json needs rebuilding. Each tool above handles this differently (or not at all), so pick the one that matches your workflow.

What's your approach to managing AI coding session history? I'm curious if anyone has other tools or workflows worth trying.

AI Coding: Why You Need to Record Your Complete Conversation History

decker — Tue, 10 Mar 2026 01:08:57 +0000

The Problem Every AI Programmer Knows

You spent 2 hours with Claude solving a tricky bug. The prompts were perfect, the reasoning was solid, and the code worked.

One week later, you hit a similar problem. And you cannot remember a single prompt you used.

Sound familiar?

Why This Keeps Happening

Current AI chat tools are designed for one-off Q&A, not for engineering workflows.

Think about it:

Code has version control (Git)
Issues have tracking systems (GitHub Issues, Jira)
AI conversations have... nothing?

Your AI chat history is buried in a sidebar of hundreds of conversations. Good luck finding that specific prompt from last Tuesday.

The Real Cost

This is not just annoying — it is a real productivity drain:

Repeated reasoning — You solve the same class of problems multiple times because you forgot your approach
Lost prompt techniques — That clever prompt pattern that worked perfectly? Gone forever
No team knowledge sharing — Your teammates only see the final code, not the AI-assisted reasoning that produced it
Slower debugging — When bugs appear, you cannot trace back to "why did we implement it this way?"

Conservative estimate: 20-30% wasted time on repeated AI interactions.

Three Ways to Fix This

Approach 1: Manual Logging

The simplest method — keep a markdown file or Notion page where you paste important prompts and responses.

Pros: Zero setup, works with any AI tool
Cons: Requires discipline, easy to forget, no code-change correlation

Approach 2: Session Recording Tools

Tools that automatically record your entire AI coding session — every prompt, every response, every code change.

For example, Mantra records complete AI coding sessions and lets you "time travel" back to any point. You can see exactly what prompt you used, what the AI responded, and how the code changed.

Pros: Automatic, complete history, searchable
Cons: Requires installation, storage overhead

Approach 3: Team Prompt Libraries

Build a shared knowledge base of effective prompts organized by problem type.

Pros: Great for teams, compounds over time
Cons: Requires curation effort, may not capture full context

The Bigger Picture

We are in the early days of AI-assisted programming. The tools will get better, but the workflow is something we need to figure out ourselves.

Just like version control transformed how teams collaborate on code, some form of "AI conversation history" will become essential.

The question is not whether — it is when.

What About You?

How do you handle your AI coding history? Do you have a system for remembering past prompts and solutions?

I would love to hear what works for different people. Drop a comment below.

Why Your AI Coding Sessions Are Worth More Than You Think (And How to Stop Losing Them)

decker — Tue, 10 Mar 2026 00:55:50 +0000

Have you ever had that moment where you know you solved a similar bug three weeks ago using Claude or ChatGPT, but you can't remember the exact prompt you used? Or the specific reasoning chain that led to the fix?

You're not alone. This is quietly becoming one of the biggest productivity drains in AI-assisted development.

The Hidden Cost of Forgetting

Let's be honest about how most of us use AI coding assistants today:

We hit a problem
We open a chat, describe the issue, iterate on prompts
The AI helps us solve it
We close the tab and move on

The code gets committed. The solution lives in the codebase. But the process that got us there — the prompts, the reasoning, the dead ends, the breakthroughs — vanishes.

This matters more than you might think.

Three Real Scenarios Where Lost Sessions Hurt

1. The "I Fixed This Before" Problem

You encounter a tricky TypeScript generics issue. You have a vague memory of spending 30 minutes with an AI assistant working through the exact same pattern two months ago. You found a clean solution. But now? You're starting from scratch.

The code is in git, sure. But the journey — the prompts that helped you understand why infer behaves differently inside conditional types — that's gone.

Time wasted: 30-45 minutes re-deriving what you already learned.

2. The Onboarding Gap

A new developer joins your team. They need to understand not just what the code does, but why certain architectural decisions were made. You used AI to explore three different approaches before settling on the current one. Those conversations contained valuable context about trade-offs, edge cases considered, and alternatives rejected.

Without access to those sessions, the new team member either:

Makes the same mistakes you already explored and discarded
Asks you to re-explain the reasoning (interrupting your flow)
Accepts the code at face value without understanding the "why"

3. The Prompt Refinement Loss

Over weeks of working with AI assistants, you develop increasingly effective prompting patterns. You learn that for your specific codebase, starting with "Look at the error handling pattern in src/middleware/ and apply the same approach to..." gives much better results than generic instructions.

These hard-won prompt strategies live only in your memory — which, let's face it, is not the most reliable storage system.

What Actually Makes AI Coding Sessions Valuable?

It's worth stepping back and asking: what exactly is valuable in an AI coding session beyond the final code output?

The prompt engineering context. The specific way you framed a problem that led to a good solution. This is transferable knowledge — it works for similar problems in the future.

The exploration path. When you ask an AI to compare approaches (e.g., "Should I use a worker thread or a child process here?"), the comparison and reasoning have lasting educational value.

The debugging narrative. AI-assisted debugging sessions often follow a logical chain: hypothesis → test → refine. This chain is often more instructive than the final fix.

The decision rationale. "We went with approach B because approach A had issues with..." — this context is gold for future-you and your team.

Practical Tips to Preserve Session Value

Here are some concrete things you can do today:

1. Build a Personal Prompt Library

When you craft a prompt that works exceptionally well, save it. Create a simple markdown file in your project:

# Effective Prompts

## Debugging Race Conditions
"Analyze this code for potential race conditions. Focus on shared 
state between [X] and [Y]. Consider the scenario where [specific 
timing issue]."

## Architecture Decisions
"Compare [approach A] vs [approach B] for [specific use case]. 
Consider: performance under [N] concurrent users, maintainability 
for a team of [size], and compatibility with [existing system]."

2. Document the "Why" in Commit Messages

When an AI helps you reach a solution, invest 60 seconds to write a commit message that captures the reasoning:

fix: resolve WebSocket reconnection loop

AI-assisted debugging revealed the issue was in the backoff 
timer not resetting on successful connection. Initial hypothesis 
(buffer overflow) was incorrect. Key insight: the reconnection 
handler was capturing a stale closure over the retry count.

This takes a minute but saves hours of future archaeology.

3. Use Session-Aware Tools

This is where tooling can genuinely help. If you're using terminal-based AI assistants like Claude Code, Codex CLI, or Gemini CLI, your sessions contain rich context — terminal I/O, code diffs, the full back-and-forth with the AI.

Tools like Mantra are designed specifically for this: they record your AI coding sessions and let you replay them later. Think of it as a DVR for your coding process. When you need to recall how you solved something, you browse your session history instead of relying on memory.

The key value isn't anything fancy — it's simply having a convenient way to look back at what happened. No more "I know I solved this before but can't remember how."

4. Create Session Summaries

If you don't want to use dedicated tools, build a lightweight habit. After a significant AI-assisted coding session, spend 2 minutes writing a summary:

## 2026-03-10: Auth Token Refresh Fix

**Problem:** Access tokens weren't refreshing properly, causing 
401 errors after 1 hour.

**Key prompts that worked:**
- "Trace the token lifecycle from login to expiry"
- "Show me where the refresh interceptor might miss a concurrent request"

**Solution:** Added a request queue that holds pending requests 
during token refresh. Mutex pattern.

**What I learned:** The interceptor was correctly catching 401s 
but not queuing simultaneous requests — they'd all trigger 
independent refresh calls.

5. Review Before You Start

Before starting a new AI coding session on a familiar topic, take 30 seconds to check your previous sessions or notes on the same topic. This simple habit compounds dramatically:

You start with better prompts (building on what worked before)
You avoid known dead ends
You build on previous context instead of starting from zero

The Bigger Picture

AI coding assistants are incredibly powerful, but we're still in the early days of figuring out the workflow around them. Right now, most of us treat AI sessions as disposable — use them and throw them away.

But consider how we treat other development artifacts:

Code → version controlled (git)
Decisions → documented (ADRs, RFCs)
Bugs → tracked (issue trackers)
Knowledge → shared (wikis, docs)

AI coding sessions? → Currently: nothing. They just disappear.

This gap will close over time, whether through better tooling, better habits, or both. The developers who figure it out early will have a meaningful advantage — not because of any single session, but because of the compound effect of preserved knowledge over months and years.

Start Small

You don't need to overhaul your workflow. Pick one thing from this article:

Start saving prompts that work well
Write better commit messages after AI-assisted fixes
Try a session recording tool
Create a 2-minute summary habit

The goal isn't perfection. It's simply to stop losing the valuable work that happens between your problem and your solution.

What's your approach to preserving AI coding session context? I'd love to hear what works for you in the comments.

I Just Want to Look Up What I Asked Claude Last Tuesday

decker — Tue, 10 Mar 2026 00:30:08 +0000

Every developer using AI coding assistants has this moment:

"Wait, how did I fix that auth bug last week? I spent 45 minutes with Claude on it..."

You open your terminal history. Useless. You check your git log. Just commit messages. The actual conversation — the prompts you tried, the reasoning, the code states at each step — gone.

The Problem Nobody Talks About

We generate dozens of AI coding sessions per week. Each one contains valuable context:

The exact prompts that worked (and the ones that didn't)
Why you chose approach B over approach A
The intermediate code states before the final solution
Terminal outputs that led to breakthroughs

But there's no good way to go back and look at any of it.

Your browser history shows "claude.ai" 47 times. Super helpful.

What I Actually Wanted

I didn't want a fancy workflow tool. I didn't want to "transform my coding process." I just wanted to:

Find that session where I debugged the WebSocket reconnection issue
See the exact prompts I used
Look at the code at each step of the conversation

That's it. A history viewer for AI coding sessions. Like browser history, but actually useful.

The Real Cost of Forgetting

I tracked this for two weeks. Here's what I found:

3-4 times per week I wanted to reference a previous AI session
~20 minutes each time spent trying to recreate the context
About 1-1.5 hours per week wasted on re-prompting things I'd already solved

Multiply that across a team of 5 developers and you're losing a full workday every week.

What Good Session History Looks Like

After experimenting with different approaches, here's what actually matters:

Searchable conversations. Not just full-text search, but being able to find sessions by the problem you were solving, the files you touched, or the tools you used.

Code state at each step. When you're replaying a session, you want to see what the code looked like at message #5, not just the final result.

Terminal context. Half the debugging happens in the terminal. If your session replay doesn't include terminal input/output, you're missing the plot.

Works across tools. I use Claude Code, sometimes Cursor, occasionally Codex. My session history shouldn't be locked to one tool.

Building This

I've been working on Mantra to solve exactly this. It records your AI coding sessions — the full conversation, terminal I/O, and code changes — and lets you replay them later.

The key insight: it's not about changing how you code. It's about being able to look back at how you coded. Big difference.

A few things I learned building it:

Recording needs to be invisible. If it adds any friction to your workflow, you'll turn it off.
Replay needs to be fast. You're looking for one specific moment, not watching a movie.
Security matters. Your coding sessions contain API keys, credentials, internal URLs. Built-in sensitive content detection and redaction isn't optional — it's mandatory.

Try It

If you've ever wished you could just look up what you asked your AI assistant last Tuesday, give Mantra a try. It's free and works with Claude Code, Cursor, Codex, and Gemini CLI.

The setup takes about 2 minutes, and after that it just runs in the background. No workflow changes required.

What's your current approach for keeping track of AI coding sessions? I'm curious whether others have found workarounds or if everyone's just re-prompting from scratch.

How to Debug Multi-Agent AI Systems: Session Replay for LLM Workflows

decker — Sat, 07 Mar 2026 23:24:20 +0000

You just watched your AI agent make a terrible decision. It sent the wrong email. It queried the database with the wrong filter. It hallucinated a fact and ran with it.

Now you have to figure out why.

Traditional debugging is hard enough. But with LLMs, it gets exponentially worse because every interaction is non-deterministic. Re-running the same prompt with the same input gives you a different output. The bug is gone. You're back to square one.

The Problem: AI Debugging is Broken

Here's what happens in most teams right now:

Agent makes a mistake → You get an error message or wrong output
You try to reproduce it → The agent behaves fine this time (different LLM response)
You add logging → You sprinkle console.log() or similar everywhere
You trace execution → Manually follow the decision tree to find where it diverged
You're still lost → What was the exact prompt? What was the LLM thinking?

This is where session replay comes in.

Session Replay: Record Everything, Debug Anything

The core idea is simple: record every decision point in your AI workflow, then replay it to understand what happened.

What you capture:

Every LLM prompt (exact text sent to Claude/GPT)
Every LLM response (with tokens, confidence scores if available)
Every tool invocation (what your agent called, what it got back)
Every decision (why the agent chose path A over path B)
Code changes (what the agent actually modified in your codebase)
Time travel (jump to any point in the session and inspect state)

Real Example: The Email Bug

Your agent is supposed to send payment reminders. Yesterday it sent 500 emails to the wrong customers.

Without replay: You manually trace through logs, reconstruct what happened, add a fix, and hope it works.

With replay: You jump to the exact moment the agent decided who to email. You see:

The prompt: "Send payment reminders to customers with overdue invoices"
The LLM response: ["customer_1", "customer_2", ...] (the bad list)
Why it was bad: The agent queried overdue_invoices table but didn't filter by active=true
The fix: Add one more constraint to the prompt or tool definition

Time saved: 2 hours vs 10 minutes.

Why This Matters for Teams

1. Faster Debugging

Instead of: "Let me add more logging and re-run this"

You get: "Let me jump back to the decision point and inspect the exact LLM reasoning"

2. Knowledge Preservation

When one engineer debugs an agent issue, they can save that session as a reference. Other engineers can replay it and learn.

3. Training Your Agents

Replay successful agent interactions to train new ones. Share "how agent X solved this problem" as a replayable workflow.

4. Audit Compliance

For regulated industries (fintech, healthcare), replay gives you a full audit trail: what the agent decided, why, and when.

How to Build Session Replay

Here's a minimal implementation:

from dataclasses import dataclass
from datetime import datetime
from typing import Any
import json

@dataclass
class SessionEvent:
    timestamp: datetime
    event_type: str  # "prompt", "response", "decision", "tool_call"
    data: dict[str, Any]

class SessionRecorder:
    def __init__(self):
        self.events = []

    def record_prompt(self, prompt: str, model: str):
        self.events.append(SessionEvent(
            timestamp=datetime.now(),
            event_type="prompt",
            data={"prompt": prompt, "model": model}
        ))

    def record_response(self, response: str, tokens: int = None):
        self.events.append(SessionEvent(
            timestamp=datetime.now(),
            event_type="response",
            data={"response": response, "tokens": tokens}
        ))

    def record_decision(self, decision: str, reasoning: str):
        self.events.append(SessionEvent(
            timestamp=datetime.now(),
            event_type="decision",
            data={"decision": decision, "reasoning": reasoning}
        ))

    def replay(self, from_index: int = 0):
        """Replay from a specific point in the session"""
        return self.events[from_index:]

    def export(self) -> str:
        return json.dumps([
            {
                "timestamp": e.timestamp.isoformat(),
                "type": e.event_type,
                **e.data
            }
            for e in self.events
        ], indent=2)

# Usage
recorder = SessionRecorder()
recorder.record_prompt("Summarize this article", model="gpt-4")
recorder.record_response("The article discusses...")
recorder.record_decision("send_email", reasoning="User asked for summary, article is relevant")

# Later: replay the exact sequence
print(recorder.export())

But real session replay needs more:

Distributed tracing (across multiple agents/services)
Time-travel debugging (inspect state at any point)
Full code diffs (what actually changed in your codebase)
Search (find sessions that match a pattern)
Sharing (send a replay to a teammate)

The Tools Landscape

MCP (Model Context Protocol) handles agent-to-tool communication, but doesn't record sessions.

Bee/Claude agents capture some context, but not in a replayable format.

Session replay for AI is still new. The best tools right now are:

Mantra — Full session replay for AI workflows (open source, self-hostable)
PostHog — Product analytics + session recordings (but not AI-specific)
Datadog — Enterprise observability (heavy, expensive)
LangSmith — LLM observability (limited to LangChain)

Next Steps

If you're building multi-agent systems, start here:

Instrument your agents — Log every LLM call, tool invocation, and decision
Store events sequentially — Timestamp everything, keep the order
Build a replay viewer — Let engineers jump to any point and inspect state
Share replays — Make it easy to send a session to a teammate for debugging

The difference between blind debugging and session replay debugging is the difference between guessing in the dark and having a video recording of exactly what happened.

Have you hit this problem with your AI agents? How do you currently debug them? Drop a comment below — I'd love to hear your approach.

Claude Code session replay: what I learned after 10 days of tracking every AI decision

decker — Mon, 02 Mar 2026 04:11:15 +0000

I almost gave up on Claude Code three weeks in.

Not because it was bad — it was genuinely impressive. But I kept running into the same wall: I'd start a session with clear context, make real progress, and then hit the session limit. The next day I'd pick it up again, spend 20 minutes re-explaining everything, watch Claude confidently make a decision I'd already tried and discarded, and lose another hour undoing it.

That's when I started tracking every AI decision I made. Every single one. For 10 days straight.

What I learned changed how I think about AI-assisted development entirely.

Why I Started the Experiment

The trigger was a specific failure. I was building a data pipeline, and Claude had helped me design an elegant solution using a particular caching strategy. We talked through the tradeoffs, I pushed back on one approach, Claude agreed and we went with something simpler.

Three sessions later, Claude proposed the exact caching strategy we'd already ruled out. With the same reasoning. I said "we already tried this," and of course Claude had no idea what I meant.

I started wondering: how much time was I actually losing to this? How many decisions were getting re-litigated? How much of my Claude Code workflow was just... rebuilding context?

So I built a simple tracker. A markdown file per session, timestamped, with three fields for each decision point: what the AI proposed, what I decided, and why.

The Tracking System

Nothing fancy. I kept a decisions.md file in every project root:

## Session 2026-02-15

### Decision: API retry logic
- Proposed: Exponential backoff with jitter, max 5 retries
- Decided: Simple 3-retry with fixed 2s delay
- Why: External API has rate limits that make jitter counterproductive; simpler to reason about

### Decision: Error handling strategy
- Proposed: Custom error classes per domain
- Decided: Keep native errors, add context via cause chain
- Why: Team is small, over-engineering error taxonomy costs more than it saves

By day three, I had something unexpected: a searchable record of my own thinking. Not Claude's thinking — mine. The decisions I made when I had full context, when I was fresh, when I understood the problem completely.

I also started adding a "context dump" at the top of each session's section — a one-paragraph summary of where the project stood, what constraints were in play, and what I was trying to accomplish that day. This became the thing I'd paste into Claude at the start of each session.

What the Data Showed

After 10 days, 23 sessions, and 147 logged decision points, some patterns were hard to ignore.

Context decay is real and measurable. On average, I was spending 18 minutes per session re-establishing context before I could do productive work. That's 25% of a typical 70-minute coding session gone before writing a line. Across 23 sessions, that's roughly seven hours of lost time in just ten days.

The most expensive decisions were the ones made in session 1. Architecture choices, data model decisions, API contract decisions — these came up again in later sessions, and without the log, Claude would sometimes propose alternatives that seemed reasonable in isolation but contradicted earlier choices. I watched this happen four distinct times. Each one cost at least 30 minutes to untangle.

"Why" was the hardest thing to capture. It was tempting to just log what I decided. But the reason mattered more. "We went with SQLite because we need zero-config deployment" is worth ten times more than "we went with SQLite." The bare decision without reasoning is almost useless in a later session. Claude can read that we chose SQLite but won't know not to suggest PostgreSQL unless it knows why.

I was better at decisions early in sessions. Looking back at the logs, my reasoning in session-start notes was cleaner and more considered. By the end of long sessions, I was making decisions faster and documenting less. Session fatigue is real. The decisions I made in the last 15 minutes of a long session were consistently lower quality. Logging made this visible.

Not all context loss is Claude's fault. I'd expected to find that Claude was the weak link — it forgets, sessions expire, the context window has limits. That's all true. But I also found that I was inconsistent. I'd remember a decision differently than how I'd logged it. My mental model of the codebase drifted from reality. The log was often more accurate than my own memory.

The Workflow That Actually Worked

By day 7, I'd settled into a rhythm:

# Start of every session
cat decisions.md | tail -50  # Review recent decisions
# Paste the last 5-10 entries into Claude as context

# Template I evolved to use:

## Session context for Claude:
Recent decisions that affect this work:
- [date] Chose X over Y because Z
- [date] Rejected approach A — creates problems with B
- [date] Constraint: must maintain backward compat with API v1

Current goal: [specific, scoped task]
Out of scope today: [things Claude might try to fix that I don't want touched]

The difference was immediate. Sessions started faster. Claude stopped re-proposing rejected approaches. I stopped repeating myself.

But it was also manual. Every session, I was copy-pasting context. Every session, I was making sure the log was updated before I closed the terminal. I built a small shell alias to remind me:

alias end-session='echo "Update decisions.md before you close this terminal"'

Embarrassingly low-tech. But it worked.

The Hidden Cost I Hadn't Accounted For

Midway through the experiment I noticed something I hadn't expected: the tracking itself was making me make better decisions in real time.

Knowing I'd have to write down "why" forced me to actually think it through before committing. A few times I started writing the reasoning and realized mid-sentence that I didn't actually have a good reason — I was just going with Claude's suggestion because it sounded fine and I was tired.

The log introduced a small amount of productive friction. Not enough to slow down the work, but enough to catch the low-effort decisions.

This is the part that doesn't show up in productivity numbers. The decisions I didn't make badly because I had to justify them in writing.

What I Was Actually Missing

About a week in, I found Mantra while looking for tools that handled this kind of tracking automatically.

The core idea aligned with what I'd been doing manually: every AI action gets bound to a git snapshot. Every decision Claude Code makes is recorded alongside the exact state of the codebase at that moment. Session replay means you can go back to any point in the AI's work on your project and see what it did, why, and what the code looked like.

What took me a week to build a rough manual version of — Mantra does automatically, and ties it to something even more useful than a markdown log: actual git history. You can go back to any checkpoint, see what Claude proposed, see what the code looked like at that moment, and replay or branch from there.

The session replay piece in particular was what I'd been missing. Not just "what did we decide" but "what did the codebase look like when we decided it." That context is the difference between a decision log and actually understanding why the code is the way it is.

I've been using it for the past week instead of my manual system. The friction of context re-establishment has dropped significantly. I spend maybe 5 minutes at the start of a session instead of 18.

What I'd Tell Someone Starting Out

If you're using Claude Code seriously and not tracking decisions, you're losing time to a problem that's easy to fix. The productivity gains from AI assistance are real, but they come with a hidden cost: your context is ephemeral, the AI's memory is ephemeral, and the combination creates a slow bleed of time and quality.

A few things that actually helped:

1. Log the "why," not just the "what."
The decision itself is secondary. In three weeks, you won't remember why you picked approach A. Future-you (and future Claude) needs the reasoning. Force yourself to write one sentence of justification for every non-trivial decision.

2. Scope sessions aggressively.
Smaller, focused sessions with clear exit criteria lose less context than marathon sessions that sprawl across three subsystems. I started ending sessions at natural decision points rather than when I ran out of time or energy.

3. The session boundary is where quality drops.
The handoff between sessions is the highest-risk moment in AI-assisted development. Whatever system you use — manual logs, automated tools, anything — make the session boundary explicit and handled. Don't just close the terminal.

4. Your past decisions are architecture documentation.
After 10 days, my decisions.md was more useful than my README for understanding the project. The reasoning trail told the story of the system in a way that code comments and docs never do. It's the "why the code is this way" document you never have time to write.

5. Track what you rejected, not just what you chose.
The rejected alternatives are often the most valuable part. "We didn't use Redis because X" is load-bearing information. Someone (or some AI) will propose Redis again. You need the rejection reason on record.

The Numbers

After 10 days of tracking:

147 decision points logged across 23 sessions
~7 hours estimated lost to context re-establishment across the experiment
4 decisions explicitly flagged as "don't propose this again" that would have been re-proposed without the log
Avg session start time dropped from 18 minutes to about 8 minutes by day 10 (using the context-paste workflow)
3 times the log caught me making a decision I couldn't justify

The ROI of spending 2-3 minutes per session updating a decision log: real and measurable. The ROI of automating it entirely: the direction I've moved toward.

Where to Go From Here

If you want to try the manual version, start with a single project and commit to logging every non-trivial decision for a week. Just the decision and the reason. See what you learn about your own workflow.

If you want to see what automated session replay looks like, Mantra is worth checking out: mantra.gonewx.com. It's open source and designed to work alongside Claude Code, not as a replacement. The session replay feature is the part I'd been trying to build manually.

The goal isn't to make AI development frictionless — some friction is useful. The goal is to make sure the friction you're experiencing is productive friction, not just entropy from context decay.

Ten days of logging taught me that most of the friction I was experiencing was the second kind. And most of it was fixable.

How I use Mantra to audit what my AI coding assistant actually did

decker — Sun, 01 Mar 2026 20:03:42 +0000

I have been using AI coding assistants daily for about a year now -- Claude Code mostly, with some Cursor mixed in. They are genuinely useful, but there is a problem I kept running into: after a long session, I had no clear idea what the AI actually did.

Not in a paranoid way. More like: I asked it to refactor a module, it made changes across several files, and then I realized I could not reconstruct the sequence of what happened. Which file changed first? What was the prompt that triggered that particular edit? Did it touch anything it was not supposed to?

I tried keeping notes. That lasted about two days.

Finding Mantra

A few weeks ago I came across Mantra. The tagline is "AI coding session time machine" -- replay, control, secure. I was a bit skeptical but tried it anyway since it is free and does not require an account.

The setup took maybe five minutes. Mantra works as an MCP (Model Context Protocol) gateway, sitting between your AI tool and the outside world. For Claude Code you just add it to your MCP config. Same for Cursor and Gemini CLI.

Session Replay in practice

The feature I use most is Session Replay. After a coding session, I can open the timeline and see every tool call the AI made -- file reads, writes, shell commands, everything -- in the order it happened, with the associated prompt context.

This sounds minor but it changed how I review AI work. Before, I would just look at the git diff and try to reason backwards. Now I can watch the session like a log:

Prompt: "add input validation to the signup form"
AI reads auth/signup.ts
AI writes auth/signup.ts (adds zod schema)
AI reads auth/tests/signup.test.ts
AI writes auth/tests/signup.test.ts (adds test cases)

That is the happy path. What I actually found useful was catching the deviations. In one session the AI quietly read a config file that had nothing to do with the task. Not malicious, just scope creep. The replay made it visible immediately.

Sensitive content detection

Mantra also flags potentially sensitive content passing through the session -- things like API keys, tokens, or credentials that end up in prompts or responses. This has caught me twice when I accidentally included an .env file in context. The AI never did anything bad with it, but I would rather not have that data flowing through at all.

The detection is not perfect -- it does not catch everything -- but it is a useful second layer of attention.

The MCP Unified Gateway

If you use multiple AI tools, the gateway aspect is worth noting. Instead of configuring MCP servers separately for Claude Code and Cursor, Mantra acts as a single proxy. You configure your MCP tools once in Mantra and both clients pick them up. Less duplication, and the audit log covers everything regardless of which tool you used.

I mostly use Claude Code so this is not a huge deal for my workflow, but I can see it being valuable in team settings where different people prefer different editors.

What it does not do

To be fair: Mantra is not a code review tool. It does not tell you whether the AI changes were correct, only what it did. You still need to read the diff and test things. It also does not integrate with git directly -- the session log and your version history are separate things.

I also noticed the UI is still fairly early-stage. Functional, but not polished. Filtering through long sessions could be easier.

Worth trying

If you use Claude Code, Cursor, or similar tools heavily, the visibility gap is real. You are handing over significant editing power to a system that does not narrate its own actions very well. Mantra fills that gap in a straightforward way.

It is at mantra.gonewx.com, free, no signup required. The setup docs are clear enough that you will not need more than ten minutes to get it running.

I am not affiliated with them -- just found it useful and figured it was worth sharing.

I spent 10 days promoting my indie dev tool — here’s what actually worked (and what completely failed)

decker — Sun, 01 Mar 2026 18:07:09 +0000

Three weeks ago I launched Mantra, a CLI tool that helps developers manage environment variables and secrets across projects without the usual copy-paste chaos. I gave myself 10 days to promote it as hard as I could, tracking everything obsessively. Here's the unfiltered breakdown.

The numbers upfront: 196 downloads, 22 Dev.to articles, 41 GitHub PRs submitted to awesome-lists, 1 Reddit ban, at least 1 HN shadowban, and a Twitter account with 0 followers that I basically talked to myself on.

What I thought would work (but didn't)

I posted to r/programming, r/webdev, r/devtools, and r/IndieHackers. My first post got 3 upvotes and a comment telling me to "just use .env files." My second post got removed for self-promotion. My third post got me banned from r/programming.

The frustrating part: I wasn't spamming. I tried to add value — asking questions, sharing the problem I was solving, mentioning Mantra only at the end. Didn't matter. Reddit's spam filters are brutal for new accounts, and the community gatekeeping for dev tools is real.

What I'd do differently: Spend 3-4 months being a genuine Reddit contributor before ever posting about your own project. There's no shortcut.

Hacker News

I submitted to Show HN on day 1. Got 2 points. I later found out through a third-party HN analyzer that my account might have been shadowbanned — my posts weren't appearing in "new" for other users. I never got confirmation from YC, but the engagement pattern was a giveaway.

Lesson: HN is incredibly high-value if it works, but it's a coin flip for new accounts promoting their own stuff. Don't make it your primary channel.

Twitter / X

I created a fresh account to document the journey. Zero followers, zero reach. I posted daily updates, screenshots, and tips. My best tweet got 4 impressions.

Twitter without an existing audience is shouting into a void. I knew this going in but tried anyway. Confirmed: the void doesn't care.

What actually moved the needle

Discord communities

This was the biggest surprise. I joined about 15 developer Discord servers — general programming ones, language-specific ones, indie hacker communities. I spent the first day or two just helping people, answering questions, being useful.

When I eventually mentioned Mantra in context ("I built something that solves exactly this problem I see you're having"), the reception was completely different from Reddit. People were curious. They asked questions. Several joined a feedback thread I set up.

Discord gave me maybe 60-70 of my 196 downloads. More importantly, it gave me actual user conversations that shaped the next version.

The key: lead with helpfulness, not promotion. This sounds obvious but it's easy to skip when you're eager to show off what you built.

Dev.to articles

I wrote 22 articles over the 10 days. Not all about Mantra directly — more like:

"How I manage secrets across 8 side projects without losing my mind"
"The .env file problem nobody talks about"
"CLI tools that changed how I work in 2024"

Mantra came up naturally in those posts as the tool I built to solve these problems. The articles that did best were the ones where the tool was almost incidental — the real value was the underlying problem discussion.

Dev.to gave me consistent, slow-burn traffic. No single article went viral, but they kept bringing in 5-10 downloads a day even after I stopped actively promoting. The SEO value alone makes it worth the effort.

GitHub awesome-lists

This one took the most time but has the best long-term payoff. I submitted 41 PRs to various awesome-* repositories on GitHub:

awesome-cli-apps
awesome-devtools
awesome-developer-experience
awesome-shell
awesome-dotenv (this one was obvious)
... and about 36 others

About 28 of those PRs got merged. Being listed in an awesome-list is low-key one of the best forms of passive discovery for dev tools. Developers actually browse these lists when they're looking for tools.

Time investment: roughly 2 hours total. Return: ongoing discoverability that doesn't decay.

The numbers broken down

Channel	Downloads	Time spent
Discord	~70	4 days
Dev.to articles	~55	5 days
GitHub awesome-lists	~40	2 hours
Reddit (before ban)	~15	1 day
HN	~10	30 min
Twitter	~6	3 days

The Twitter ROI is genuinely embarrassing. 3 days of effort for 6 downloads. Never again (without an existing audience).

What I wish I'd done differently

Start with content, not promotion. The Dev.to articles worked because they provided standalone value. I should have written 10 articles before launching, building an audience first.

Document the build in public. The indie hacker community responds well to build-in-public stories. If I'd been writing about building Mantra for 2-3 months before launch, the launch would have landed differently.

Focus on fewer channels. I spread myself thin trying everything simultaneously. Discord + Dev.to + GitHub PRs would have been enough. The Reddit and Twitter experiments cost me time I could have spent talking to actual users.

Talk to users sooner. I spent too much time broadcasting and not enough time in conversations. The best feedback I got came from Discord DMs and Dev.to comments — not from metrics.

Where Mantra is now

196 downloads in 10 days isn't life-changing, but it's enough to confirm people have the problem I'm solving. I've got a small but growing group of users giving me feedback, and the awesome-list placements keep sending a trickle of new installs.

If you're managing secrets and environment variables across multiple projects, give Mantra a try. It's free, open source, and the setup takes about 5 minutes.

And if you're about to launch your own tool: skip Twitter for now, be genuinely helpful on Discord before mentioning your thing, and write content that would be valuable even if your product didn't exist.

The promotion game is slow. That's probably fine.

I tried 3 different ways to fix Claude Code's memory problem — here's what actually worked

decker — Fri, 27 Feb 2026 05:03:56 +0000

I lost a full afternoon's work last week.

Four hours of debugging a gnarly database migration, maybe 30 back-and-forth messages with Claude Code about the exact schema evolution. Then I closed the terminal, came back after dinner, started a new session — and Claude had no idea what we'd figured out. The CLAUDE.md I'd written was vague. The git commits were there but the why was gone.

This is the Claude Code memory problem, and if you code with AI tools regularly, you've hit it. Each session is a blank slate. The context you built up — the decisions, the dead ends, the "wait, we tried that and it failed because..." — evaporates.

I spent the last couple weeks trying three different approaches. Here's what happened.

The problem in concrete terms

Before I get into solutions, let me be specific about what I was trying to solve. There are actually two distinct problems people conflate:

Problem A — Intra-session compaction: Claude Code compacts conversation history during a long session to stay within context limits. You lose early conversation detail while still coding. Annoying but manageable.

Problem B — Cross-session continuity: You close the terminal. New session tomorrow. Claude knows nothing of yesterday's decisions. This is the one that kills me.

I was mostly solving Problem B. Keep that in mind as you evaluate these approaches.

Approach 1: The CLAUDE.md + structured notes system

What it is: You maintain a CLAUDE.md at the project root, and you religiously update a notes/ folder with session summaries after each coding session.

How I set it up: I created notes/YYYY-MM-DD.md files after each session, writing 5-10 bullet points of "what we decided and why." The CLAUDE.md pointed Claude to read these files at the start.

What worked: Claude actually got surprisingly good at picking up context from well-written notes. If I took 3 minutes at session end to write "decided to use optimistic locking instead of row-level because of X", the next session started with that knowledge intact.

What didn't: The discipline. I skipped writing notes maybe 40% of the time — usually when I was tired, or when the session ended in frustration. Those were exactly the sessions where the context mattered most. Also, notes are lossy. They capture what I thought was important, not what Claude actually found important during the conversation.

Verdict: Works if you're disciplined. I'm not always disciplined.

Approach 2: SQLite memory layer via MCP

A few people in r/ClaudeAI have been building local SQLite-backed memory servers that expose themselves as MCP tools. The idea: Claude writes key facts to a database during the session, reads them back at the start of the next one.

What I tried: I found a few open-source implementations, set one up. The MCP server runs locally, Claude Code connects to it and has access to remember() and recall() type tools.

What worked: When Claude remembered to use it, it was actually pretty good. I'd ask it to remember a decision, and it would. The memory persisted across sessions because SQLite is durable.

What didn't: Two issues. First, Claude doesn't always reach for the memory tool when you'd want it to. You have to prompt it or add instructions to CLAUDE.md to remind it to save decisions. It's not autonomous. Second — and this one surprised me — it saves semantic knowledge but not state. It can remember "we decided on optimistic locking" but it can't tell me "at the point where we made this decision, the schema looked like this." There's no connection to what the code actually was at that moment.

Verdict: Good for explicit knowledge. Weak on tying memory to code state.

Approach 3: Session replay tied to git state

This is what I ended up landing on. The tool is Mantra — it records your AI coding sessions and links each message to the corresponding git state. So you can actually scrub back through a past session and see what the code looked like at the moment a decision was made.

What worked: The time travel part is genuinely useful. I was debugging something last week, hit a wall, and scrubbed back through a session from 3 days ago to find the exact moment we refactored a function that I suspected was the cause. Took maybe 2 minutes. Without this I'd have been reading git history trying to reconstruct the narrative.

The replay also captures context I wouldn't have thought to write down in notes — the questions I asked, the paths Claude suggested and I rejected, the chain of reasoning. That stuff is often more useful than the final decision.

What didn't: The tool is local-first and currently pretty minimal. It doesn't write memory back to Claude — it's a read/review tool, not an automatic context injection system. You have to actually look at it. For cross-session continuity, I still start sessions by briefly reviewing relevant past sessions, then writing a tighter prompt with what I found. It's manual but at least the information is there.

Verdict: The best solution for recovering context after the fact. Doesn't solve the "Claude starts fresh" problem automatically, but makes the manual recovery process much faster.

What I actually do now

Combination approach. The SQLite MCP handles explicit "remember this" moments. Mantra captures the full session history so I can review it later. And I write CLAUDE.md notes, but shorter and more ruthlessly selective — only the non-obvious stuff.

For most projects, this gets me maybe 80% of the continuity I want. The remaining 20% is the stuff I genuinely can't reconstruct: the nuanced direction we were heading, the three alternatives Claude laid out in detail that I said "let me think about that."

That part I've made peace with losing. You can't have perfect memory in a tool that was designed session-by-session. What you can do is recover faster when you need to.

The uncomfortable truth

None of these solutions are great. They're workarounds for a tool design limitation.

The real fix would be native session persistence — where Claude Code can optionally pull in relevant history from past sessions automatically, without you having to manually manage CLAUDE.md files or MCP memory servers. Some people are building toward this. A few GitHub issues on the Claude Code repo have been open for a while requesting exactly this feature.

Until then, the combination above is the best I've found. If you have a different setup that works better, I genuinely want to hear it in the comments.

If you want to try the session replay approach: Mantra is free, no account required, works with Claude Code, Cursor, and Gemini CLI.

FAQ

Does Mantra work with Cursor?
Yes — Cursor v0.40.0+ is fully supported. Gemini CLI and Codex as well.

Does the SQLite MCP approach work with other AI coding tools?
If the tool supports MCP, yes. Claude Code has solid MCP support. Cursor's is improving.

Won't all this overhead slow down my actual coding?
The session-end note-writing takes 3-5 minutes. The replay tool is passive — it records automatically. The MCP memory only costs time when you explicitly ask it to remember something. In practice the overhead is small compared to the time I used to spend reconstructing lost context.

DEV Community: decker

Cursor Session Management: How to Find, Search, and Organize Your AI Coding Conversations

The Current State of Cursor Session Management

Problem 1: Sessions Are Siloed by Project

Problem 2: Session Accumulation Without Organization

Problem 3: Disconnection Between Conversations and Code State

Problem 4: Data Ownership and Privacy

Existing Approaches and Their Limitations

Approach 1: Manual Export to Note-Taking Tools

Approach 2: Cursor's Built-in Export

Approach 3: Third-Party Open Source Tools

A More Systematic Approach

1. Global Indexing

2. Temporal Correlation

3. Local Storage

4. Cross-Tool Support

A Tool That Does This

Summary

Where Is Claude Code Session History? How to Find Your AI Coding Conversations

How Claude Code Stores Sessions

Limitations of Existing Approaches

Approach 1: Manually Browse JSON Files

Approach 2: Use grep to Search

Approach 3: Rely on Claude's Context Window

Common Problems with These Approaches

Why This Matters

Best Practices for Session Management

1. Manually Export Important Conversations

2. Maintain a Decision Log

3. Use Git Commit Messages for Context

4. Organize Sessions by Project

A More Systematic Solution

The Future of Session Management

AI Coding Tools Comparison 2026: Claude Code vs Cursor vs Gemini CLI vs Codex

1. The 2026 AI Coding Landscape

2. Deep Dive: The Four Major Tools

2.1 Cursor: The IDE Experience Benchmark

2.2 Claude Code: The Terminal King

2.3 Gemini CLI: Google Ecosystem Integration

2.4 Codex: Automated Code Execution

3. Comparison Summary: How to Choose

4. The Overlooked Dimension: Session Management

5. Mantra: The Session Management Layer for AI Coding

5.1 Cross-Tool Session Search

5.2 Time Travel: Code Timeline Replay

5.3 Local Privacy Sanitization

5.4 MCP Gateway

6. Mantra's Position: Complementary, Not Competitive

7. Conclusion

I Tested 4 Tools for Browsing Claude Code Session History

The Problem

What I Tested

1. Built-in CLI (--resume + /history)

2. claude-history (Rust CLI)

3. Claude Code History Viewer (CCHV)

4. Mantra

The Verdict

One More Thing

AI Coding: Why You Need to Record Your Complete Conversation History

The Problem Every AI Programmer Knows

Why This Keeps Happening

The Real Cost

Three Ways to Fix This

Approach 1: Manual Logging

Approach 2: Session Recording Tools

Approach 3: Team Prompt Libraries

The Bigger Picture

What About You?

Why Your AI Coding Sessions Are Worth More Than You Think (And How to Stop Losing Them)

The Hidden Cost of Forgetting

Three Real Scenarios Where Lost Sessions Hurt

1. The "I Fixed This Before" Problem

2. The Onboarding Gap

3. The Prompt Refinement Loss

What Actually Makes AI Coding Sessions Valuable?

Practical Tips to Preserve Session Value

1. Build a Personal Prompt Library

2. Document the "Why" in Commit Messages

3. Use Session-Aware Tools

4. Create Session Summaries

1. Built-in CLI (`--resume` + `/history`)