Search your coding agent's own session history instead of re-explaining it

Open a new Claude Code session on a project you have worked in for months, and it knows nothing about the bug you already fixed twice, the approach you already rejected, or the exact command that made the flaky test pass. You either retype that context or the agent rediscovers it the slow way. Every session after the first one pays this tax, and the tax compounds with how many tools you run — Claude Code for one thing, Cursor for another, Codex or OpenCode for a third, each with its own transcript nobody reads twice.

Those transcripts already exist on disk. ctx is a local CLI that indexes them into a single searchable SQLite database, so a session can look up what an earlier session already worked out instead of starting cold. It shipped as a Show HN post on July 4, it is Rust, Apache-2.0, and at the time of writing sits at 686 stars on GitHub with the latest release (v0.19.0) cut on July 3. Young, but the mechanism does not depend on the project's age — it just reads files your tools already write.

Why this is not another "agent memory" product

The framing to get right first: ctx does not summarize your work into facts, store embeddings, or build a knowledge graph. It preserves the actual session — the messages, the tool calls, the commands, the outputs — and makes that raw record searchable by keyword, file path, or session ID. That distinction matters in practice. A summary is somebody's compressed opinion of what happened and it can be wrong in a way you will not notice until it costs you. A search hit on the actual transcript shows you the real exchange, with a session ID you can open and read in full if you want to check it. Nothing is invented in the retrieval step.

It also does not touch a model. No API key, no network call for the search itself, no cost per query. It reads files you already have and writes a local index next to them.

Setting it up (verified, not copied from the README)

Installed and ran this end to end before writing any of it down:

curl -fsSL https://ctx.rs/install | sh -s -- --no-setup

That installs the signed binary to ~/.local/bin after verifying the release metadata signature — no sudo, nothing touched outside the user's own directories. Then the indexing step:

ctx setup

On a machine with several months of mixed Claude Code, Codex, Cursor, and OpenCode history, that one command discovered all four, imported them, and reported the real counts back:

imported claude: sessions=1282 events=217905 edges=618
imported codex: sessions=3 events=3331 edges=0
imported opencode: sessions=45 events=2776 edges=0
imported cursor: sessions=8 events=143 edges=6
imported_sessions: 1724
imported_events: 241436

Everything landed in ~/.ctx/work.sqlite. No upload step exists — that is the entire pipeline. ctx sources --json will tell you which of the supported harnesses — Claude Code, Codex, Cursor, Windsurf, Zed, Gemini CLI, GitHub Copilot CLI, and roughly thirty others — it found importable data for on your machine, before you run setup for real.

Running a search against it

ctx search "railway deploy blog"

That query returned real hits from sessions weeks apart: the exact commit where a deploy decision had been made, a web search result from a later session checking the same API, and an assistant message confirming a deploy had gone out — each tagged with the session ID, the timestamp, and enough surrounding text to tell whether it is the right hit before opening the full transcript with ctx show session <id>. No retyping the decision, no scrolling back through a week of unrelated chat to find it.

The project's own benchmark claims roughly 50x less context spent per lookup than paging through a raw transcript to find the same answer — 917 tokens for a ctx search hit against 45,734 tokens to get an equivalent answer from raw transcript text. Treat that as their number, not an independently audited one, but the shape of it holds up: a six-result search on the run above returned about 11KB of text, a small fraction of what reading through the matching raw session files directly would cost.

Wiring it in so you stop typing the commands yourself

Two ways to make the agent use this on its own instead of you running ctx search by hand:

As a skill, installable across Claude Code, Codex, and Cursor:

ctx skill install

This drops the skill definition where each of those tools looks for one, so the agent can decide on its own to check prior sessions before repeating work — the same mechanism behind any other Agent Skill.

As an MCP server, if your host supports MCP tool calls over an agent-defined skill:

ctx mcp serve

This starts a read-only MCP server over stdio that exposes status, sources, search, sql, show_session, and show_event as callable tools. The agent gets structured results back — a JSON object per hit — rather than parsing CLI text output, which is the cleaner integration if you are already running an MCP-based stack.

Before you turn this on

The index is local, but it is not redacted. ctx preserves transcript text as-is, including file paths, command output, and anything that looked like a secret in the original session — so review a result before pasting it somewhere else or sharing your screen mid-search. And because it is four days old as a public project, expect the CLI surface to still move; pin the version if you are wiring ctx mcp serve into something that needs to keep working unattended.

The actual payoff is narrow and real: the next time a session needs to know whether you already tried something, it can check before repeating the attempt, instead of both of you finding out the hard way that you are debugging the same thing twice.