用 MCP 把任务历史带进 Cursor 跨会话：开源 Mac 应用 Deiko

Every new Cursor chat starts without what the last one tried. What’s worked for me, with or without any tool:

1. Keep a short per-task note: what was tried, what was decided, what’s still open. Three headings, a few lines each.
2. Start the next chat by handing Cursor that note, not the whole history.
3. At the end of a session, ask the agent to rewrite the note. The “decided” lines are the valuable part: they stop the agent re-trying a fix you already ruled out.

I got tired of doing that by hand, so I built it into Deiko, an open-source Mac app (MIT). You point at the problem on screen and talk; it files each brief into its task and keeps that note for you. Cursor can read and update it through a local MCP server (search_briefs, get_task, list_tasks, save_outcome).

Repo: GitHub - maddy30445r/deiko: Point at it. Say it. Your agent remembers it. Voice and on-screen annotation for coding agents, plus a free board on your Mac that keeps every task's context. For Claude Code, Cursor, Codex and any MCP agent. · GitHub

Curious how others here keep context between Cursor sessions.

Security note: it asks for Accessibility, Screen Recording and Microphone access and captures only while a session runs (a red bar shows). Screenshots never leave your Mac. It isn’t notarized by Apple yet, so read the install script first: https://github.com/maddy30445r/deiko/blob/main/scripts/install.sh

Hey, great topic to discuss, thanks for sharing your approach. The habit of keeping a short per-task note with a “decided” section is a really solid way to stop the agent from retrying things you’ve already ruled out.

If anyone wants a tool-agnostic option right inside Cursor, you can get the same effect using project rules and an AGENTS.md file in the repo root. You put decisions and open questions there, and the agent will pick them up in every new session. Docs: Rules | Cursor Docs

On the “memory between sessions” topic, there were also a couple community projects posted recently that might be interesting to compare approaches:

• Built a shared memory layer for Cursor and AI coding agent
• Grounder: session memory shared between Cursor and Claude Code

Small note for anyone installing it. Like you said, the app isn’t notarized yet and it asks for Accessibility, Screen Recording, and Microphone permissions, it’s good that you linked the install script. Everyone trying it should read the script before running it.

The “decided” section is the part I would underline too. Ruled-out fixes are what agents retry most, because nothing in the code shows an approach was already tried and dropped.

Disclosure: I am one of the people behind Recallium (https://recallium.ai/), which tackles the same problem from a slightly different angle. Instead of one note per task, decisions and fixes are saved as separate memories linked to the files they relate to, so before editing a file the agent can check what was tried there before. The same memory also works across Cursor, Claude Code and VS Code, and can be shared with a team. The trade-off is that a per-task note like yours is much easier to read and edit by hand, which counts for a lot.

Curious how you handle a decision that applies to more than one task. Do you copy it into each note, or keep it somewhere shared?

that decided section is the part i’d keep even after the session ends.

when the agent opens a PR, the reviewer has the same problem the next chat has: they see the final diff but not the approaches that got tried and dropped, so they end up suggesting one of them again.

pasting the task note, or just the decided lines, into the PR description fixes that for free.

does save_outcome write anything to the PR side, or does the note stay on the Mac?

Thanks Dean, and agreed: AGENTS.md / project rules is where anything stable should live. “We use pnpm”, “never touch the generated client”, that sort of thing. I think of the per-task note as the other half: the in-flight stuff that’s true for this bug this week and would just be noise in a rules file once it’s fixed. If it graduates to “true for the whole repo”, it moves into AGENTS.md.

I’ll have a look at those two projects, thanks for the links. And yes, please read the install script; it’s short.

Good question, and it’s the weak spot of a per-task note. Right now:

• A decision lives in the task it came from, and it rides along with every later brief on that task until an agent retires it.
• When one outgrows its task (“prices are always computed server-side”), I pin it as a project rule. Every brief in that project then carries it, whichever task it lands in. There’s room for five, on purpose, so they stay rules and don’t turn into a second memory.
• For everything in between, the agent can search across tasks (search_briefs), so it can find “we already tried X in the coupon task”, but only if it thinks to look.

So the honest answer is that moving a decision from one task up to the project is still a manual step. Linking memories to files, the way you do, catches the case I miss: a different task touching the same file the old decision was about. I can see that being the better trigger for “check before you edit”. Nice approach.

Good point. The reviewer is just another “next chat” without the history.

Today the note stays on the Mac: save_outcome writes it into that brief’s folder, and nothing goes to GitHub on its own. Two ways to get it into a PR now:

• The board can hand a task off as Markdown, so you can copy the note straight into the PR description.
• The agent can read the note itself through get_task. So a line in AGENTS.md like “when you open a PR for a Deiko task, call get_task and put its Decided lines under ‘Tried and ruled out’” does it without any copy-paste.

I like the idea of making that automatic, though. The “Decided” lines are exactly what a reviewer is missing. Noted.