Local work memory for Claude Code, Codex, and Cursor
Contextberg records your screen, browser history, app usage, keystrokes, and agent conversations locally, then serves work memory to MCP-compatible coding agents.
What I built
Contextberg is a local memory app for AI coding agents. It runs in the background, records the context around your work, and makes that memory available to MCP-compatible clients. The first release is for Windows, with the same local-first model intended to expand to macOS.
It captures five kinds of signals: screenshots, browser history, keystrokes, app/window usage, and agent conversation history. Claude Code, Codex, Cursor, GitHub Copilot, OpenClaw, LM Studio, and other MCP clients can then ask what you were doing and receive useful work context instead of a blank session.
Why conversation history is not enough
Modern development often moves across multiple AI agents. You might discuss architecture with Claude Code, ask Codex to review a diff, use Cursor for edits, and rely on GitHub Copilot in the terminal.
The problem is that those agents do not see each other's conversations. More importantly, a lot of decisions happen before you ever talk to an agent: reading Stack Overflow, scanning GitHub Issues, looking at logs, trying changes in VS Code, and then deleting them.
Chat history captures the final request. It does not capture the research, screen state, browser tabs, app usage, or dead ends that led to that request. To resume work across sessions, agents need memory of the work around the conversation.
The four pillars
Context: Contextberg records screen, browser, and agent activity so you no longer have to restate what you were doing.
Memory: Hourly reports and long-term memory turn raw activity into structured context that an agent can reason over.
Private: Work data is stored locally first. Cloud models can be used for summarization, but LM Studio lets you run the memory pipeline fully offline. The same OpenAI-compatible route also leaves room for user-owned API keys, OpenRouter, or subscriptions and model quotas you already pay for, including Codex, instead of forcing all usage through Contextberg's cloud quota.
Remember: When you come back, Contextberg can summarize what you were doing and help you pick up from the previous session.
What Contextberg records
The core idea is to merge five signals into one work timeline. App/window usage shows where your time went. Browser history restores what you researched. Screenshots preserve what was visible. Keystrokes give clues about what you were writing or struggling with. Agent conversations connect the work to Claude Code, Codex, Cursor, and terminal sessions.
Each signal is useful on its own, but the combination is what makes it valuable. Conversation history tells an agent what you decided. Screen, browser, input, and app context help it infer why that decision happened.
Record and Memory tabs
A memory app that records in the background has to be inspectable. The Record tab shows foreground app changes, screenshots, browser history, and usage charts so you can see what is being captured.
The Memory tab lets you inspect short-term reports and long-term memory. Long-term memory can be edited manually, so wrong assumptions can be removed and useful preferences can be added.
Three memory layers
Contextberg uses three memory layers: Activity, Hourly Report, and Long-Term Memory. Activity is updated frequently and is useful for questions like what was I just doing. Hourly Report turns one hour of activity into a natural-language summary. Long-Term Memory extracts durable facts such as projects, preferences, tools, and work patterns.
This is not a simple compression pipeline. Each layer has a different use case. Short-term context helps with immediate recovery. Hourly summaries support daily review. Long-term memory gives agents stable background knowledge before a task starts.
How MCP connects the memory
Contextberg runs a local HTTP server inside the desktop app and exposes a thin MCP bridge through npm. A Claude Desktop configuration can start the bridge with npx and connect it to the local Contextberg app.
The MCP tools include get_activity for recent work, get_daily_memory and get_weekly_memory for reports, get_agent_history for Claude Code / Cursor / Codex conversation turns, read_ltm for long-term memory, and update_ltm for appending durable facts.
Privacy and limits
Contextberg records sensitive signals. That is the point of making useful work memory, but it also creates real privacy pressure. The current design draws the line by recording broadly on the local machine while not storing work data in the cloud backend.
Cloud models can be used to generate reports, and the prompt may include screenshots, keystroke snippets, browser history, app usage, and agent conversations. The backend treats those requests statelessly and returns generated text to the desktop app. If you do not want Contextberg-hosted processing, you can switch to an OpenAI-compatible endpoint such as LM Studio, OpenRouter, a provider key you already pay for, or a subscription/model quota such as Codex.
You can exclude apps, window titles, URL patterns, time ranges, screenshots, or keystrokes. Excluded records do not enter Activity, so they do not flow into reports, LTM, or MCP responses.
Why lightweight desktop matters
A background app that captures screen, browser, and keyboard context has to stay lightweight. Contextberg targets roughly 120-180 MB idle memory, around 250 MB active memory, under 1% idle CPU, and an MSIX size around 100 MB.
The first release is Windows-focused because a background memory app needs tight integration with screen capture, foreground windows, keyboard signals, local credentials, and app packaging. The product direction is not Windows-only, though. The goal is to bring the same local memory model to macOS with an implementation that feels native to that platform too.
Who this is for
Contextberg is for developers who use Claude Code, Codex, Cursor, GitHub Copilot, and MCP workflows every day. The more agents you use, the more painful context fragmentation becomes.
It is also for people who are tired of explaining where they left off, want to resume work faster, or want local-first AI memory without sending their entire work history to a hosted memory service. If recording screen, browser history, and keystrokes is unacceptable for your workflow, Contextberg is not the right tool.
Where Contextberg sits in the memory landscape
AI memory is not one category. Mem0, Letta, agentmemory, Claude-Mem, Recall-style screen history, and Contextberg solve adjacent but different problems.
| Layer | Examples | Best for | Contextberg's angle |
|---|---|---|---|
| Memory API / SDK | Mem0 | Adding memory to your own AI app | Contextberg is not an SDK; it gives existing tools local work context |
| Agent runtime | Letta | Building stateful agents | Contextberg keeps memory on the user's work environment side |
| Coding agent memory | agentmemory, Claude-Mem | Helping coding agents remember prior sessions | Contextberg also captures screen, browser, app, and keyboard context |
| Screen history | Microsoft Recall, screenpipe, OpenRecall | Searching what you saw on your computer | Contextberg uses similar local signals, but the output is MCP-readable work memory |
The MCP bridge is not the data store
The npm package is intentionally thin. `@contextberg/mcp-server` is a bridge between MCP JSON-RPC and the local Contextberg API running at `http://localhost:18080`. The desktop app owns the data; the bridge only makes it readable to MCP clients.
That matters for trust. A memory bridge should not look like a telemetry collector or a cloud sync daemon. The useful boundary is local app, local API, token-guarded access, and MCP tools that return shaped work context instead of raw dumps.