{
  "source_file": "0930",
  "source_platform": "Dev.to",
  "author": "Nishikanta Ray",
  "title_listed": "What If Your Coding Agent Could Remember What It Learned Yesterday?",
  "keywords": "",
  "domain": "大模型算法",
  "content_type": "深度技术解析",
  "is_paid_flag": "否",
  "url": "https://dev.to/nishikantaray/what-if-your-coding-agent-could-remember-what-it-learned-yesterday-2okj",
  "publish_date": "2026-09-17",
  "corpus_stage": "",
  "notes": "",
  "id": "b489f67da9e7",
  "collected_at": "2026-10-02T14:04:38",
  "title": "What If Your Coding Agent Could Remember What It Learned Yesterday? - DEV Community",
  "body_markdown": "I built Attic to help Claude Code and Codex CLI remember what they discover — and now you can save knowledge from your browser too.\nYou ask your AI coding assistant to investigate a bug.\nIt searches the repository. Reads five files. Follows a few imports. Runs some commands. Finally, it tells you:\n\"Found it. The authentication check happens after the desktop sub-window is created.\"\nGreat. You fix the bug.\nA few days later, you start a new session.\nYou ask the assistant to investigate another issue in the same area.\nIt searches the same files.\nReads the same imports.\nRuns the same commands.\nAnd eventually discovers the same thing you already knew.\nYou just paid for the same investigation twice.\nMaybe three times.\nThis is the problem I wanted to solve with\nAttic\n— an open-source knowledge persistence tool for AI coding assistants.\nBut the interesting part isn't simply saving notes.\nIt's the design behind making those notes useful across sessions, after context compaction, and now even from your browser.\nGitHub:\nhttps://github.com/NishikantaRay/Attic\nThe problem: Your AI knows more than your codebase\nLet's start with a simple example.\nImagine you're working on a JavaScript monorepo.\nYou ask Claude Code:\n\"Why is the cloud package failing to load?\"\nThe assistant investigates and finds:\n// packages/cloud/index.js\nexport\ndefault\ncloudClient\n;\nexport\ndefault\ncloudConfig\n;\nEnter fullscreen mode\nExit fullscreen mode\nTwo default exports.\nThe file throws a syntax error.\nThe assistant explains the issue. You fix it.\nBut where does that knowledge go?\nIf you only keep the conversation, the discovery is trapped inside that session.\nIf you start a new session, your assistant may have to rediscover the same problem.\nThe codebase contains the bug fix, but it doesn't necessarily contain the\nreasoning that helped you find it\n.\nAnd reasoning is often what you need the next time.\nAnother example: Documentation versus reality\nSuppose your project has a rule:\n\"All desktop sub-windows must wait for authentication before rendering.\"\nBut the actual implementation creates the window before the authentication gate finishes.\nYour assistant investigates and discovers the contradiction.\nThat's valuable knowledge.\nNot just:\nThere is a bug.\nEnter fullscreen mode\nExit fullscreen mode\nBut:\nThe desktop sub-window can be created before the authentication gate\ncompletes, despite the documented requirement.\nEnter fullscreen mode\nExit fullscreen mode\nThat tells the next investigation where to look.\nIt also tells a teammate what assumption is unsafe.\nIt explains\nwhy\nthe code behaves the way it does.\nThis kind of knowledge is easy to lose.\nAnd it isn't limited to bugs.\nIt includes:\nArchitectural decisions.\nRepository conventions.\nFailed approaches.\nImportant file locations.\nAuthentication assumptions.\nPerformance discoveries.\nWhy a particular implementation exists.\nThings you should never repeat.\nYour codebase is a library of implementation.\nYour AI assistant's discoveries are the notes in the margins.\nThe question is:\nWhere do those notes live?\nMeet Attic: A memory shelf for your coding agent\nAttic is an open-source tool designed to help AI coding assistants persist and reuse knowledge.\nIt works with:\nClaude Code.\nCodex CLI.\nThe idea is straightforward:\nWrite what you learn to a file. Keep a small index in context. Retrieve the details when you need them.\nNo need to put every discovery into the assistant's context forever.\nNo need to rebuild the same understanding from scratch every session.\nAnd no need to turn your entire repository into a giant collection of instructions.\nAttic gives the agent a place to store useful discoveries.\nThink of it as a small knowledge library inside your project.\nThe library analogy that makes Attic click\nImagine you have a library.\nYou have 200 books.\nYou don't carry all 200 books around with you.\nYou carry a catalogue.\nThe catalogue tells you:\nWhich books exist.\nWhere they are.\nWhich ones are important.\nWhat each book is about.\nWhen you need a particular book, you look it up.\nAttic follows the same idea.\nThe\n.attic/\nfolder is the library\nA typical Attic knowledge folder contains Markdown files:\n.attic/\n├── INDEX.md\n├── DECISIONS.md\n└── items/\n    ├── f1.md\n    ├── f2.md\n    ├── f3.md\n    └── ...\nEnter fullscreen mode\nExit fullscreen mode\nThe exact files and commands depend on the installed version, but the core concept is consistent:\nThe knowledge lives on disk. The index helps the agent find it.\nINDEX.md\nis the catalogue card\nThe index is not supposed to contain every detail.\nIt's a compact representation of what matters.\nFor example:\n# Attic Index\n## Pinned\n-\nf3: Authentication must complete before\n  desktop sub-windows are created.\n## Recent findings\n-\nf12: Cloud package has duplicate default exports.\n-\nf11: API client is initialized in the shared module.\n-\nf10: The docs and implementation disagree\n  about the authentication lifecycle.\n## Older items\n95 older items not shown.\nUse /attic-recall\n<topic>\n.\nEnter fullscreen mode\nExit fullscreen mode\nThis is an illustrative example of the idea, not a claim about the exact generated format.\nThe agent can see the important information without loading the entire knowledge base into every prompt.\nWhen more detail is needed, it can recall the relevant item.\nThat's the distinction:\nThe index is the catalogue. The Markdown files are the books.\nWhy not just put everything in the system prompt?\nThis is a reasonable question.\nIf the assistant needs the information, why not inject all of it?\nBecause context is limited.\nAnd even when you have enough context, more context isn't automatically better.\nImagine an assistant working on a project with 200 findings.\nIf every finding is included in every session, the prompt becomes filled with:\nOld discoveries.\nSuperseded decisions.\nUnrelated bugs.\nDetails from previous tasks.\nInformation that may not matter to the current question.\nThe agent now has to spend attention deciding what matters.\nAttic takes a different approach.\nKeep the index small\nAttic's runtime includes logic for loading the index and keeping its injected representation compact.\nThe repository's design notes describe an index that prioritizes pinned findings, recent items, and compact summaries for older knowledge.\nThe important idea is not a magic token number.\nIt's this:\nDon't force the assistant to carry the entire library when a catalogue will do.\nRetrieve the details when needed\nSuppose the agent is investigating authentication.\nIt doesn't need to read every database discovery, UI decision, and deployment note.\nIt needs the authentication-related knowledge.\nThat's where recall becomes useful.\nThe four commands: Put knowledge in, get knowledge out\nAttic's commands are organized around a simple workflow.\n1.\nstash\n— save what you learned\nAfter an investigation, save the discovery.\nExample:\n/attic-stash\nEnter fullscreen mode\nExit fullscreen mode\nThe exact command options depend on the installed version.\nConceptually, you are turning an ephemeral chat discovery into a persistent Markdown item.\nInstead of:\n\"I think the auth gate is somewhere in the desktop code.\"\nYou save:\n# Authentication gate and desktop sub-windows\nThe desktop sub-window creation path can run\nbefore the authentication gate completes.\n\nWhen investigating window lifecycle bugs,\ncheck the auth gate before the window creation path.\n\nTags:\n-\nauthentication\n-\ndesktop\n-\nlifecycle\nEnter fullscreen mode\nExit fullscreen mode\nNow that discovery has a home.\n2.\nrecall\n— find what you already know\nLater, you can ask Attic to retrieve relevant knowledge.\nExample:\n/attic-recall authentication\nEnter fullscreen mode\nExit fullscreen mode\nThe assistant can use the stored findings instead of starting from zero.\nThis is particularly useful when:\nA new session starts.\nYou run\n/compact\n.\nA teammate clones the project.\nYou return to an old feature.\nYou forgot why a particular design exists.\n3.\nindex\n— inspect the catalogue\nThe index helps you understand what the agent can see.\nExample:\n/attic-index\nEnter fullscreen mode\nExit fullscreen mode\nThe idea is to inspect the compact catalogue rather than opening every item.\n4.\npin\n,\nprune\n, and\narchive\n— manage the shelf\nNot every discovery deserves permanent prominence.\nSome knowledge is important forever.\nSome is useful for a week.\nSome becomes obsolete after a refactor.\nAttic provides commands for managing that lifecycle:\n/attic-pin\n/attic-prune\n/attic-archive\nEnter fullscreen mode\nExit fullscreen mode\nThe exact syntax depends on the version and installed commands.\nThe important design decision is that knowledge needs management.\nA memory system that only writes and never cleans up eventually becomes another source of noise.\nThe part I find most interesting: The index is not the memory\nThis is the design detail worth understanding.\nA common approach to agent memory is:\nStore a large amount of information and inject it into the next prompt.\nAttic separates storage from injection.\nStorage\nThe detailed findings live in Markdown files.\nThey can contain context, explanations, file references, and reasoning.\nInjection\nThe assistant receives a compact index.\nThe index tells it what exists and how to find it.\nThis separation gives you a useful property:\nYou can have a large knowledge base without making every prompt equally large.\nFor example:\nKnowledge on disk:\n\n200 findings\n│\n├── Pinned findings\n├── Recent findings\n└── Older findings\n    └── Available through recall\nEnter fullscreen mode\nExit fullscreen mode\nThe assistant doesn't need all 200 findings in context.\nIt needs enough information to navigate the collection.\nThis is a familiar pattern in software engineering:\nDatabase versus index.\nFilesystem versus directory listing.\nLibrary versus catalogue.\nSearch engine versus document store.\nAttic applies that idea to coding-agent memory.\nWhat happens when you use\n/compact\n?\nThis is one of the reasons persistent memory matters.\nImagine a long coding session.\nAt the beginning, you ask:\n\"Understand the authentication flow.\"\nThe agent investigates.\nIt discovers:\nThe auth gate lives in one module.\nThe desktop window is created in another.\nThe window creation can happen before auth finishes.\nThe documentation assumes the opposite order.\nYou fix the problem.\nThen the conversation becomes huge.\nYou use:\n/compact\nEnter fullscreen mode\nExit fullscreen mode\nThe context is reduced.\nThe agent may no longer have every detail from the earlier investigation.\nIf the key discovery existed only in the conversation, it can be difficult to recover.\nBut if you saved it to Attic:\n.attic/items/f3.md\nEnter fullscreen mode\nExit fullscreen mode\nThe knowledge remains on disk.\nA later session can recall it.\nThe discovery has survived the conversation.\nThis is the central promise of persistent agent memory:\nYour knowledge should outlive the context window.\nThe browser extension: Knowledge doesn't only happen in your terminal\nNow let's talk about the feature that makes Attic particularly interesting.\nMost coding-agent memory tools focus on what happens inside the terminal.\nBut developers learn things everywhere.\nYou might discover a useful fact while reading:\nA GitHub issue.\nA pull request.\nA Stack Overflow answer.\nA technical blog.\nA framework documentation page.\nA browser tab containing an important explanation.\nA discussion about a design decision.\nYou might think:\n\"This is useful. I should save it.\"\nThen you close the tab.\nOr forget.\nOr leave it in your browser history.\nThe information never makes it into your project's knowledge base.\nAttic's browser companion is designed to close that gap.\nInstead of only remembering what the coding agent discovers, you can save useful knowledge from the browser into the same Attic shelf.\nThat is a powerful extension of the original idea.\nBrowser to project memory\nLet's say you're investigating a bug in a Node.js application.\nYou open a GitHub issue discussing a subtle behavior in a dependency.\nThe issue contains the explanation you need.\nYou don't want to copy the entire page into your project.\nYou want to save the useful discovery.\nThe workflow becomes:\nRead useful information in browser\n          │\n          ▼\n       Clip it\n          │\n          ▼\n  Save to Attic knowledge\n          │\n          ▼\n  Recall it in a future session\nEnter fullscreen mode\nExit fullscreen mode\nThe browser becomes another input into your project memory.\nThis is important because developers don't learn only by asking an AI agent questions.\nThey learn by reading.\nAnd a lot of that reading happens outside the terminal.\nWhat is a clip?\nA clip is a way to capture useful browser content and save it as a knowledge item.\nImagine reading this on a documentation page:\n\"The authentication callback must complete before the desktop window is created.\"\nInstead of copying the entire article into a notes app, you can clip the useful content into Attic.\nThe saved item might look like:\n# Authentication callback lifecycle\nSource: Browser research\n\nThe authentication callback must complete\nbefore the desktop window is created.\n\nThis matters because creating the window\ntoo early can bypass the expected auth gate.\n\nTags:\n-\nauthentication\n-\ndesktop\n-\nlifecycle\nEnter fullscreen mode\nExit fullscreen mode\nNow your browser research becomes part of the same knowledge collection used by your coding agent.\nThe exact clip UI and available options depend on the installed extension version.\nWhy reuse the CLI writer instead of building a second memory system?\nThis is one of the most important design calls in Attic's browser companion.\nA tempting approach would be to build a separate browser storage system.\nSomething like:\nBrowser extension\n       │\n       ▼\nBrowser database\n       │\n       ▼\nBrowser-only notes\nEnter fullscreen mode\nExit fullscreen mode\nThen the CLI would have its own memory system:\nCLI\n │\n ▼\n.attic/\n │\n ▼\nCLI-only notes\nEnter fullscreen mode\nExit fullscreen mode\nNow you have two systems.\nTwo storage formats.\nTwo sets of rules.\nTwo places to search.\nTwo systems to maintain.\nAttic takes a different approach.\nThe browser companion reuses the CLI writer.\nThe repository's design notes explicitly call out that the companion uses the existing CLI writer rather than reimplementing it.\nConceptually:\n┌────────────────────┐\n                 │  Browser extension │\n                 └─────────┬──────────┘\n                           │\n                           ▼\n                 ┌────────────────────┐\n                 │   CLI writer       │\n                 └─────────┬──────────┘\n                           │\n                           ▼\n                      .attic/\n                           │\n                 ┌─────────┴──────────┐\n                 ▼                    ▼\n             INDEX.md             items/*.md\nEnter fullscreen mode\nExit fullscreen mode\nThis is a classic software engineering principle:\nReuse the existing source of truth instead of creating a second implementation.\nThe CLI already knows how to write Attic items.\nThe browser companion should not need to invent a different way to do the same job.\nThat keeps the storage model consistent.\nIt also means the knowledge saved from your browser can be used by the CLI.\nAnd knowledge saved from the CLI can be found in the same collection.\nOne shelf.\nMultiple ways to put books on it.\nThe subtle distinction: Edit is not stash\nThis is another design decision worth talking about.\nAt first glance, these two actions might seem similar.\nStash\nYou discover something new.\nYou want to add it to the knowledge base.\nNew discovery → Add a knowledge item\nEnter fullscreen mode\nExit fullscreen mode\nEdit\nYou already have a knowledge item.\nYou want to correct or update it.\nExisting item → Replace its content\nEnter fullscreen mode\nExit fullscreen mode\nThese are not the same operation.\nSuppose you have this finding:\n# Authentication lifecycle\nThe desktop window is created before\nthe authentication callback completes.\nEnter fullscreen mode\nExit fullscreen mode\nLater, you investigate more deeply and discover that the bug has been fixed.\nYou edit the existing item:\n# Authentication lifecycle\nThe desktop window now waits for the\nauthentication callback to complete.\n\nThe previous behavior was caused by\nthe window creation path running too early.\nEnter fullscreen mode\nExit fullscreen mode\nYou have updated the knowledge.\nYou haven't discovered a second, unrelated fact.\nWhy appending everything is a problem\nIf editing simply appended another copy, you could end up with:\n# Authentication lifecycle\nThe desktop window is created before auth.\n---\n# Authentication lifecycle\nThe desktop window waits for auth.\n---\n# Authentication lifecycle\nThe previous behavior was caused by...\nEnter fullscreen mode\nExit fullscreen mode\nNow the agent has to reconcile multiple versions.\nThat's noise.\nThe repository's design notes explicitly distinguish editing from stashing:\nEditing replaces; stashing appends.\nThis is a small detail, but it reflects a larger principle:\nMemory needs both creation and correction.\nA knowledge system that only adds information eventually becomes cluttered with stale information.\nWhy there is no delete endpoint\nThis might sound strange.\nIf a knowledge item is wrong, why not just delete it?\nThe design notes for Attic's browser companion call out that there is no delete endpoint.\nInstead, the system provides management operations such as archive and prune.\nThere is a reason to be careful here.\nDeleting knowledge can be destructive.\nImagine an agent saves an important architectural decision.\nA browser clip accidentally overwrites it.\nOr a user removes an item because it looks old.\nThe information may be gone before anyone realizes it was useful.\nA safer approach is to separate:\nEditing an existing item.\nArchiving an item.\nPruning stale knowledge.\nPermanently removing data, if supported through an intentional local workflow.\nThis is a design choice, not a universal rule.\nDifferent tools may reasonably choose different deletion models.\nBut the principle is worth considering:\nMemory should be managed deliberately, not casually destroyed.\nThe browser companion is also a security boundary\nThe moment a browser extension can write to your project files, security becomes important.\nA browser extension is not the same as a trusted terminal command.\nIt runs in a different environment.\nIt may interact with content from arbitrary websites.\nIt needs a way to communicate with the local Attic server.\nThat means the design has to answer:\nWhich origins can connect?\nWhich requests are allowed?\nHow is the local service authenticated?\nWhere can it write?\nWhat happens when a user clips sensitive information?\nCan arbitrary websites cause files to be written?\nAttic's design notes identify several of these concerns:\nLoopback communication.\nA token.\nA root allowlist.\nOrigin checks.\nA credential scan for clips.\nThese are important because a browser-to-local-file bridge should not behave like an unrestricted file-writing API.\nLoopback: Keep communication local\nThe companion communicates with a local server.\nThe goal is to keep the interaction on the developer's machine rather than sending knowledge to a remote cloud service.\nThe repository's design notes identify loopback communication as part of the implementation.\nThis is aligned with the project's broader local-first approach.\nThe knowledge is intended to live in the project's\n.attic/\ndirectory.\nToken authentication\nA local service still needs protection.\nJust because something runs on\nlocalhost\ndoesn't mean every request should be trusted.\nAttic's browser server uses a token as part of its request validation.\nConceptually:\nBrowser extension\n       │\n       │ request + token\n       ▼\nLocal Attic server\n       │\n       ▼\nValidate request\n       │\n       ▼\nWrite knowledge item\nEnter fullscreen mode\nExit fullscreen mode\nThe exact request format is an implementation detail.\nThe important point is that the server isn't designed as an unauthenticated arbitrary file-writing endpoint.\nRoot allowlist: Where can it write?\nThis is another useful security concept.\nSuppose the browser companion could tell the server:\nWrite this content to:\n\n/Users/me/anything/on/my/computer\nEnter fullscreen mode\nExit fullscreen mode\nThat would be dangerous.\nA project memory tool should not be allowed to write to arbitrary locations.\nAttic's design notes identify a root allowlist in the server.\nThe intended principle is:\nRestrict file writes to approved project roots.\nThat limits the scope of what the companion can modify.\nCredential scanning: Don't stash secrets\nThis is particularly important for browser clipping.\nImagine you are reading a page containing:\nAPI_KEY=super-secret-value\nEnter fullscreen mode\nExit fullscreen mode\nYou click \"Clip.\"\nShould that secret be saved to your project's memory?\nNo.\nAttic's design notes identify a credential scan that refuses a clip containing a credential.\nThis is a practical safeguard.\nBut it doesn't mean every secret will be detected.\nYou should still avoid clipping:\nAPI keys.\nPasswords.\nSession tokens.\nPrivate access tokens.\nCredentials.\nPersonal secrets.\nA browser extension that can save content needs to treat sensitive information as a first-class concern.\nThe local-first philosophy\nOne of the things I like about Attic is that its design stays close to ordinary developer tools.\nThe knowledge is stored as Markdown.\nThe project can inspect it.\nThe files can be version-controlled.\nAnd the runtime is designed around local filesystem operations rather than a cloud memory service.\nThe repository describes the runtime as using Node.js\nfs\nand\npath\n, with no network calls in the plugin runtime.\nThat gives the project a straightforward mental model:\nYour project\n    │\n    ├── Source code\n    ├── Documentation\n    ├── Tests\n    └── .attic/\n         ├── INDEX.md\n         ├── DECISIONS.md\n         └── items/\nEnter fullscreen mode\nExit fullscreen mode\nYour agent's memory is another part of the repository.\nNot a mysterious remote database.\nNot a separate SaaS dashboard.\nNot a service you need to query over the internet every time the agent needs to remember something.\nBut should you commit\n.attic/\nto Git?\nThis is an important practical question.\nIf the knowledge lives in your project, it can potentially be shared with the team.\nFor example:\nDeveloper A\n    │\n    ▼\nSaves an architectural discovery\n    │\n    ▼\nCommits .attic/\n    │\n    ▼\nDeveloper B pulls the changes\n    │\n    ▼\nAgent can recall the discovery\nEnter fullscreen mode\nExit fullscreen mode\nThe repository notes describe\n.attic/\nas surviving a Git clone only if it is committed rather than ignored.\nThat distinction matters.\nIf you want shared project memory, you need to decide:\nShould the knowledge be committed?\nShould some findings remain local?\nHow should stale findings be managed?\nHow should conflicting changes be merged?\nWhat information is appropriate for the whole team?\nFor a team project, knowledge management becomes part of the repository workflow.\nA complete example: From bug investigation to reusable knowledge\nLet's walk through a realistic workflow.\nStep 1: Start a new investigation\nYou ask Claude Code:\n\"Investigate why the desktop sub-window sometimes appears before authentication.\"\nThe agent searches the codebase.\nIt discovers:\npackages/desktop/window.js\npackages/auth/gate.js\npackages/desktop/bootstrap.js\nEnter fullscreen mode\nExit fullscreen mode\nIt traces the execution path.\nStep 2: The agent finds the root cause\nThe agent explains:\n\"The window creation call happens before the authentication callback completes.\"\nYou fix the issue.\nStep 3: Save the discovery\nYou stash the important knowledge:\n/attic-stash\nEnter fullscreen mode\nExit fullscreen mode\nThe saved item contains something like:\n# Desktop window authentication lifecycle\nThe desktop window creation path can run\nbefore the authentication callback completes.\n\nWhen investigating window lifecycle issues,\ncheck the auth gate before window creation.\n\nRelevant areas:\n-\npackages/desktop/window.js\n-\npackages/auth/gate.js\n-\npackages/desktop/bootstrap.js\n\nTags:\n-\ndesktop\n-\nauthentication\n-\nlifecycle\nEnter fullscreen mode\nExit fullscreen mode\nStep 4: Start a new session\nA few days later:\n\"Why is the desktop window lifecycle failing?\"\nThe agent can inspect the Attic index and recall relevant knowledge.\nInstead of immediately rediscovering the entire execution path, it has a useful starting point.\nStep 5: Update the knowledge after the fix\nYou discover a more precise explanation.\nYou edit the existing item.\nNow the knowledge stays current.\nThis is the lifecycle that matters:\nInvestigate\n    ↓\nDiscover\n    ↓\nStash\n    ↓\nRecall\n    ↓\nUpdate\n    ↓\nReuse\nEnter fullscreen mode\nExit fullscreen mode\nIt's not magic.\nIt's a disciplined way to make discoveries persistent.\nWhat Attic does not try to do\nIt's worth being clear about the scope.\nAttic is not a replacement for:\nYour source code.\nYour Git history.\nYour issue tracker.\nYour documentation.\nYour test suite.\nYour own engineering judgment.\nIt's a knowledge persistence layer for coding-agent workflows.\nIt helps preserve discoveries and make them available again.\nIt doesn't guarantee that the assistant will always recall the right item.\nIt doesn't guarantee that every saved finding is correct.\nIt doesn't eliminate the need to verify facts.\nAnd it doesn't mean the agent should blindly trust old notes.\nA stale memory can be just as dangerous as no memory.\nThat's why editing, pruning, and archive workflows matter.\nThe bigger idea: Agents need a knowledge lifecycle\nWhen people talk about AI coding assistants, they often focus on:\nBetter models.\nLarger context windows.\nFaster inference.\nMore tool calls.\nBetter code generation.\nThose things matter.\nBut there is another problem:\nWhat happens to the useful knowledge after the task ends?\nA coding agent might discover:\nThe API client is initialized in a shared module.\nEnter fullscreen mode\nExit fullscreen mode\nThat can be valuable.\nBut if it exists only in the chat, the next session may have to rediscover it.\nThe same is true for:\nWhy a dependency was chosen.\nWhy a workaround exists.\nWhy a particular file is important.\nWhich approach failed.\nWhat assumption caused a bug.\nWhat the team should avoid repeating.\nThese are not necessarily code changes.\nThey are discoveries about the codebase.\nAnd they deserve a place to live.\nWhy browser memory is a natural next step\nThe browser extension expands the idea beyond terminal-based discovery.\nDevelopers constantly learn from external information.\nThey read a blog post.\nFind a GitHub issue.\nUnderstand a framework quirk.\nDiscover a workaround.\nRead a discussion about a bug.\nThat knowledge is useful even if the AI agent didn't discover it itself.\nThe browser companion makes it possible to capture useful information and bring it into the same local knowledge system.\nThis creates a broader workflow:\n┌───────────────┐\n             │   Terminal    │\n             │ Claude/Codex  │\n             └───────┬───────┘\n                     │\n                     ▼\n              ┌────────────┐\n              │   Attic    │\n              │  Knowledge │\n              └────────────┘\n                     ▲\n                     │\n             ┌───────┴───────┐\n             │               │\n      ┌──────┴──────┐ ┌──────┴──────┐\n      │ CLI stash   │ │ Browser     │\n      │             │ │ clip        │\n      └─────────────┘ └─────────────┘\nEnter fullscreen mode\nExit fullscreen mode\nOne knowledge shelf.\nDifferent ways to add information.\nThe same place to recall it.\nGetting started\nYou can explore Attic here:\nGitHub:\nhttps://github.com/NishikantaRay/Attic\nThe project is designed for Claude Code and Codex CLI.\nA typical workflow is:\n1. Install Attic\n2. Initialize it in your project\n3. Investigate a problem\n4. Stash useful discoveries\n5. Recall them in later sessions\n6. Manage the knowledge as it evolves\n7. Use the browser companion to capture useful research\nEnter fullscreen mode\nExit fullscreen mode\nFor the exact installation and usage commands, follow the repository's current README and release documentation.\nFinal thoughts\nI think the most interesting thing about AI coding assistants isn't just how much code they can write.\nIt's how much they can discover.\nAn agent can investigate a codebase for ten minutes and uncover something that would take a developer much longer to understand.\nBut if that discovery disappears when the session ends, you lose part of the value.\nAttic is built around a simple idea:\nDon't make your AI coding assistant rediscover what it already learned.\nWrite the discovery to a file.\nKeep a compact index.\nRecall the details when needed.\nAnd now, when useful knowledge comes from your browser, clip it into the same shelf.\nThe future of AI coding assistants may not just be about giving agents more context.\nIt may also be about giving them better ways to remember.\nTry Attic\nIf you use Claude Code or Codex CLI and you've ever thought:\n\"I know we already solved this. Why is the agent investigating it again?\"\nAttic is worth exploring.\nGitHub:\nhttps://github.com/NishikantaRay/Attic\nIf you try it, I'd be interested to hear how you manage your agent's knowledge.\nWhat would you want your coding assistant to remember permanently?\nTags\nai #claudecode #codex #opensource #developer-tools #codingagents #artificialintelligence #productivity",
  "metadata": {
    "title": "What If Your Coding Agent Could Remember What It Learned Yesterday? - DEV Community",
    "description": "I built Attic to help Claude Code and Codex CLI remember what they discover — and now you can save... Tagged with ai, claude, tooling, programming.",
    "keywords": "ai, claude, tooling, programming, software, coding, development, engineering, inclusive, community",
    "author": null,
    "og:type": "article",
    "og:url": "https://dev.to/nishikantaray/what-if-your-coding-agent-could-remember-what-it-learned-yesterday-2okj",
    "og:title": "What If Your Coding Agent Could Remember What It Learned Yesterday?",
    "og:description": "I built Attic to help Claude Code and Codex CLI remember what they discover — and now you can save...",
    "og:site_name": "DEV Community",
    "og:image": "https://media2.dev.to/dynamic/image/width=1200,height=627,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fambu1ty013up018lioz6.png",
    "twitter:site": "@thepracticaldev",
    "twitter:creator": "@",
    "twitter:title": "What If Your Coding Agent Could Remember What It Learned Yesterday?",
    "twitter:description": "I built Attic to help Claude Code and Codex CLI remember what they discover — and now you can save...",
    "twitter:card": "summary_large_image",
    "twitter:widgets:new-embed-design": "on",
    "twitter:image:src": "https://media2.dev.to/dynamic/image/width=1200,height=627,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fambu1ty013up018lioz6.png"
  },
  "paywall": {
    "listed_paid": false,
    "detected": false,
    "marker": "",
    "public_only": false,
    "policy": "付费/会员内容只保留页面公开可见部分，不绕过付费墙"
  },
  "crawl": {
    "success": true,
    "status_code": 200,
    "error": ""
  },
  "code_blocks": [
    {
      "file": "attachments/b489f67da9e7/code/body-000.txt",
      "chars": 85,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-001.txt",
      "chars": 16,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-002.txt",
      "chars": 116,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-003.txt",
      "chars": 103,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-004.txt",
      "chars": 383,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-005.txt",
      "chars": 13,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-006.txt",
      "chars": 276,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-007.txt",
      "chars": 29,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-008.txt",
      "chars": 13,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-009.txt",
      "chars": 39,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-010.txt",
      "chars": 127,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-011.txt",
      "chars": 9,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-012.txt",
      "chars": 19,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-013.txt",
      "chars": 180,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-014.txt",
      "chars": 276,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-015.txt",
      "chars": 90,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-016.txt",
      "chars": 39,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-017.txt",
      "chars": 540,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-018.txt",
      "chars": 37,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-019.txt",
      "chars": 36,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-020.txt",
      "chars": 104,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-021.txt",
      "chars": 183,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-022.txt",
      "chars": 213,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-023.txt",
      "chars": 154,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-024.txt",
      "chars": 58,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-025.txt",
      "chars": 27,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-026.txt",
      "chars": 159,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-027.txt",
      "chars": 170,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-028.txt",
      "chars": 79,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-029.txt",
      "chars": 13,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-030.txt",
      "chars": 367,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-031.txt",
      "chars": 77,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-032.txt",
      "chars": 50,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-033.txt",
      "chars": 546,
      "language": "text"
    },
    {
      "file": "attachments/b489f67da9e7/code/body-034.txt",
      "chars": 230,
      "language": "text"
    }
  ],
  "images": [],
  "audio": [],
  "videos": [],
  "links": [
    {
      "href": "https://github.com/NishikantaRay/Attic",
      "label": "https://github.com/NishikantaRay/Attic",
      "type": "a"
    }
  ],
  "repair_version": 2,
  "repaired_at": "2026-10-14T10:49:49Z",
  "source_url": "https://dev.to/nishikantaray/what-if-your-coding-agent-could-remember-what-it-learned-yesterday-2okj",
  "papers": [],
  "actual_video_files": [],
  "body_chars": 29358,
  "expected_body_images": 0,
  "discovery_status": "ok",
  "delivery_status": "ok",
  "missing_reason": "",
  "raw_html": "attachments/b489f67da9e7/pages/source.html",
  "local_html": "attachments/b489f67da9e7/pages/article.html",
  "body_base_path": "attachments/b489f67da9e7/pages/",
  "body_markdown_path": "attachments/b489f67da9e7/pages/article.md"
}