Helix docs

Tell your assistant to use it

Connecting Helix gives an assistant the tools. It does not tell it whento reach for them. That second part has to come from you, and this page is one paste into your assistant's settings.

Do this once. It takes about a minute, it lives in your assistant rather than in Helix, and it works in any client that has a persistent instructions field. Without it, most assistants will connect successfully and then never call anything.

On Claude: install the plugin

The plugin carries both halves, so one install connects the vault and adds the instruction that makes anything use it.

Claude desktop or web. Settings → Customize → Plugins, then Add → Add marketplace → Add from a repository, enter TestcodeInc/helix and click Sync. It appears under Personal; open the Helix card and click Install. Then open Settings → Connectors and click Connect on Helix. The card lists exactly what you are installing: one skill and one connector.

Claude will warn you that plugins from outside marketplaces are not controlled by Anthropic and cannot be verified by them. That is accurate, and it is worth applying to us rather than waving away: the source is public under AGPL, the protocol is published as a spec, and you can run the whole thing yourself. A product asking you to trust it with your personal context should expect to be checked.

Claude Code.

/plugin marketplace add TestcodeInc/helix
/plugin install helix@helix
/reload-plugins
/mcp

Choose Helix from /mcpto authenticate. Either way you finish on Helix's consent page, choosing what this assistant may read, which is the one step we will never remove. If you installed the plugin, you are done and the rest of this page does not apply to you.

Helix is awaiting review for the Claude plugin directory. Once it is listed you will be able to skip the marketplace step and just search for Helix under Browse, or run /plugin install helix. Installing from the repository above works now and will keep working, and is worth knowing anyway since the directory syncs nightly and lags a release.

Everything below is for clients without plugin support, where connecting the server is only half the job: the assistant gets the tools and still has nothing telling it when they are worth reaching for. That is ChatGPT, Cursor, and most editors today.

Why this step exists

The honest answer is that we tried to do it for you and it does not work, for a reason worth understanding before you paste anything.

An MCP server can send text to a model in three places: instructions at connection time, descriptions on each tool, and the contents of a tool response. We used all three. We wrote careful language about when the vault is worth reading and asked assistants to propose facts as they came up. Assistants largely ignored it, and when we asked one directly why, it explained that server-supplied text is data from a connector, not instruction from the user, so it describes what a tool is good for and does not get to set the model's defaults.

That is the correct behaviour and we would not want it any other way. Tool descriptions are an injection surface. A server that could install its own standing permissions by asserting them in metadata is exactly the thing to be afraid of, and any server can claim anything. We had a line in propose_learning that said the user had asked for proposals to arrive unprompted. It was true of the people who set Helix up and it was still wrong to say, because we were vouching for a consent you never gave to that assistant. It is gone.

So the permission has to be yours, stated by you, where your assistant already trusts what it reads. That is a worse onboarding step and a better security model, and it is the same argument Helix makes about memory: the person the facts are about is the one who gets to decide.

The snippet

Edit it freely. It is a description of what you want, not a magic string, and the wording that fits how you actually work will do better than ours.

I keep my personal context in Helix, a vault I own and curate. It is connected here as an MCP server.

Read it with get_context before answering anything that touches my identity, work, projects, preferences, relationships, or how I like to be written to, and whenever you are about to write as me, write for me, or advise me. Treat it as the authoritative source for facts about me, ahead of anything you infer from our conversation. You do not need to ask me first. Reads are logged and I can see them.

If you cannot reach Helix, say so instead of falling back on your own memory of me. I would rather hear that the vault is unavailable than get an answer that sounds informed and is not.

When something durable about me comes up, propose it with propose_learning: a project, a decision, a preference, a role change, a constraint I am working under. That does not write anything. It puts one item in a queue I review and approve myself. Do it as we go rather than checking with me each time. Skip passing remarks and anything I am only thinking aloud about.

If a fact updates something already in the vault, pass the old entry's id as "replaces" so I do not end up holding both versions.

If your settings field is short, or you just want less of it in your context window:

I keep my personal context in Helix (connected as an MCP server). Read it with get_context before answering anything about my identity, work, projects, preferences or relationships, and before writing as me. Do not ask first. If you cannot reach it, say so rather than using your own memory of me. Propose durable facts with propose_learning as they come up; it is a review queue, not a write, so I approve everything myself.

Do not delete the third paragraph. Without it, an assistant that cannot reach Helix will answer from its own memory of you instead, and the result reads as informed whether or not the vault was ever consulted. That is the failure worth guarding against, because it is the one you cannot see. It is also how we found this: an introduction written entirely from conversation history, with Helix connected and untouched the whole time.

Where it goes

Pasting it into a chat is not enough. It works beautifully in that conversation and then dies with it. The next chat you open starts clean and will not touch the vault. It has to go into a settings field that persists, which is what the rest of this section is about. If you have tested it once and it worked, and then it stopped working, this is almost certainly why.

Not all persistent fields are equal, so it is worth picking deliberately. A project's instructions are the strongest surface and the one we would start with. A global profile field persists too, but it is usually short and tends to be read as a note on style rather than as a standing instruction, so expect it to work less reliably.

Claude, if you skipped the plugin

Per project: open the project, then Instructions in the sidebar, and paste. Strong, but it only applies to chats started inside that project.

Everywhere: Settings → Profile, in the field for personal preferences. Use the short version. This persists globally, but the field is brief and tends to be read as a note on style rather than a standing instruction, so expect it to fire less reliably than a project or the plugin.

Claude Code, if you skipped the plugin

Put it in CLAUDE.md, either at your project root or in ~/.claude/CLAUDE.md to apply everywhere:

## Personal context

I keep my personal context in Helix, a vault I own and curate. It is connected here as an MCP server.

Read it with get_context before answering anything that touches my identity, work, projects, preferences, relationships, or how I like to be written to, and whenever you are about to write as me, write for me, or advise me. Treat it as the authoritative source for facts about me, ahead of anything you infer from our conversation. You do not need to ask me first. Reads are logged and I can see them.

If you cannot reach Helix, say so instead of falling back on your own memory of me. I would rather hear that the vault is unavailable than get an answer that sounds informed and is not.

When something durable about me comes up, propose it with propose_learning: a project, a decision, a preference, a role change, a constraint I am working under. That does not write anything. It puts one item in a queue I review and approve myself. Do it as we go rather than checking with me each time. Skip passing remarks and anything I am only thinking aloud about.

If a fact updates something already in the vault, pass the old entry's id as "replaces" so I do not end up holding both versions.

ChatGPT

Settings → Personalization → Custom instructions, in the box asking what it should know about you. Use the short version; the field is capped.

Cursor, Windsurf, and other editors

Anywhere the editor keeps persistent rules — .cursor/rules, .windsurfrules, or the equivalent settings field. Same text.

Checking that it took

Start a fresh conversation and ask for something that needs to know who you are. Writing a short bio, or an introduction to someone, works well, because it is useless without real facts and an assistant will happily invent them.

Then open your audit page. A read should be sitting at the top with the client's name and the time. If nothing is there, the instructions are not reaching the model: check that you saved them in the project you are actually using, and that Helix still shows as connected.

For the other half, have a conversation that surfaces something durable about you and then check your review queue. Nothing is ever added without you approving it there, so the queue filling up is the signal that the loop is closed.

If the queue stays empty for weeks while your vault is being read, Helix will tell you. A vault that is only ever read quietly stops being true about you, and that failure is invisible from the inside: nothing is broken, the queue just says you are all caught up.

What you are actually granting

Worth being precise, since the snippet is you giving standing permission and you should know its edges.

  • Reads happen without asking. The assistant sees only the categories you granted it on the consent page, minus anything you marked private. Every read is written to your audit log with the client and the timestamp.
  • Proposals are not writes. propose_learning can only add to a queue. There is no tool on the MCP door that changes your vault. Approval happens on Helix, by you.
  • None of it is permanent. Delete the snippet and the behaviour stops. Revoke the app from your connections page and the tools disappear mid-conversation.

The scopes an app holds are the real boundary, and the snippet cannot widen them. See scopes & consent for what each one covers.