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 a session finishes, Codux’s extractor keeps information that should make future turns better and drops conversation noise:

• User habits — coding style, response preferences, and durable personal workflow rules
• Project notes — decisions, conventions, facts, bug lessons, and recent working notes
• A refresh signal — whether the project overview should be regenerated

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. Note that the project overview itself is built from your repository’s files, not extracted from chat transcripts — the extractor only flags when it should be refreshed.

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	Purpose, stack, modules, common commands, and source signals — generated from repo files
Project notes	Evolving over time	Decisions, conventions, facts, bug lessons, and recent notes

Token control

Codux does not inject the whole memory database. It renders a small launch set within a per-scope budget:

• Stable user memory
• The current project overview
• Relevant project notes, selected under the injection budget
• Recent working notes, only while they are still useful

Extraction prompts ask the model to keep summaries concise, and 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 builds a memory workspace under its application data directory and renders:

• MEMORY.md — the launch index
• memory-prompt.txt — the same context delivered to the CLI as a system-prompt / instructions file
• memory-recent.md — relevant recent working notes
• CLAUDE.md, AGENTS.md, GEMINI.md — tool entry files for the supported CLIs

Your AI process keeps its working directory in your real repo; Codux points the CLI at these files through environment variables (and, for Codex, --add-dir) rather than copying anything into your repository. 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-root/
    └── memory-workspaces/<project-id>/
        ├── MEMORY.md
        ├── memory-prompt.txt
        ├── memory-recent.md
        ├── CLAUDE.md
        ├── AGENTS.md
        └── GEMINI.md

Settings

Open Settings → Memory to control: Enable Memory, Automatic Injection, Automatic Extraction, Extraction Interval, Maximum Recent Sessions, Cross-Project User Memory, and the Default Extraction Provider. The Memory Manager (opened from the status bar) shows your records with token estimates, and lets you delete records, regenerate the project profile, and refresh.

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 memory closer to how the codebase is actually being worked on — and by keeping it app-private, the cost of being wrong (or personal) is zero: nothing leaks into the repo or onto the team.