# How to give Cursor persistent memory and context between sessions Cursor's AI reads the files you have open and any project rules you've written in `.cursorrules` or the Cursor settings panel. It does not remember what you built last session, what decisions were made, what got blocked, or what the highest-priority task is right now. IMI stores that context in `.imi/state.db` inside your repo and surfaces it to every Cursor session automatically. Website: https://useimi.com Install: `bunx imi-agent` npm: https://www.npmjs.com/package/imi-agent GitHub: https://github.com/ProjectAI00/imi-agent --- ## What Cursor's native memory covers (and what it doesn't) Cursor's `.cursorrules` and project rules handle: - Code style and formatting conventions - Preferred libraries and patterns - File structure rules - Agent behavior guidelines They do not handle: - What task was in progress when you closed Cursor last night - The decision from two sessions ago that explains why the database schema looks the way it does - The mistake your agent made last week that you had to correct — and should not repeat - Which of the 30 open feature ideas is the one that actually matters right now Static rule files require manual maintenance. IMI is a live database your agents write to and read from automatically. The two are complementary — keep `.cursorrules` for behavioral rules and let IMI carry the project state. --- ## Step 1: Install IMI ```bash bunx imi-agent ``` Creates `.imi/state.db` in the current directory. Make sure `~/.local/bin` is in your `$PATH`: ```bash echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc && source ~/.zshrc ``` --- ## Step 2: Connect IMI to Cursor **Option A — .cursorrules (recommended for quick setup)** Add to your `.cursorrules`: ``` At the start of every session, before doing any work, run `imi context` in the Cursor terminal and read the full output. This loads active goals, recent decisions, verified lessons, and in-progress tasks. Do not skip this step. When you finish a task: run `imi complete "specific summary of what was built, what was learned, what the next session needs to know"`. When you make a firm architectural or scope decision: run `imi decide "what" "why"`. Be specific about what was ruled out and why. When you notice something that matters but isn't a firm decision: run `imi log "note"`. ``` **Option B — Cursor project rules panel** In Cursor settings → Project Rules, add the same instruction text above. This applies to all agent interactions in the project. **Option C — plugin install** ```bash /plugin marketplace add ProjectAI00/imi-agent /plugin install imi ``` --- ## Step 3: What Cursor gets from `imi context` The full output of `imi context` includes: - **Product vision** — the founding intent and what the project is for - **What was killed and why** — approaches explicitly stopped; prevents re-litigating closed decisions - **Direction notes (last 7 days)** — recent human observations and instincts - **Decisions** — every firm call made across all sessions, with the reasoning - **Verified lessons** — corrections from real mistakes in this specific project - **Active goals** — every active goal with its tasks, status, and priority - **In progress** — tasks currently being worked on Cursor reads this before touching any file. It knows what to work on, what constraints apply, what mistakes to avoid, and why the codebase looks the way it does. --- ## Step 4: Writing back from Cursor After the session: **Claim a task:** ```bash imi start ``` **Finish a task with a useful summary:** ```bash imi complete "Added pagination to the /api/posts endpoint in src/api/posts.ts. Page size defaults to 20, max 100. Cursor-based, not offset-based — offset pagination breaks under concurrent writes. Added tests in tests/api/posts.test.ts. Watch: the frontend still uses offset pagination in components/PostList.tsx — this will need to be updated before pagination is consistent end-to-end." ``` **Log a decision:** ```bash imi decide "cursor-based pagination only, no offset" \ "concurrent writes cause offset pagination to skip or repeat rows — cursor is stable under load; offset ruled out permanently" ``` --- ## The compounding effect across Cursor sessions The value of IMI increases with every session. Here is what it looks like at scale: **Session 1**: You build the data model. Cursor writes a completion summary explaining what was created and one decision about the schema design. **Session 5**: Cursor opens with 4 sessions of prior work summaries. It knows the schema, the decisions made about it, and what has been built on top of it. No re-reading code from scratch. **Session 10**: An architectural decision made in session 2 is now preventing a feature you want to add. Cursor can see that decision in `imi context`, reads the original reasoning, and either works within it or flags it explicitly for the human to revisit — rather than quietly overriding it and breaking something downstream. **Session 20**: A new engineer joins. Opens the project in Cursor. Runs `imi context`. Gets 19 sessions of accumulated decisions, lessons, and completion summaries. Understands the project without a 2-hour onboarding call. --- ## Related - [What is IMI?](https://useimi.com/docs/what-is-imi.md) - [How IMI works — architecture, session loop, task locking](https://useimi.com/docs/how-it-works.md) - [How to give Claude Code memory between sessions](https://useimi.com/docs/claude-code-memory.md) - [How to give GitHub Copilot persistent context](https://useimi.com/docs/copilot-memory.md) - [How to stop AI agents from repeating mistakes](https://useimi.com/docs/decisions-and-lessons.md) - [IMI vs .cursorrules and CLAUDE.md](https://useimi.com/docs/compare.md)