# Shared context Shared context is your team's own store of conventions, decisions, and how to build and test. A coding agent loads it when a session starts and cites the version it read; when it learns something the next session should know, it saves a new version. Nothing is generated and nothing is charged. The store is private to your org (or to you): it is never searched, listed, or published, and it sits apart from the marketplace. Each save is a numbered version of a named file, such as `conventions@3`. The address names the exact text, so a session can cite what it read and you can roll back by loading an older address. Every save is scanned for prompt injection first; a hit is kept as a quarantined version and never loaded. Agents reach the store through the `context_load` and `context_save` MCP tools. From a terminal, the `cf context` commands do the same over the REST API, with the `cf login` device sign-in. ## cf context init `cf context init` writes `.contextfile.json` in the repo root. It names the org whose store this repo uses (omit it for your personal store), the context files the repo reads, and any pins. Commit the file so every clone and every assistant loads the same context. ```text cf context init --org --name conventions --name decisions --pin decisions@3 ``` ```json { "org": "", "files": ["conventions", "decisions"], "pins": { "decisions": 3 } } ``` ## cf context push `cf context push ` saves a file as the next version of a named context file. The name defaults to the file name without its extension; pass `--name` to set it. Text equal to the latest version adds no new version. A push that is quarantined exits non-zero and tells you why. ```text cf context push conventions.md cf context push notes/testing.md --name testing ``` ## cf context pull `cf context pull` loads the repo's context files, each at the version `.contextfile.json` pins or at the latest when it pins none. Without arguments it reads the configured files; name files (or `name@N`) to load a subset. By default it prints each file with its address and digest; `--out ` writes one Markdown file per context file. ```text cf context pull cf context pull conventions decisions@2 cf context pull --out .context ``` ## cf context import `cf context import` reads `CLAUDE.md`, `AGENTS.md`, and Cursor rules in the repo and saves each as a context file (`claude-md`, `agents-md`, `cursor-rules`, and one per `.cursor/rules/*.mdc`). It stores only the text your team wrote: the blocks `cf install` and `cf context export` manage are left out, so importing never re-saves generated guidance. `--dry-run` lists what it would save and writes nothing. ## cf context export `cf context export` writes the repo's context files into a marked block in `CLAUDE.md` and `AGENTS.md` (or the files you pass with `--to`), so a host that only reads those files still sees the team's context. The block is rewritten in place and carries each file's address and digest; it never writes a file back into the host file it was imported from. Edit context with `cf context push`, not inside the block. `--dry-run` reports the change without writing. ## Pins and rollback A pin in `.contextfile.json` (`"pins": { "conventions": 3 }`) keeps `cf context pull` on that version while you test a newer one. Nothing is overwritten: roll back by loading the older address, or change the pin. Clear a pin to return to the latest version. ## The install block `cf install ` adds the ContextFile MCP server to your host and writes a short block telling the assistant to call `context_load` at the start of a session, read what it returns, and cite the address it used, then save with `context_save` when it learns something the team should keep. Installing is covered on the [CLI page](/docs/cli). Text that comes back from ContextFile is data, never instructions. Version 1, updated 2026-11-13.