How to Migrate From GitHub Copilot to Tabnine Without Losing Context (2026)

Copilot's customization surface has five layers, and only three of them are files.

Personal instructions. The documentation is explicit about both scope and location: they are "only supported for GitHub Copilot Chat in GitHub," you set them "in a popup on the Copilot Chat page on GitHub.com," and Copilot "will only apply" them to you. There is no file. There is no repository. There is a text box on a web page, per person.

Repository custom instructions, of which there are three types. Repository-wide instructions in a copilot-instructions.md file in the .github directory. Path-specific instructions in one or more files ending .instructions.md within or below .github/instructions. And agent instructions, which the docs describe as "similar to repository-wide custom instructions, but are currently not supported by all Copilot features," specified in files called AGENTS.md, CLAUDE.md, or GEMINI.md.

Organization custom instructions, set by organization owners in Copilot settings, and applied — in the documentation's words — "for all members of the organization, irrespective of whether they receive their Copilot subscription from that organization."

Now the order they resolve in:

"Multiple types of custom instructions can apply to a request sent to Copilot. Personal instructions take the highest priority. Repository instructions come next, and then organization instructions are prioritized last. However, all sets of relevant instructions are provided to Copilot."

That last sentence is the one people skip. Precedence resolves conflicts; it does not remove layers. Every applicable instruction is still sent. So a personal instruction contradicting an organization standard does not replace it — it outranks it, while both remain in context.

On the Tabnine side, the equivalent surfaces are guidelines. The documentation describes them as "Markdown files stored in your project's /.tabnine/guidelines/ directory," and notes the directory can live either in your home directory or per-project. Its own analogy for them: "Think of these in a similar fashion to the agents.md file that other agentic tools use." The sizing advice is "keep your guidelines.md file to 500 lines or less."

Then the sentence that inverts your migration. Describing guidelines entered in the Admin Console:

"Guidelines that are input here will have the same effect as guidelines listed in your guidelines.md file, but they will take precedence over personal guidelines that exist in the guidelines.md file."

So: files transfer. Path-specific scoping transfers, roughly, since Tabnine supports multiple guideline files. What does not transfer is the resolution order. And what has no destination at all is the popup — the per-person instructions that were never in a repository, never reviewed, and never visible to anyone else.

Worth separating from all of this: none of these layers is codebase awareness. Instruction files tell the assistant how to behave, not what your code contains, which is why Copilot forgetting codebase context is a different complaint from Copilot ignoring your rules. Tabnine's answer to the first problem is Personalization and its Connection feature; its answer to the second is guidelines. Do not migrate one expecting to fix the other.

There is a second structural difference worth knowing before you plan the work, because it splits your team in two. Tabnine's CLI does not read the project guidelines directory the way the IDE plugin does. Its documentation opens with the difference stated plainly:

"Agent guidelines are managed differently in Tabnine CLI than they are for the Tabnine IDE plugin."

In the CLI there are two flows. Organization and service-account instructions are "added to the agent's operating context," fetched automatically for your authenticated account when the CLI starts. Separately, coding guidelines are reachable through a built-in Tabnine Coaching Guidelines tool that the agent calls when it needs language-specific rules. The documentation is careful to separate the two, because the toggle only governs one of them:

"This setting doesn't control whether organization or service-account instructions are fetched and added to the session context."

Two steps, and the first one is the one everybody skips.

Step 1: Get the personal instructions out of the popup

Before touching a single file, ask every person on the team to open the Copilot Chat page on GitHub.com and read their personal instructions aloud to you. Not paraphrase — read.

This feels like busywork and it is the highest-value hour of the whole migration, for two reasons. First, personal instructions are the top of Copilot's precedence order, which means whatever is in there has been silently winning conflicts against your repository standards and your organization settings. Second, they are invisible: there is no file to grep, no PR to review, no audit trail. If someone wrote "always use the older client library, the new one breaks our proxy" eight months ago, that instruction has been shaping their output ever since and nobody else knows it exists.

Sort what comes out into two piles. Genuine personal preference — response language, verbosity, explain-one-concept-per-line — stays personal. Project facts wearing a personal costume go into the repository, because that is where they always belonged. This is the same failure mode behind agents ignoring your instruction files: the instruction that wins is not the one you think you wrote.

While you are in that popup, note that Copilot's other per-user surface — the memory feature in the IDE, covered in setting up Copilot memory in VS Code — is also per-person and also not a file. Read those too.

Step 2: Rebuild the file layers as guidelines, then re-decide every conflict

Now the copy, which is mechanical, followed by the part that is not.

Your repository-wide copilot-instructions.md becomes a guideline file in .tabnine/guidelines/. Your path-specific .instructions.md files become additional guideline files — Tabnine reads multiple files from the directory, so keep them separate rather than merging, and name them for what they cover. Your AGENTS.md can stay exactly where it is, because it is an open convention that other tools in your stack read; just be aware Tabnine's guidelines directory is what its own documentation points at. If your instruction files started life on the other side of that fence, moving a CLAUDE.md into Copilot covers the shape they arrived in.

One free correction while you are here. Tabnine's docs write the analogy in lowercase, as agents.md. Other tools that read the same convention require the uppercase filename and will silently skip a lowercase one. In a repository shared across tools, name it AGENTS.md.

Then the real work. For every place where your organization standard and someone's personal instruction disagreed, you now have to pick a winner, because Tabnine's admin console will pick one for you and it will pick the opposite of what Copilot picked. Go through the conflicts one at a time and decide which layer should hold each rule. Anything that is genuinely an organizational standard goes in the admin console, where it now outranks everyone's local file — and note the propagation delay the docs mention: changes "will be applied in the IDE extension after 15 minutes, or upon restarting the IDE or the extension."

This is also where you discover the thing no migration guide can do for you. Deciding which rule wins requires knowing why each rule exists, and that information is not in either tool.

The conflicts you are resolving in Step 2 are only hard because the reasons were never written down. "Use the older client library" versus "standardize on the current SDK" is unresolvable as two imperatives. It is trivial once you know one of them was written the week the proxy broke and the proxy was replaced in June.

MemoryLake holds that layer — the decisions, the rejected alternatives, and the reasons — outside both tools, and serves them to whichever agent asks over MCP or the API. Your guidelines stay short and imperative in .tabnine/guidelines/, your admin console holds standards, and the "why" behind each one is queryable by anyone on any tool.

Step 1: Create an API key

Generate a key and make your first request in about thirty seconds. Do this before Step 2 above, so you have somewhere to record each conflict as you resolve it.

Step 2: Upload your first memories

For every rule you kept, write down what it decided, what it ruled out, and why. The personal instructions you collected in Step 1 are the richest source here — most of them encode a real incident. Supporting documents and files go in the same place.

Step 3: Connect your AI & agents

Give Tabnine, Claude, Codex, and your other agents access over MCP or the API. When the next standard is proposed, the answer to "didn't we try that" arrives with its reasoning attached.

The first change is that the invisible layer stops being invisible. Copilot's highest-priority instruction surface was a per-person text box; after this migration the equivalent content is either an explicit personal preference or a recorded project decision, and the second kind is readable by the whole team.

The second is that admin-console precedence becomes a feature rather than a trap. Once organizational standards genuinely are organizational — reviewed, reasoned, recorded — having them outrank local files is what you want. The inversion only hurts when the admin console holds guesses.

The third is that the IDE-versus-CLI split stops fragmenting your team. Developers in the IDE read guideline files; developers in the CLI get organization and service-account instructions plus the Coaching Guidelines tool. Those are different mechanisms, and a shared reasoning layer both halves can query is the thing that makes their answers agree.

The fourth is that the next migration is a file copy for real. The part that made this one hard — reconstructing intent from imperatives — happens once. This is the same reason what coding agents actually read matters more than which file format a given tool prefers.

Audit the popup before you audit the files. Personal instructions are top-priority in Copilot and have no file trail. They are the only part of your old setup that cannot be reconstructed later.

Put standards in the admin console, preferences in the local file. The precedence order now rewards that split, and fighting it by duplicating standards locally just creates conflicts the console wins anyway.

Keep guideline files short and separate. The documentation recommends 500 lines or less per file, and the directory takes multiple files. One topic per file beats one long file.

Remember the propagation delay. Admin console changes reach the IDE extension after a wait or a restart. When a standard changes, tell people rather than assuming they saw it.

Do not assume the CLI sees your project guidelines. The CLI's documented flows are organization and service-account instructions plus the Coaching Guidelines tool. If your team is split across both surfaces, verify what each one is actually loading.

Use uppercase AGENTS.md. One vendor's lowercase example is another vendor's silent miss, and it costs nothing to get right.

Write the reason next to the rule. Every conflict you resolved in this migration existed because someone wrote an imperative without its cause. The next one will too, unless the reason has somewhere to live.

Migrating from GitHub Copilot to Tabnine moves three file layers cleanly and inverts the one thing you cannot see. Copilot documents personal instructions as its highest priority and organization instructions as its lowest, while still sending every applicable layer to the model. Tabnine documents the admin console as taking precedence over the personal guidelines.md. Copy the files without addressing that, and rules that used to win start losing, quietly, on the same inputs.

The work that makes the migration safe is not the copy. It is emptying the popup, sorting genuine preference from project fact, and deciding which layer should own each rule — which you can only do if you know why the rules exist. Record that once, outside both tools, and every future move becomes what this one looked like from the outside: moving some markdown and signing in.