Every Coding Agent Session Starts by Rediscovering Your Repository

A developer built Recall, a local CLI that derives structured context from a repository and stores it inside the repository itself, aiming to eliminate the need for coding agents to rediscover the repository's structure at the start of each session. Recall uses deterministic scans rather than AI models, producing Markdown context that can be consumed by tools like Claude Code, Codex, and Cursor. The tool is published as an npm CLI and requires Node.js 22+.

I've been using coding agents heavily across real projects. Claude Code. Codex. Cursor. They are getting remarkably good at making changes. But I kept noticing the same thing at the beginning of new sessions. The agent starts exploring. It reads package.json. It looks for entry points. It walks through directories. It checks configuration. It tries to understand conventions. It finds the important files. Then the session ends. A new session starts later, and a surprising amount of that work happens again. That bothered me. Not because repository exploration is useless — an agent should inspect the source before making important changes. The problem is that there is a difference between: verifying the current source and: rediscovering the basic shape of the repository from zero. I wanted to see whether that second part could become persistent. So I built Recall. What Recall is Recall is a local CLI that derives structured context from a repository and stores it inside the repository itself. It isn't another coding agent. It doesn't call an LLM to understand your codebase. It doesn't require an AI API key. It doesn't require a cloud account. The basic idea is: repository ↓ deterministic scan ↓ .recall/ ↓ persistent repository context ↓ Claude Code / Codex / Cursor / any Markdown-capable agent The generated context can describe things Recall can derive from the repository, including: architecture entry points project conventions relevant files risks workspace structure repository state The important word there is derive. I deliberately didn't want Recall inventing architectural explanations using another model. If Recall says something about the repository, I want that information to be traceable back to repository evidence. Why not just use CLAUDE.md or AGENTS.md? I use these files too. They solve a different problem. A file like CLAUDE.md or AGENTS.md is excellent for things such as: Use pnpm. Run this command before committing. Never modify generated migrations manually. Our API errors follow this convention. Those are instructions and human knowledge. But there is another category of context: Where are the entry points? How is this monorepo structured? Which workspace owns this functionality? Which files appear relevant to this task? Has the repository changed since this context was generated? Much of that can be derived from the repository. I don't want to manually maintain it if a tool can reconstruct it deterministically. So my mental model became: AGENTS.md / CLAUDE.md ↓ human intent + instructions Recall ↓ repository-derived context Source code + tests ↓ ultimate source of truth Recall isn't supposed to replace the source. It's supposed to provide a better map to the source. The first command Recall is published as an npm CLI. Node.js 22+ is currently required. npx recall-context@latest init That initializes Recall for the repository. You can inspect its state with: npx recall-context@latest status And generate task-focused context: npx recall-context@latest context \ --task "Understand the CLI release and packaging workflow" \ --max-tokens 1200 \ --stdout The result is Markdown, so there is no vendor-specific protocol required. You can give it to Claude Code. Or Codex. Or Cursor. Or another tool capable of consuming Markdown. That portability was intentional. Task-focused context Generating a giant repository dump isn't particularly interesting. The harder question is: What parts of this repository are likely to matter for the task I'm about to perform? Recall uses deterministic signals to rank relevant files. Today that includes things such as file paths, names, symbols, workspace relationships and a bounded import graph. There are no embeddings involved. There is no semantic model secretly deciding what your application means. That has an obvious trade-off. The ranking isn't magically intelligent. But it is predictable, local and inspectable. For this version of the project, I prefer that property. Context has an expiration problem Persistent context introduces another problem: stale context can be worse than no context. Suppose an agent receives a beautiful architectural summary generated three weeks ago. The repository has changed since then. The summary still looks authoritative. Now the context is actively misleading the agent. Recall therefore keeps a snapshot and exposes repository/context state through commands such as: npx recall-context@latest status The goal isn't to pretend generated context is permanently true. The goal is to know when it should no longer be trusted without checking the repository again. This area still has limitations. The current implementation is not a perfect semantic change detector, and I don't want to present it as one. Which leads to something I've been trying to do differently with this project. What Recall does not prove I could put several attractive claims on the README: Saves tokens. Makes coding agents faster. Improves accuracy. Reduces tool calls. I haven't proven any of them. So I'm not claiming them. Recall currently proves something much narrower: I can deterministically derive reusable repository context, persist it, inspect it, and give it to different coding agents. Whether doing that materially improves a real agent workflow is an empirical question. And that's the question I'm interested in now. There are already other approaches Repository context and agent memory are becoming an active area. Some approaches use persistent memory. Some use embeddings and semantic search. Some maintain module knowledge. Others intercept file reads and replace raw files with structural summaries. Those are valid approaches. Recall is intentionally narrower. Its current constraints are: local deterministic repository-derived inspectable agent-agnostic no AI provider required I don't know yet whether those constraints are enough to make it useful. But they make the experiment interesting to me. The limitations are real Recall is early. Some important limitations today: The import graph isn't a full semantic program analysis system. Task ranking is deterministic rather than semantic. The current ecosystem support is primarily focused on JavaScript/TypeScript and related Node.js frameworks. Token estimation is approximate rather than based on each model's tokenizer. There is no native MCP integration. There is no editor plugin. There is no cloud memory layer. And I'm deliberately not building those things yet. I'm stopping feature development This is probably the most important decision I've made around Recall. Normally this is where I would start adding: MCP. Editor integrations. More languages. Embeddings. Team synchronization. A dashboard. And six weeks later I would have a much larger product without knowing whether the original idea mattered. I'm not doing that this time. Version 0.2.0 is released. The next phase is validation. I want to measure real coding tasks with and without Recall and look at things like: time to first correct edit repository exploration time tool calls before the first correct edit context/token usage correctness whether someone voluntarily uses Recall again That last metric may be the most important one. If somebody tries Recall once and never reaches for it again, it doesn't matter how sophisticated I make the scanner. Try it on a real repository If you regularly use coding agents on non-trivial JavaScript or TypeScript repositories, that's the environment I'm most interested in testing. Start with: npx recall-context@latest init Then try: npx recall-context@latest context \ --task "Describe the task you're about to give your coding agent" \ --stdout The project is open source: GitHub: https://github.com/sabahattink/Recall https://github.com/sabahattink/Recall I'm particularly interested in failures. If the generated context points you toward the wrong files, misses something important, becomes stale incorrectly, or simply doesn't improve your workflow, that's more useful to me right now than another feature request. Because the question isn't: How much can I add to Recall? It's: Is persistent, deterministic repository context useful enough that you want it again in your next coding-agent session? That's what I'm trying to find out.