Today, what your team shares is hand-written, and what your agent learns is stuck on one laptop. keepctx joins them: context captured as your agent works, kept current, and shared with everyone.
Every session, you re-explain how to log in to your servers, where the logs live, and what runs where. Every next session, it's forgotten. The fix isn't a bigger context window — it's writing things down once, in a place the next session reads automatically.
When you correct your agent, it records the correction. The next session — yours or a teammate's — starts already knowing.
Preloading a company's knowledge every session is about 95% waste. keepctx loads a small index and fetches a context only when the task touches it.
A new hire clones the repo and their agent already knows how to get into prod, where the logs are, and which docs are lying.
Every change is versioned server-side and one revert away. A weak model can add noise; it can't destroy what your team already established.
.ctx/ ignores itself, so context never pollutes diffs and never goes stale
on a branch. Your AGENTS.md gets two lines and nothing else.
Facts are readable text. Run our server or your own. Uninstalling is deleting two lines from a file.
A context is a list of facts. The bolded lead is the key, and the value can be an IP, a command, or a sentence.
# .ctx/example-project/facts.md
- **prod.access** — SSO, then jump host `bastion.example.com`, then `aws --profile prod-ro`. Never direct SSH. `[verified]`
- **network.proxy** — internal hosts only resolve through the corporate proxy; set `HTTPS_PROXY` first
- **logs.location** — Splunk, index `app_prod`. Not CloudWatch, whatever the old runbook says.
- **api.runs-on** → Cloud Foundry (`cf logs api --recent`), not Kubernetes
- **api.depends-on** → auth-service, for session validationYour agent opens facts.md with the same tools it uses for any
other file, and edits it as it learns. There's no write command to forget and no ceremony to
skip — which is exactly why capture actually happens.
Changes sync per key, not per file. Two people learning different things both land. Two people changing the same fact means the later one wins, and every version is kept — so a bad change is one revert away rather than an argument.
| Syntax | Means |
|---|---|
— value | an attribute |
→ value | a relationship — what your architecture diagram is drawn from |
[verified] | a human settled it; stop re-deriving it |
Two minutes to local. An account only matters when you want to share.
Python 3.9 or newer, no dependencies. The app is keepctx, and it also
installs ctx as a short alias, which is what the examples below use. If
another ctx is already on your PATH the alias is skipped and
keepctx works the same.
curl -fsSL https://keepctx.com/install.sh | shCreates .ctx/, adds two lines to AGENTS.md, and ignores itself
in git. The name defaults to your directory.
cd ~/work/example-project
ctx init
Initialized `example-project`
.ctx/example-project/facts.md your facts
.ctx/instructions.md how the agent maintains them
AGENTS.md pointer added at the top
Tell your AI to re-read AGENTS.md.Your agent reads .ctx/instructions.md, learns the rules, and starts
recording what matters — corrections, hard-won findings, decisions. Nothing else to do.
Local works forever with no account. ctx remote puts it on a server so
your team gets it — and so it survives a dead laptop.
ctx remote # one time, creates it on the server
ctx sync # two-way. mostly automatic after thisctx clone your-org:your-contextShown as ctx; keepctx works the same everywhere.
ctx | status |
|---|---|
ctx init [name] | set up here. local, no account, no network |
ctx remote | one-time. create this context on a server |
ctx clone org:name | get a context you don't have |
ctx sync | upload local changes, download remote ones |