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

glenn chen (cg33) — Sat, 30 May 2026 01:05:44 +0000

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:

It is transparent.
It is easy to inspect.
It works with almost every coding agent.
It avoids forcing users into a specific database or runtime.
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.

Because the existing Mermaid diagram editors online produce unattractive charts, I created a new one.

glenn chen (cg33) — Sat, 29 Nov 2025 01:24:02 +0000

https://modern-mermaid.live

I've been using Mermaid for flowcharts and diagrams for a while, but I always felt that the available online editors just produce ugly, unpolished charts. So I decided to build a new Mermaid editor from scratch. It features a modern, clean interface, multiple visual themes including hand-drawn and Studio Ghibli styles, real-time preview, and high-quality export options (PNG/JPG).

I’d love to hear what the community thinks—feedback and suggestions are welcome!

DEV Community: glenn chen (cg33)