Your AI coding agent forgets everything outside the chat. I built OpenContext to fix that.

Every morning, I found myself onboarding a new AI agent.

Not a new human teammate.
A new Claude Code / Codex / Cursor session.

The pattern was always the same:

I would open a fresh session and say something like:

Continue the bug I was debugging this morning.

And the agent would basically ask:

What bug? What files? What changed? What failed? What have you already tried?

Which is reasonable. The agent was not there.

It did not know which shell commands I had run.
It did not know which files I had touched.
It did not know which build failed.
It did not know which browser docs I had been reading.
It did not know which previous agent session already explored and rejected a certain approach.

So I had to explain my own work history again.

That felt wrong.

We are building increasingly capable coding agents, but most of them still only know what happens inside the current chat. The rest of your workday is invisible to them.

That is the problem I built OpenContext to explore.

GitHub: https://github.com/ohmyctx/opencontext

The problem: agent memory stops at the chat boundary

Most AI coding tools are powerful inside a single session.

They can read files, edit code, run commands, explain errors, and help you reason through a task.

But once you start a new session, a lot of useful context disappears:

• What did I work on yesterday?
• Which files did I edit?
• Which commands failed?
• Which tests passed?
• Which docs did I read?
• What did I already ask another agent?
• What did I decide not to do?
• What was I trying to accomplish before I got interrupted?

This is especially painful for coding agents because software work is not just “the current prompt”.

It is a stream of activity across many tools:

• terminal
• editor
• browser
• git
• issue trackers
• email
• chat
• previous agent sessions

A fresh agent session usually sees none of that unless you manually paste it in.

So every new session starts with a small onboarding tax.

For small tasks, that is annoying.
For large projects, it becomes a real bottleneck.

Existing memory tools mostly remember conversations

There are already many agent memory systems.

Some remember facts from previous chats.
Some store vector embeddings.
Some let agents write notes to themselves.
Some act as a long-term memory backend.

Those are useful, but they often start from the conversation itself.

I wanted to explore a slightly different layer:

What if agents could remember the work signals around the conversation?

Not just what you told the agent, but what you actually did:

• ran go test ./...
• edited platform/slack/slack.go
• opened a GitHub issue
• searched docs about Cursor hooks
• started a new Codex session
• asked a previous Claude Code session about the same bug
• switched branches
• committed a fix

These are not random logs. They are work context.

And they are exactly the kind of context a new coding agent needs before it can help.

OpenContext: memory beyond the chat

OpenContext is a local-first work memory layer for AI coding agents.

The idea is simple:

Collect lightweight work signals, store them locally, filter them through subscriptions and privacy rules, then compile them into agent-readable memory.

The first interface is intentionally boring:

memory.md

Why Markdown?

Because every coding agent can read it.

Claude Code can read it.
Codex can read it.
Cursor can read it.
Any local agent can read it.

No special vector database required.
No complex agent runtime required.
No cloud service required.

The current flow looks like this:

collectors
  -> events
  -> local SQLite store
  -> subscriptions / filters
  -> compiled memory.md
  -> agent reads context before helping

The goal is not to build another time tracker.

The goal is to make this possible:

You open a blank agent session and say: “Continue what I was doing this morning.”

And the agent already has enough recent context to understand where to start.

What OpenContext collects

OpenContext is based on collectors.

Collectors observe lightweight work signals from tools you already use.

Current / planned collectors include:

• shell commands
• Claude Code hooks
• Codex hooks
• Cursor hooks
• OpenCode / OpenClaw / Hermes hooks
• browser activity
• macOS / Windows activity
• git-related context
• agent prompts and tool calls

A shell event might look like this:

{
  "source": "shell",
  "type": "command",
  "cwd": "/code/opencontext",
  "command": "go test ./...",
  "exit_code": 1,
  "duration_ms": 18420
}

An agent prompt event might look like this:

{
  "source": "cursor",
  "type": "user_prompt",
  "prompt": "Continue the hook integration from this morning",
  "workspace": "/code/opencontext"
}

A browser event might look like this:

{
  "source": "browser",
  "type": "page_view",
  "url": "https://cursor.com/docs/hooks",
  "title": "Cursor Hooks",
  "duration_ms": 240000
}

Individually, these events are small.

Together, they tell a story:

The user was integrating Cursor hooks, reading the Cursor hooks docs, editing the OpenContext repo, and running tests that failed.

That is context.

What OpenContext does not try to do

This boundary is important.

OpenContext is not meant to copy your entire workspace.

It should capture activity, not duplicate all content.

For example, if you edit a file, OpenContext does not need to store the full file by default.

It can store:

• file path
• project
• timestamp
• git branch
• action type
• optional summary
• pointer to the original source

The agent can read the actual file later if needed.

Same with emails, docs, browser pages, or GitHub issues.

OpenContext should tell the agent:

Something important happened here. This is where to look.

It should not automatically become a giant warehouse of all your private content.

A useful distinction is:

content = the thing itself
context = your interaction with the thing

A document is content.
Opening it, editing it, sharing it, returning to it repeatedly, or leaving a comment unresolved — that is context.

OpenContext focuses on the second part.

Privacy model

This kind of tool can easily become creepy if designed badly.

So OpenContext starts with a few constraints:

• local-first by default
• no screenshots by default
• no keyboard logging
• raw events stay local
• sensitivity levels for collected events
• subscriptions decide what becomes agent-readable memory
• users should be able to inspect what was collected

The default goal is not:

Record everything the user does.

The goal is:

Capture enough work context to help agents continue where the user left off.

Those are very different products.

OpenContext should feel like a personal memory layer, not employee monitoring software.

Subscriptions: not every agent needs every memory

Another idea in OpenContext is subscriptions.

Not every agent should see every event.

A coding agent may need:

• recent shell commands
• touched files
• failed tests
• git branch
• recent coding prompts

A PM-style agent may need:

• summaries
• open loops
• project progress
• decisions
• blockers

A writing agent may need:

• drafts
• browser research
• notes
• previous writing style

So instead of dumping all events into every agent context, OpenContext lets memory be filtered.

Conceptually:

raw events
  -> subscriptions
  -> scoped memory
  -> agent-readable context

This matters because memory is not just storage.
Memory is selection.

Too little context and the agent is lost.
Too much context and the agent is distracted.

Why Markdown first?

The first version compiles memory into Markdown.

That may sound primitive, but it has a few advantages:

1. It is transparent.
2. It is easy to inspect.
3. It works with almost every coding agent.
4. It avoids forcing users into a specific database or runtime.
5. It is easy to version, diff, edit, and delete.

A generated memory file might contain:

# Recent Work Memory

## Current Project: opencontext

### Recent Activity
- Worked on Cursor hook integration.
- Captured beforeSubmitPrompt events from Cursor.
- Ran local tests for shell collector.
- Investigated how to inject memory into fresh agent sessions.

### Recent Commands
- go test ./...
- oc collector cursor install
- curl http://localhost:6060/health

### Open Loops
- Verify Cursor sessionStart hook behavior.
- Improve memory.md formatting.
- Add browser collector examples.

### Relevant Files
- cmd/oc
- internal/collector
- docs/hooks.md

This is not the final form of memory.

But it is a useful first interface.

Later, OpenContext can add MCP tools, richer querying, embeddings, event graphs, or temporal memory.

But Markdown gives us a simple baseline: the agent can read it today.

How this differs from time tracking

OpenContext may sound similar to time tracking tools at first.

But the question is different.

A time tracker asks:

Where did my time go?

OpenContext asks:

What context should my agent know before it helps me?

That changes the output.

The main output is not a dashboard.
It is not productivity analytics.
It is not employee monitoring.

The main output is agent-usable context:

• what changed
• what failed
• what was tried
• what is still open
• where the agent should look next

This is closer to a continuity layer for coding agents.

Humans work continuously.
Agent sessions are fragmented.

OpenContext tries to bridge that gap.

A small example

Imagine you spent the morning debugging a Slack integration bug.

During that time you:

• edited platform/slack/slack.go
• ran go test ./...
• opened Slack API docs in the browser
• asked Codex about mention parsing
• committed a test case
• left one release-test issue unresolved

Later, you open a fresh agent session and type:

Continue the Slack bug from this morning.

Without OpenContext, the agent asks for background.

With OpenContext, it can see something like:

## Recent Work: cc-connect

This morning the user worked on a Slack mention parsing bug.

Evidence:
- Edited `platform/slack/slack.go`
- Ran `go test ./...`
- Opened Slack API documentation
- Added/updated mention parsing tests
- Related prompt: "handle @Bot/status without a space"
- Open loop: verify release-test phantom session behavior

That is enough for the agent to start in the right place.

It does not need your entire life story.
It just needs the relevant trail.

Why I built this

I am interested in coding agents, local-first tools, and agent infrastructure.

The more I use agents, the more I feel the bottleneck is not only model intelligence.

A big bottleneck is context continuity.

We keep building smarter agents, but we still ask users to manually explain what just happened in their own workflow.

That feels backwards.

If agents are going to become useful long-term collaborators, they need memory beyond the chat.

Not unlimited surveillance.
Not raw screen recording.
Not a giant personal data dump.

Just enough structured work context to understand what happened and where to continue.

That is what OpenContext is trying to explore.

Current status

OpenContext is early.

The first version is focused on local developer workflows and coding agents.

It currently includes the basic pieces:

• local event collection
• SQLite storage
• collector architecture
• sensitivity levels
• subscriptions
• Markdown memory output
• hooks for several agent tools
• optional browser / OS collectors

There is still a lot to improve:

• better event schema
• better privacy controls
• better summarization
• better MCP integration
• better UI for inspecting collected events
• better support for Cursor / Codex / Claude Code workflows
• better distinction between raw events, summaries, and long-term memory

But the core idea already feels useful:

A new agent session should not start from zero.

Try it

GitHub:

https://github.com/ohmyctx/opencontext

If you use Claude Code, Codex, Cursor, or similar coding agents, I would love feedback.

Especially on:

• Is Markdown memory a good first interface?
• What work signals are actually useful?
• What should never be collected?
• How should subscriptions work?
• How should this differ from time trackers and memory databases?

I do not think this space is solved yet.

But I do think “memory beyond the chat” will become a necessary layer for serious AI agent workflows.