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
The problem: Your AI knows more than your codebase
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
;
Enter fullscreen mode
Exit fullscreen mode
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.
Another example: Documentation versus reality
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.
Enter fullscreen mode
Exit fullscreen mode
But:
The desktop sub-window can be created before the authentication gate
completes, despite the documented requirement.
Enter fullscreen mode
Exit fullscreen mode
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:
Architectural decisions.
Repository conventions.
Failed approaches.
Important file locations.
Authentication assumptions.
Performance discoveries.
Why a particular implementation exists.
Things you should never repeat.
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?
Meet Attic: A memory shelf for your coding agent
Attic is an open-source tool designed to help AI coding assistants persist and reuse knowledge.
It works with:
Claude Code.
Codex CLI.
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.
The library analogy that makes Attic click
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:
Which books exist.
Where they are.
Which ones are important.
What each book is about.
When you need a particular book, you look it up.
Attic follows the same idea.
The
.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
    └── ...
Enter fullscreen mode
Exit fullscreen mode
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>
.
Enter fullscreen mode
Exit fullscreen mode
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.
Why not just put everything in the system prompt?
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:
Old discoveries.
Superseded decisions.
Unrelated bugs.
Details from previous tasks.
Information that may not matter to the current question.
The agent now has to spend attention deciding what matters.
Attic takes a different approach.
Keep the index small
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.
Retrieve the details when needed
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.
The four commands: Put knowledge in, get knowledge out
Attic's commands are organized around a simple workflow.
1.
stash
— save what you learned
After an investigation, save the discovery.
Example:
/attic-stash
Enter fullscreen mode
Exit fullscreen mode
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
Enter fullscreen mode
Exit fullscreen mode
Now that discovery has a home.
2.
recall
— find what you already know
Later, you can ask Attic to retrieve relevant knowledge.
Example:
/attic-recall authentication
Enter fullscreen mode
Exit fullscreen mode
The assistant can use the stored findings instead of starting from zero.
This is particularly useful when:
A new session starts.
You run
/compact
.
A teammate clones the project.
You return to an old feature.
You forgot why a particular design exists.
3.
index
— inspect the catalogue
The index helps you understand what the agent can see.
Example:
/attic-index
Enter fullscreen mode
Exit fullscreen mode
The idea is to inspect the compact catalogue rather than opening every item.
4.
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
Enter fullscreen mode
Exit fullscreen mode
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.
The part I find most interesting: The index is not the memory
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.
Storage
The detailed findings live in Markdown files.
They can contain context, explanations, file references, and reasoning.
Injection
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.
For example:
Knowledge on disk:

200 findings
│
├── Pinned findings
├── Recent findings
└── Older findings
    └── Available through recall
Enter fullscreen mode
Exit fullscreen mode
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:
Database versus index.
Filesystem versus directory listing.
Library versus catalogue.
Search engine versus document store.
Attic applies that idea to coding-agent memory.
What happens when you use
/compact
?
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:
The auth gate lives in one module.
The desktop window is created in another.
The window creation can happen before auth finishes.
The documentation assumes the opposite order.
You fix the problem.
Then the conversation becomes huge.
You use:
/compact
Enter fullscreen mode
Exit fullscreen mode
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
Enter fullscreen mode
Exit fullscreen mode
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.
The browser extension: Knowledge doesn't only happen in your terminal
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:
A GitHub issue.
A pull request.
A Stack Overflow answer.
A technical blog.
A framework documentation page.
A browser tab containing an important explanation.
A discussion about a design decision.
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.
Browser to project memory
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
Enter fullscreen mode
Exit fullscreen mode
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.
What is a clip?
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
Enter fullscreen mode
Exit fullscreen mode
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.
Why reuse the CLI writer instead of building a second memory system?
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
Enter fullscreen mode
Exit fullscreen mode
Then the CLI would have its own memory system:
CLI
 │
 ▼
.attic/
 │
 ▼
CLI-only notes
Enter fullscreen mode
Exit fullscreen mode
Now you have two systems.
Two storage formats.
Two sets of rules.
Two places to search.
Two systems to maintain.
Attic takes a different approach.
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
Enter fullscreen mode
Exit fullscreen mode
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.
The subtle distinction: Edit is not stash
This is another design decision worth talking about.
At first glance, these two actions might seem similar.
Stash
You discover something new.
You want to add it to the knowledge base.
New discovery → Add a knowledge item
Enter fullscreen mode
Exit fullscreen mode
Edit
You already have a knowledge item.
You want to correct or update it.
Existing item → Replace its content
Enter fullscreen mode
Exit fullscreen mode
These are not the same operation.
Suppose you have this finding:
# Authentication lifecycle
The desktop window is created before
the authentication callback completes.
Enter fullscreen mode
Exit fullscreen mode
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.
Enter fullscreen mode
Exit fullscreen mode
You have updated the knowledge.
You haven't discovered a second, unrelated fact.
Why appending everything is a problem
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...
Enter fullscreen mode
Exit fullscreen mode
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.
Why there is no delete endpoint
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:
Editing an existing item.
Archiving an item.
Pruning stale knowledge.
Permanently removing data, if supported through an intentional local workflow.
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 browser companion is also a security boundary
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:
Which origins can connect?
Which requests are allowed?
How is the local service authenticated?
Where can it write?
What happens when a user clips sensitive information?
Can arbitrary websites cause files to be written?
Attic's design notes identify several of these concerns:
Loopback communication.
A token.
A root allowlist.
Origin checks.
A credential scan for clips.
These are important because a browser-to-local-file bridge should not behave like an unrestricted file-writing API.
Loopback: Keep communication local
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.
Token authentication
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.
Conceptually:
Browser extension
       │
       │ request + token
       ▼
Local Attic server
       │
       ▼
Validate request
       │
       ▼
Write knowledge item
Enter fullscreen mode
Exit fullscreen mode
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.
Root allowlist: Where can it write?
This is another useful security concept.
Suppose the browser companion could tell the server:
Write this content to:

/Users/me/anything/on/my/computer
Enter fullscreen mode
Exit fullscreen mode
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.
Credential scanning: Don't stash secrets
This is particularly important for browser clipping.
Imagine you are reading a page containing:
API_KEY=super-secret-value
Enter fullscreen mode
Exit fullscreen mode
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:
API keys.
Passwords.
Session tokens.
Private access tokens.
Credentials.
Personal secrets.
A browser extension that can save content needs to treat sensitive information as a first-class concern.
The local-first philosophy
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/
Enter fullscreen mode
Exit fullscreen mode
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.
But should you commit
.attic/
to Git?
This is an important practical question.
If the knowledge lives in your project, it can potentially be shared with the team.
For example:
Developer A
    │
    ▼
Saves an architectural discovery
    │
    ▼
Commits .attic/
    │
    ▼
Developer B pulls the changes
    │
    ▼
Agent can recall the discovery
Enter fullscreen mode
Exit fullscreen mode
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:
Should the knowledge be committed?
Should some findings remain local?
How should stale findings be managed?
How should conflicting changes be merged?
What information is appropriate for the whole team?
For a team project, knowledge management becomes part of the repository workflow.
A complete example: From bug investigation to reusable knowledge
Let's walk through a realistic workflow.
Step 1: Start a new investigation
You ask Claude Code:
"Investigate why the desktop sub-window sometimes appears before authentication."
The agent searches the codebase.
It discovers:
packages/desktop/window.js
packages/auth/gate.js
packages/desktop/bootstrap.js
Enter fullscreen mode
Exit fullscreen mode
It traces the execution path.
Step 2: The agent finds the root cause
The agent explains:
"The window creation call happens before the authentication callback completes."
You fix the issue.
Step 3: Save the discovery
You stash the important knowledge:
/attic-stash
Enter fullscreen mode
Exit fullscreen mode
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
Enter fullscreen mode
Exit fullscreen mode
Step 4: Start a new session
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.
Step 5: Update the knowledge after the fix
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
Enter fullscreen mode
Exit fullscreen mode
It's not magic.
It's a disciplined way to make discoveries persistent.
What Attic does not try to do
It's worth being clear about the scope.
Attic is not a replacement for:
Your source code.
Your Git history.
Your issue tracker.
Your documentation.
Your test suite.
Your own engineering judgment.
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.
The bigger idea: Agents need a knowledge lifecycle
When people talk about AI coding assistants, they often focus on:
Better models.
Larger context windows.
Faster inference.
More tool calls.
Better code generation.
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.
Enter fullscreen mode
Exit fullscreen mode
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:
Why a dependency was chosen.
Why a workaround exists.
Why a particular file is important.
Which approach failed.
What assumption caused a bug.
What the team should avoid repeating.
These are not necessarily code changes.
They are discoveries about the codebase.
And they deserve a place to live.
Why browser memory is a natural next step
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        │
      └─────────────┘ └─────────────┘
Enter fullscreen mode
Exit fullscreen mode
One knowledge shelf.
Different ways to add information.
The same place to recall it.
Getting started
You can explore Attic here:
GitHub:
https://github.com/NishikantaRay/Attic
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
Enter fullscreen mode
Exit fullscreen mode
For the exact installation and usage commands, follow the repository's current README and release documentation.
Final thoughts
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.
Try Attic
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.
GitHub:
https://github.com/NishikantaRay/Attic
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?
Tags
ai #claudecode #codex #opensource #developer-tools #codingagents #artificialintelligence #productivity