MyContext: a local-first context layer for your work history

The problem MyContext targets: your work history is scattered and every AI prompt starts empty

Most knowledge work leaves a trail across instant messaging, documents, calendars, meetings and approvals. None of those systems knows about the others, and none of them is organized around you. The README puts the cost plainly: instead of making every AI start from an empty prompt, MyContext provides a durable context layer that models, local agents and authorized external AI applications can retrieve from. The intended user is an individual, not a team or an IT department. The repository describes a "persistent personal work context layer for every individual," and the principles section repeats the framing: organize information around the individual, not around the application that produced it. That is a narrower audience than it first appears. A team that wants a shared knowledge base is not the target. A person who wants their own messages, documents and meeting records searchable and reusable by whichever model they choose is.

How the ingestion and retrieval layers fit together

The README separates source access from context consumption, and the repository layout mirrors that split. Channels handle authorization, source discovery, reading and controlled actions. Ingest handles scheduling, normalization, checkpoints, retries and incremental synchronization, which is what keeps local copies current without rereading everything. Store holds the on-disk SQLite vault, migrations, source records and message indexes. Above that sit the context pipeline (structured facts, preferences, relationships, evidence), retrieval (full-text plus semantic recall with source references), the knowledge graph (entities, facts, relationships, community processing), the persona layer that runs the digital self, and an agent runtime with isolated sessions and scoped permissions. The desktop app is Electron plus React and ties them together. One design decision is worth calling out because it is easy to miss: the README states that if the agent runtime is unavailable, search falls back to ranked local results rather than inventing an answer. That fallback is the difference between a degraded search box and a confident wrong answer, and it is the kind of choice that should be more common.

Installing MyContext and running the desktop app from source

There is no published installer described in the README, so the path is to build from the repository. The root package.json sets the toolchain: pnpm 10.13.1 as packageManager, Node at least 22.17.0 and below 23, and pnpm at least 10.13.0. The .nvmrc file is there for a reason, and the engines field will reject anything outside that Node range. Start by installing dependencies and copying the environment template.

nvm use
pnpm install
cp .env.example .env

The .env.example documents the variables you can set. MYCONTEXT_LOG_LEVEL accepts debug, info, warn or error. MYCONTEXT_DATA_DIR overrides the data directory in development; if you leave it empty the app uses the system default userData directory. MYCONTEXT_DEV_PORT defaults to 5273, and the comment explains that it deliberately avoids Vite's 5173 because running several Vite projects on one machine collides. The port is not silently reassigned when busy; the app errors out instead, to avoid a white screen from a main process that cannot connect. Then start the dev flow.

pnpm dev

That script runs verify:toolchain, prepare:bin and native:electron before filtering to @mycontext/desktop dev, so expect a native rebuild step on first run. The model gateway variables in .env.example are marked as reserved for a later stage: the file says the current stage only verifies that injection works and that keys are masked, and issues no network requests. MYCONTEXT_LLM_BASE_URL and MYCONTEXT_LLM_API_KEY are the shared gateway, and MYCONTEXT_MODEL_MAIN is described as the main model for all model calls, including digital-self replies, the search agent, work-layer extraction and knowledge graph building when no separate KL model is configured. The settings page in the app takes precedence over the .env value. A separate KL gateway block exists because, per the comment, switching the main model once broke Chinese extraction, so knowledge graph extraction keeps its own door. Search's opencode agent reuses the same MYCONTEXT_LLM_BASE_URL and MYCONTEXT_LLM_API_KEY; the ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN variables are only needed if you want search pointed at a different gateway, and they take priority over the MYCONTEXT_LLM_* pair.

The developer preview warning is not boilerplate

The README opens with a developer preview notice in bold: there will be compatibility-breaking changes. The paragraph that follows is the part to read twice. Local data lives in an on-disk SQLite vault under versioned migrations, and a migration can require you to re-run collection. Some changes may not be reversible. The README's own instruction is not to treat this build as the only home for anything you cannot re-derive. That is a real constraint, not a disclaimer. If your only copy of a meeting record is the one MyContext ingested, a migration that is not reversible can cost you it. Collection has to be re-runnable from the source, which means the source still has to exist and still has to be reachable. The second limitation is coverage. The README says the current codebase includes working ingestion paths for instant messaging conversations, documents and meeting records. Calendars, tasks and approvals, mail, local work artifacts and agent interactions are described as things the source model is designed to expand to, which is not the same as supported today. If your context lives mainly in a calendar or a mail client, this build does not reach it yet.

How MyContext differs from a notes vault or a hosted AI assistant

A tool like Obsidian is a place you write into. MyContext is a place that reads from your existing systems and organizes what it finds around you. The difference in approach matters for effort: a notes vault asks you to capture, while MyContext's ingest layer handles scheduling, checkpoints and incremental synchronization so you do not. The cost is that you are trusting an automated pipeline to decide what is worth keeping. The comparison to a hosted assistant such as ChatGPT or Claude with connectors is sharper. A hosted assistant processes your context on someone else's infrastructure and, in most configurations, you cannot inspect the intermediate representation. MyContext keeps the vault, indexes and derived context in your own data directory, and the README's principles state that models and agents use the context through controlled interfaces while the user owns the data and permissions. The trade is operational: you supply the machine, the disk, the model gateway and the updates. There is also a licensing difference. Elastic License 2.0 is source-available, not open source in the OSI sense. You may use, modify and self-host it, including inside a company, but you may not offer it to third parties as a hosted or managed service. A team that wants to run MyContext as a paid product for its own customers is outside the grant.

Licence, maintenance and the cost of keeping up

The package.json declares Elastic-2.0, and the README points to the LICENSE file for full terms, noting that third-party components under kl-graph/ and vendor/ keep their own licenses. That last sentence is the one to act on if you plan to redistribute anything: the licence of the product does not automatically cover what it vendors. This is not legal advice, and the LICENSE file is the authority. On maintenance, the repository is not archived and the last push was on 2026-08-31, which is recent. The README's status section says the core desktop flow, local data layer, search and answer experience, personal context graph and digital-self workflow are implemented, while supported sources and external integrations continue to expand, and it asks readers to treat the project as an evolving working prototype rather than a finished product. There are no releases listed, so there is no published version history to read. Upgrading means pulling main and accepting whatever migrations come with it. The .env.example hints at how much churn to expect: it documents a MYCONTEXT_SEARCH_MODEL variable that was removed, explaining that it only read real environment variables and never reached the agent subprocess from the .env file. Variables in this project have been renamed and retired before, so a config that works today is not a config that works after the next pull. Budget for reading the diff of .env.example and the migration files, not just for running pnpm install.

Editorial conclusion

Adopt MyContext if you want your work context to stay on your own disk and you accept a developer preview that warns of compatibility-breaking changes and non-reversible migrations. Skip it if you need a finished product, a hosted service, or a source connector set beyond IM, documents and meetings. Before you commit, check the LICENSE file for the Elastic License 2.0 terms, confirm the Node and pnpm versions in package.json match your toolchain, and decide where MYCONTEXT_DATA_DIR should point, because that directory is the only copy of what the app has collected.

Frequently asked questions

Official sources

1. Issues
2. openTrinity/mycontext on GitHub
3. Project website
4. README