AI Memory

The AI Memory system is one of Codux’s most opinionated pieces. It is not a folder of hand-written CLAUDE.md files in your repository. Codux stores memory in local SQLite, keeps user habits separate from project knowledge, and renders app-private launch files before starting an AI CLI.

What gets remembered

After sessions finish, Codux’s extractor keeps information that should make future AI turns better and drops conversation noise:

• User habits — coding style, response preferences, and durable personal workflow rules
• Project overview — what the repository does, stack, modules, commands, and source signals
• Project notes — decisions, conventions, facts, bug lessons, and relevant recent working notes
• Update signals — whether a session should refresh the project overview or only merge notes

Duplicate or near-duplicate notes are merged; conflicts are replaced by the newer, more specific fact. The goal is an evolving memory store, not a transcript archive.

Three-layer model

Layer	Lifetime	What it holds
User memory	Across projects	Personal coding habits, preferred answer style, and stable workflow rules
Project overview	Per repository	Project purpose, stack, modules, common commands, and detected source signals
Project notes	Evolving over time	Decisions, conventions, facts, bug lessons, and relevant recent notes

Project overview can be generated when missing and refreshed later from repository signals plus memory extraction results. Project notes are merged repeatedly as new sessions produce better or newer facts. The memory manager shows the records and token estimates so you can inspect, delete, or refresh memory when needed.

Token control

Codux does not inject the whole memory database. It renders a small launch set:

• Stable user memory
• Current project overview
• Relevant project notes selected under the injection budget
• Recent working notes only when they are still useful
• Search guidance so the AI can ask for more instead of receiving everything up front

Extraction prompts ask the model to keep summaries concise. Injection is budgeted by scope so memory can grow without every launch getting more expensive.

How it gets back into the AI

When a tool launches, Codux creates a memory workspace under the app data directory and links workspace/ back to your real project directory. It renders:

• MEMORY.md — the launch index
• memory-user.md — cross-project user memory
• memory-project.md — project overview plus project memory
• memory-recent.md — relevant recent working notes
• memory-search.md — search-only guidance and injection limits
• Tool entry files for supported CLIs, such as CLAUDE.md, AGENTS.md, and GEMINI.md

They live in Codux’s application support directory, not in your repo — so:

• Your teammates aren’t forced to share your memory
• The repo’s .gitignore doesn’t need a special line
• Switching machines means switching memory (it’s local)

Where the data lives

<Codux app data directory>/
├── memory.sqlite3                          # the durable store (SQLite)
└── runtime-support/
    └── memory-workspaces/<project-id>/
        ├── workspace -> /path/to/your/repo
        ├── MEMORY.md
        ├── memory-user.md
        ├── memory-project.md
        ├── memory-recent.md
        ├── memory-search.md
        └── <tool entry files>               # generated before launch

You can enable or disable automatic injection, automatic extraction, cross-project user recall, and memory limits from Settings → AI → Memory. The memory manager lets you inspect and remove records, refresh the project overview, and review total memory token estimates.

Why this design

Hand-writing launch files works for a week. Then they go stale, the team forgets to update them, and you’re back to AI tools that “forget” between sessions. By extracting from real sessions and repository signals, Codux keeps the memory closer to how the codebase is actually being worked on.

By keeping it app-private, the cost of being wrong (or personal) is zero — nothing leaks into the repo or onto the team.