Why Your Coding Agent Forgets Conventions (And How to Fix It)

You told your coding agent to use bun three times, and it just ran npm install again. Your agent isn't forgetful — it's stateless. Every session starts with an empty context window, and nothing you said last week survives unless it was stored somewhere durable. The fix is one shared memory layer that every agent reads: switch from Claude Code to Codex to OpenCode, and your new agent picks up right where the last one left off.

The "bun vs npm" loop

Here's the loop every developer recognizes: Monday, you tell OpenCode "this project uses bun." It works — for that session. Wednesday, a fresh session starts; you run a task and it generates npm install. You correct it. Friday, after a compaction, it forgets again. The convention was never stored — it was just words in a conversation that no longer exists.

Multiply that by every convention on a real project — code style, test commands, deployment targets, the config file nobody documents — and you spend a noticeable share of each session re-teaching the agent things you already taught it. That's not an agent problem. That's an architecture problem.

Root cause: ephemeral context vs persistent layer

Coding agents keep everything in the context window: the current conversation, injected files, tool outputs. The window is powerful but ephemeral — it resets on every new session, shrinks on every compaction, and vanishes entirely on /clear. Pushing back on a common misconception: a bigger context window does not fix this. It delays compaction; it doesn't persist anything. The summary after compaction is lossy by design.

What you actually need is a second store with different properties: durable, searchable, scoped. Durable across sessions and tools. Searchable by natural language ("what package manager do we use?"). Scoped per user and per project, so work conventions don't leak into side projects. That's exactly what a memory layer is — and how it differs from document retrieval is covered in RAG vs Memory Layer vs Vector DB.

The fix: one shared store every agent reads

Per-tool memory doesn't solve the loop — it just moves it. If Claude Code remembers but Codex doesn't, switching tools resets you anyway. The fix is a single layer outside all of them: your memories live in one shared store, and every coding agent connects to it. That cross-tool persistence is the entire bet behind Audaxic: Claude Code plugin, Codex plugin, OpenCode plugin, plus an MCP server for Cursor, Windsurf, and anything MCP-compatible — all reading and writing the same facts.

Setup takes minutes. Create a key at memory-dashboard.audaxic.com (free Hobby: 10K adds, 1K retrieve), install the plugin for your agent:

npx @audaxic/memory-claude install     # Claude Code
npx @audaxic/memory-codex install       # Codex
npm install -g @audaxic/memory-opencode # OpenCode

From then on, facts save automatically and relevant memories inject into your prompts. Migrating history? npm install -g @audaxic/memory-import backfills old Codex, Claude, and OpenCode conversations with correct timestamps.

Checklist: 3 conventions to persist on day one

Don't try to save everything. Start with the three categories that cause the most re-teaching:

1. Toolchain facts — package manager, runtime versions, test and lint commands ("use bun", "pytest, not unittest", "node 22"). These are the highest-frequency corrections.
2. Style and architecture rules — formatting preferences, folder conventions, API patterns, things in your head that aren't in a linter config.
3. Project constraints — secrets locations, deployment targets, pinned versions, "don't touch" files. The facts whose loss causes real damage, not just annoyance.

Seed them explicitly in your first session ("remember: we use bun"), verify with a search ("what package manager do we use?"), and let the plugin capture the rest organically from there.

FAQ

Written by Efe — Sep 03, 2026 · More articles · X @AudaxicTech