What If Your Coding Agent Could Remember What It Learned Yesterday?

A developer built Attic, an open-source knowledge persistence tool that lets AI coding assistants like Claude Code and Codex CLI save and reuse discoveries across sessions, after context compaction, and from the browser. The tool stores findings as Markdown files in a project's .attic/ folder with an INDEX.md catalogue, so agents retrieve relevant knowledge on demand instead of re-investigating the same code paths each session.

I built Attic to help Claude Code and Codex CLI remember what they discover — and now you can save knowledge from your browser too. You ask your AI coding assistant to investigate a bug. It searches the repository. Reads five files. Follows a few imports. Runs some commands. Finally, it tells you: "Found it. The authentication check happens after the desktop sub-window is created." Great. You fix the bug. A few days later, you start a new session. You ask the assistant to investigate another issue in the same area. It searches the same files. Reads the same imports. Runs the same commands. And eventually discovers the same thing you already knew. You just paid for the same investigation twice. Maybe three times. This is the problem I wanted to solve with Attic — an open-source knowledge persistence tool for AI coding assistants. But the interesting part isn't simply saving notes. It's the design behind making those notes useful across sessions, after context compaction, and now even from your browser. GitHub: https://github.com/NishikantaRay/Attic https://github.com/NishikantaRay/Attic Let's start with a simple example. Imagine you're working on a JavaScript monorepo. You ask Claude Code: "Why is the cloud package failing to load?" The assistant investigates and finds: // packages/cloud/index.js export default cloudClient; export default cloudConfig; Two default exports. The file throws a syntax error. The assistant explains the issue. You fix it. But where does that knowledge go? If you only keep the conversation, the discovery is trapped inside that session. If you start a new session, your assistant may have to rediscover the same problem. The codebase contains the bug fix, but it doesn't necessarily contain the reasoning that helped you find it . And reasoning is often what you need the next time. Suppose your project has a rule: "All desktop sub-windows must wait for authentication before rendering." But the actual implementation creates the window before the authentication gate finishes. Your assistant investigates and discovers the contradiction. That's valuable knowledge. Not just: There is a bug. But: The desktop sub-window can be created before the authentication gate completes, despite the documented requirement. That tells the next investigation where to look. It also tells a teammate what assumption is unsafe. It explains why the code behaves the way it does. This kind of knowledge is easy to lose. And it isn't limited to bugs. It includes: Your codebase is a library of implementation. Your AI assistant's discoveries are the notes in the margins. The question is: Where do those notes live? Attic is an open-source tool designed to help AI coding assistants persist and reuse knowledge. It works with: The idea is straightforward: Write what you learn to a file. Keep a small index in context. Retrieve the details when you need them. No need to put every discovery into the assistant's context forever. No need to rebuild the same understanding from scratch every session. And no need to turn your entire repository into a giant collection of instructions. Attic gives the agent a place to store useful discoveries. Think of it as a small knowledge library inside your project. Imagine you have a library. You have 200 books. You don't carry all 200 books around with you. You carry a catalogue. The catalogue tells you: When you need a particular book, you look it up. Attic follows the same idea. .attic/ folder is the library A typical Attic knowledge folder contains Markdown files: .attic/ ├── INDEX.md ├── DECISIONS.md └── items/ ├── f1.md ├── f2.md ├── f3.md └── ... The exact files and commands depend on the installed version, but the core concept is consistent: The knowledge lives on disk. The index helps the agent find it. INDEX.md is the catalogue card The index is not supposed to contain every detail. It's a compact representation of what matters. For example: Attic Index Pinned - f3: Authentication must complete before desktop sub-windows are created. Recent findings - f12: Cloud package has duplicate default exports. - f11: API client is initialized in the shared module. - f10: The docs and implementation disagree about the authentication lifecycle. Older items 95 older items not shown. Use /attic-recall <topic . This is an illustrative example of the idea, not a claim about the exact generated format. The agent can see the important information without loading the entire knowledge base into every prompt. When more detail is needed, it can recall the relevant item. That's the distinction: The index is the catalogue. The Markdown files are the books. This is a reasonable question. If the assistant needs the information, why not inject all of it? Because context is limited. And even when you have enough context, more context isn't automatically better. Imagine an assistant working on a project with 200 findings. If every finding is included in every session, the prompt becomes filled with: The agent now has to spend attention deciding what matters. Attic takes a different approach. Attic's runtime includes logic for loading the index and keeping its injected representation compact. The repository's design notes describe an index that prioritizes pinned findings, recent items, and compact summaries for older knowledge. The important idea is not a magic token number. It's this: Don't force the assistant to carry the entire library when a catalogue will do. Suppose the agent is investigating authentication. It doesn't need to read every database discovery, UI decision, and deployment note. It needs the authentication-related knowledge. That's where recall becomes useful. Attic's commands are organized around a simple workflow. stash — save what you learned After an investigation, save the discovery. Example: /attic-stash The exact command options depend on the installed version. Conceptually, you are turning an ephemeral chat discovery into a persistent Markdown item. Instead of: "I think the auth gate is somewhere in the desktop code." You save: Authentication gate and desktop sub-windows The desktop sub-window creation path can run before the authentication gate completes. When investigating window lifecycle bugs, check the auth gate before the window creation path. Tags: - authentication - desktop - lifecycle Now that discovery has a home. recall — find what you already know Later, you can ask Attic to retrieve relevant knowledge. /attic-recall authentication The assistant can use the stored findings instead of starting from zero. This is particularly useful when: /compact . index — inspect the catalogue The index helps you understand what the agent can see. /attic-index The idea is to inspect the compact catalogue rather than opening every item. pin , prune , and archive — manage the shelf Not every discovery deserves permanent prominence. Some knowledge is important forever. Some is useful for a week. Some becomes obsolete after a refactor. Attic provides commands for managing that lifecycle: /attic-pin /attic-prune /attic-archive The exact syntax depends on the version and installed commands. The important design decision is that knowledge needs management. A memory system that only writes and never cleans up eventually becomes another source of noise. This is the design detail worth understanding. A common approach to agent memory is: Store a large amount of information and inject it into the next prompt. Attic separates storage from injection. The detailed findings live in Markdown files. They can contain context, explanations, file references, and reasoning. The assistant receives a compact index. The index tells it what exists and how to find it. This separation gives you a useful property: You can have a large knowledge base without making every prompt equally large. Knowledge on disk: 200 findings │ ├── Pinned findings ├── Recent findings └── Older findings └── Available through recall The assistant doesn't need all 200 findings in context. It needs enough information to navigate the collection. This is a familiar pattern in software engineering: Attic applies that idea to coding-agent memory. This is one of the reasons persistent memory matters. Imagine a long coding session. At the beginning, you ask: "Understand the authentication flow." The agent investigates. It discovers: You fix the problem. Then the conversation becomes huge. You use: /compact The context is reduced. The agent may no longer have every detail from the earlier investigation. If the key discovery existed only in the conversation, it can be difficult to recover. But if you saved it to Attic: .attic/items/f3.md The knowledge remains on disk. A later session can recall it. The discovery has survived the conversation. This is the central promise of persistent agent memory: Your knowledge should outlive the context window. Now let's talk about the feature that makes Attic particularly interesting. Most coding-agent memory tools focus on what happens inside the terminal. But developers learn things everywhere. You might discover a useful fact while reading: You might think: "This is useful. I should save it." Then you close the tab. Or forget. Or leave it in your browser history. The information never makes it into your project's knowledge base. Attic's browser companion is designed to close that gap. Instead of only remembering what the coding agent discovers, you can save useful knowledge from the browser into the same Attic shelf. That is a powerful extension of the original idea. Let's say you're investigating a bug in a Node.js application. You open a GitHub issue discussing a subtle behavior in a dependency. The issue contains the explanation you need. You don't want to copy the entire page into your project. You want to save the useful discovery. The workflow becomes: Read useful information in browser │ ▼ Clip it │ ▼ Save to Attic knowledge │ ▼ Recall it in a future session The browser becomes another input into your project memory. This is important because developers don't learn only by asking an AI agent questions. They learn by reading. And a lot of that reading happens outside the terminal. A clip is a way to capture useful browser content and save it as a knowledge item. Imagine reading this on a documentation page: "The authentication callback must complete before the desktop window is created." Instead of copying the entire article into a notes app, you can clip the useful content into Attic. The saved item might look like: Authentication callback lifecycle Source: Browser research The authentication callback must complete before the desktop window is created. This matters because creating the window too early can bypass the expected auth gate. Tags: - authentication - desktop - lifecycle Now your browser research becomes part of the same knowledge collection used by your coding agent. The exact clip UI and available options depend on the installed extension version. This is one of the most important design calls in Attic's browser companion. A tempting approach would be to build a separate browser storage system. Something like: Browser extension │ ▼ Browser database │ ▼ Browser-only notes Then the CLI would have its own memory system: CLI │ ▼ .attic/ │ ▼ CLI-only notes Now you have two systems. Two storage formats. Two sets of rules. Two places to search. Two systems to maintain. The browser companion reuses the CLI writer. The repository's design notes explicitly call out that the companion uses the existing CLI writer rather than reimplementing it. Conceptually: ┌────────────────────┐ │ Browser extension │ └─────────┬──────────┘ │ ▼ ┌────────────────────┐ │ CLI writer │ └─────────┬──────────┘ │ ▼ .attic/ │ ┌─────────┴──────────┐ ▼ ▼ INDEX.md items/ .md This is a classic software engineering principle: Reuse the existing source of truth instead of creating a second implementation. The CLI already knows how to write Attic items. The browser companion should not need to invent a different way to do the same job. That keeps the storage model consistent. It also means the knowledge saved from your browser can be used by the CLI. And knowledge saved from the CLI can be found in the same collection. One shelf. Multiple ways to put books on it. This is another design decision worth talking about. At first glance, these two actions might seem similar. You discover something new. You want to add it to the knowledge base. New discovery → Add a knowledge item You already have a knowledge item. You want to correct or update it. Existing item → Replace its content These are not the same operation. Suppose you have this finding: Authentication lifecycle The desktop window is created before the authentication callback completes. Later, you investigate more deeply and discover that the bug has been fixed. You edit the existing item: Authentication lifecycle The desktop window now waits for the authentication callback to complete. The previous behavior was caused by the window creation path running too early. You have updated the knowledge. You haven't discovered a second, unrelated fact. If editing simply appended another copy, you could end up with: Authentication lifecycle The desktop window is created before auth. --- Authentication lifecycle The desktop window waits for auth. --- Authentication lifecycle The previous behavior was caused by... Now the agent has to reconcile multiple versions. That's noise. The repository's design notes explicitly distinguish editing from stashing: Editing replaces; stashing appends. This is a small detail, but it reflects a larger principle: Memory needs both creation and correction. A knowledge system that only adds information eventually becomes cluttered with stale information. This might sound strange. If a knowledge item is wrong, why not just delete it? The design notes for Attic's browser companion call out that there is no delete endpoint. Instead, the system provides management operations such as archive and prune. There is a reason to be careful here. Deleting knowledge can be destructive. Imagine an agent saves an important architectural decision. A browser clip accidentally overwrites it. Or a user removes an item because it looks old. The information may be gone before anyone realizes it was useful. A safer approach is to separate: This is a design choice, not a universal rule. Different tools may reasonably choose different deletion models. But the principle is worth considering: Memory should be managed deliberately, not casually destroyed. The moment a browser extension can write to your project files, security becomes important. A browser extension is not the same as a trusted terminal command. It runs in a different environment. It may interact with content from arbitrary websites. It needs a way to communicate with the local Attic server. That means the design has to answer: Attic's design notes identify several of these concerns: These are important because a browser-to-local-file bridge should not behave like an unrestricted file-writing API. The companion communicates with a local server. The goal is to keep the interaction on the developer's machine rather than sending knowledge to a remote cloud service. The repository's design notes identify loopback communication as part of the implementation. This is aligned with the project's broader local-first approach. The knowledge is intended to live in the project's .attic/ directory. A local service still needs protection. Just because something runs on localhost doesn't mean every request should be trusted. Attic's browser server uses a token as part of its request validation. Browser extension │ │ request + token ▼ Local Attic server │ ▼ Validate request │ ▼ Write knowledge item The exact request format is an implementation detail. The important point is that the server isn't designed as an unauthenticated arbitrary file-writing endpoint. This is another useful security concept. Suppose the browser companion could tell the server: Write this content to: /Users/me/anything/on/my/computer That would be dangerous. A project memory tool should not be allowed to write to arbitrary locations. Attic's design notes identify a root allowlist in the server. The intended principle is: Restrict file writes to approved project roots. That limits the scope of what the companion can modify. This is particularly important for browser clipping. Imagine you are reading a page containing: API KEY=super-secret-value You click "Clip." Should that secret be saved to your project's memory? No. Attic's design notes identify a credential scan that refuses a clip containing a credential. This is a practical safeguard. But it doesn't mean every secret will be detected. You should still avoid clipping: A browser extension that can save content needs to treat sensitive information as a first-class concern. One of the things I like about Attic is that its design stays close to ordinary developer tools. The knowledge is stored as Markdown. The project can inspect it. The files can be version-controlled. And the runtime is designed around local filesystem operations rather than a cloud memory service. The repository describes the runtime as using Node.js fs and path , with no network calls in the plugin runtime. That gives the project a straightforward mental model: Your project │ ├── Source code ├── Documentation ├── Tests └── .attic/ ├── INDEX.md ├── DECISIONS.md └── items/ Your agent's memory is another part of the repository. Not a mysterious remote database. Not a separate SaaS dashboard. Not a service you need to query over the internet every time the agent needs to remember something. This is an important practical question. If the knowledge lives in your project, it can potentially be shared with the team. Developer A │ ▼ Saves an architectural discovery │ ▼ Commits .attic/ │ ▼ Developer B pulls the changes │ ▼ Agent can recall the discovery The repository notes describe .attic/ as surviving a Git clone only if it is committed rather than ignored. That distinction matters. If you want shared project memory, you need to decide: For a team project, knowledge management becomes part of the repository workflow. Let's walk through a realistic workflow. "Investigate why the desktop sub-window sometimes appears before authentication." The agent searches the codebase. packages/desktop/window.js packages/auth/gate.js packages/desktop/bootstrap.js It traces the execution path. The agent explains: "The window creation call happens before the authentication callback completes." You fix the issue. You stash the important knowledge: /attic-stash The saved item contains something like: Desktop window authentication lifecycle The desktop window creation path can run before the authentication callback completes. When investigating window lifecycle issues, check the auth gate before window creation. Relevant areas: - packages/desktop/window.js - packages/auth/gate.js - packages/desktop/bootstrap.js Tags: - desktop - authentication - lifecycle A few days later: "Why is the desktop window lifecycle failing?" The agent can inspect the Attic index and recall relevant knowledge. Instead of immediately rediscovering the entire execution path, it has a useful starting point. You discover a more precise explanation. You edit the existing item. Now the knowledge stays current. This is the lifecycle that matters: Investigate ↓ Discover ↓ Stash ↓ Recall ↓ Update ↓ Reuse It's not magic. It's a disciplined way to make discoveries persistent. It's worth being clear about the scope. Attic is not a replacement for: It's a knowledge persistence layer for coding-agent workflows. It helps preserve discoveries and make them available again. It doesn't guarantee that the assistant will always recall the right item. It doesn't guarantee that every saved finding is correct. It doesn't eliminate the need to verify facts. And it doesn't mean the agent should blindly trust old notes. A stale memory can be just as dangerous as no memory. That's why editing, pruning, and archive workflows matter. When people talk about AI coding assistants, they often focus on: Those things matter. But there is another problem: What happens to the useful knowledge after the task ends? A coding agent might discover: The API client is initialized in a shared module. That can be valuable. But if it exists only in the chat, the next session may have to rediscover it. The same is true for: These are not necessarily code changes. They are discoveries about the codebase. And they deserve a place to live. The browser extension expands the idea beyond terminal-based discovery. Developers constantly learn from external information. They read a blog post. Find a GitHub issue. Understand a framework quirk. Discover a workaround. Read a discussion about a bug. That knowledge is useful even if the AI agent didn't discover it itself. The browser companion makes it possible to capture useful information and bring it into the same local knowledge system. This creates a broader workflow: ┌───────────────┐ │ Terminal │ │ Claude/Codex │ └───────┬───────┘ │ ▼ ┌────────────┐ │ Attic │ │ Knowledge │ └────────────┘ ▲ │ ┌───────┴───────┐ │ │ ┌──────┴──────┐ ┌──────┴──────┐ │ CLI stash │ │ Browser │ │ │ │ clip │ └─────────────┘ └─────────────┘ One knowledge shelf. Different ways to add information. The same place to recall it. You can explore Attic here: The project is designed for Claude Code and Codex CLI. A typical workflow is: 1. Install Attic 2. Initialize it in your project 3. Investigate a problem 4. Stash useful discoveries 5. Recall them in later sessions 6. Manage the knowledge as it evolves 7. Use the browser companion to capture useful research For the exact installation and usage commands, follow the repository's current README and release documentation. I think the most interesting thing about AI coding assistants isn't just how much code they can write. It's how much they can discover. An agent can investigate a codebase for ten minutes and uncover something that would take a developer much longer to understand. But if that discovery disappears when the session ends, you lose part of the value. Attic is built around a simple idea: Don't make your AI coding assistant rediscover what it already learned. Write the discovery to a file. Keep a compact index. Recall the details when needed. And now, when useful knowledge comes from your browser, clip it into the same shelf. The future of AI coding assistants may not just be about giving agents more context. It may also be about giving them better ways to remember. If you use Claude Code or Codex CLI and you've ever thought: "I know we already solved this. Why is the agent investigating it again?" Attic is worth exploring. If you try it, I'd be interested to hear how you manage your agent's knowledge. What would you want your coding assistant to remember permanently?