Ctrlk
Tabnine websiteContact Sales
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Migrating from Tabnine CLI

Beta · Tabnine plugin for OpenCode v0.5.1

If you were using Tabnine CLI (the Gemini-CLI-based coding agent that Tabnine shipped before) and want to bring your configuration into tabnine-opencode, use the migration helper. It reads your Tabnine CLI configuration and installs the equivalent settings into opencode, one category at a time, without changing your Tabnine CLI files.

This guide covers:

  • What the migration helper is and what it moves

  • Installing the helper

  • Running the migration and approving each write

  • What is left behind on purpose

  • Migrating your context files (TABNINE.md)

Coming from something else? The migration helper is only for Tabnine CLI. If you were using upstream Gemini CLI or another agent, follow Install and configure tabnine-opencode from scratch.

What the migration helper is

The migration helper is a pair of interactive skills that run inside tabnine-opencode itself. Once installed, you launch them with /migrate and /migrate-context. Each wizard scans your Tabnine CLI configuration, shows you what it found, prints exactly what it intends to write, and waits for your approval before touching anything.

Nothing is deleted from your Tabnine CLI installation. If you want to keep using Tabnine CLI in parallel while you evaluate tabnine-opencode, you can.

The helper is distributed as an open-source repository, separately from the plugin, so you can inspect it before installing:

What gets migrated

/migrate covers five categories:

  • MCP servers from your Tabnine CLI settings.json, translated into opencode.json's mcp object.

  • Skills from ~/.tabnine/agent/skills/, copied into opencode's skills directory.

  • Agents (local subagents) from ~/.tabnine/agent/agents/, translated into opencode agent files. Tool-restricted agents keep their restrictions.

  • Slash commands from ~/.tabnine/agent/commands/, translated from TOML to opencode's markdown format.

  • Extension contents — the MCP servers, skills, agents, and commands bundled inside a Tabnine CLI extension. The extension manifest itself is not migrated (opencode has no equivalent), but its contents are.

/migrate-context handles your context files separately: TABNINE.md files at the repository root, in ancestor directories, and in subdirectories are copied into opencode's AGENTS.md format.

What is left behind on purpose

A few things do not migrate, and shouldn't:

  • Your Tabnine sign-in. tabnine-opencode uses its own credential storage, so a Tabnine CLI sign-in cannot be reused. Sign in to tabnine-opencode the way you would on a fresh install. See Sign-in and Models.

  • The built-in Tabnine MCP servers (tabnine-context, tabnine-coaching). The plugin registers them automatically, so migrating them would create duplicates. If you had either disabled in Tabnine CLI, the wizard tells you the equivalent switch here — see MCP Servers.

  • OAuth tokens for other MCP servers. These are not portable. You re-authenticate each remote MCP server on first use.

  • Themes, keybindings, and general settings (model selection, approval mode). Configure those directly in tabnine-opencode; see Configuration.

Installing the helper

Clone the repository and run its installer, or copy its files by hand.

1

Install with the script

By default this installs globally into ~/.config/opencode/, so tabnine-opencode picks up the helper on next launch. To install into the current project instead, pass --project.

2

Install manually

Copy the two skill folders and two command files into the corresponding places under ~/.config/opencode/ (or your project's .opencode/). The repository's README has copy-and-paste commands for macOS, Linux, and Windows.

3

Restart

Exit any running tabnine-opencode session and launch a new one. Skills and slash commands are loaded at startup.

Running the migration

Open tabnine-opencode in a directory where you want the migration scoped (or any directory, for a global migration), then run the slash command.

You can also ask in natural language ("migrate my tabnine cli config to opencode"); either entry point activates the same wizard.

The wizard runs in four steps.

1

Discover

The wizard scans the standard Tabnine CLI locations and prints an inventory: how many MCP servers, skills, agents, commands, and extensions it found, and where each came from. If a category is empty, it says so and moves on.

2

Ask

You are asked one question per category — target scope first (global or project), then MCP servers, skills, agents, slash commands, and extensions. Selecting an item here does not authorize a write; you are only telling the wizard what you might want to migrate.

3

Plan

The wizard resolves every selection to an absolute destination and prints a plan. This includes the target directory, every file it will create, overwrite, or back up, the MCP servers it will connect (so you can see which endpoints are being granted to the agent), and any change to an agent's permissions.

Nothing has been written at this point. Read the plan and either approve it, ask for changes, or stop. If you only wanted to preview a migration, ask for the plan and stop — that is the wizard's dry-run mode.

4

Write

Once you approve, the wizard performs the writes and then reports what happened, including any file it did not write and any warning worth acting on (for example, agents whose tool restrictions were translated).

Existing files are never replaced without your consent, and any file the wizard overwrites is backed up first to <path>.bak-<YYYYMMDD-HHMMSS>.

After the wizard finishes, exit tabnine-opencode and start a new session so the migrated items are loaded.

Two translations worth knowing

Most fields copy verbatim. Two change in ways worth surfacing, and the wizard reports both:

  • Agent tool restrictions. A Tabnine CLI agent that allowlists a specific set of tools becomes a tabnine-opencode agent with an equivalent permission block, so a restricted agent stays restricted. The two systems name their tools differently and a few names cover more ground in opencode than in Tabnine CLI, so the wizard lists the resulting permissions and flags any tool that gains access it did not have before.

  • MCP timeouts. Tabnine CLI defaults an MCP request to 10 minutes; tabnine-opencode defaults to 5 seconds. When a Tabnine CLI server has no explicit timeout, the wizard writes 10 minutes into opencode.json so a slow server does not appear broken after migration.

Credentials never end up in opencode.json

If a Tabnine CLI MCP server had a password or token written directly into its configuration (rather than as a $VAR environment reference), the wizard prints only the header or variable name and offers to replace the value with an {env:VAR} reference. Credentials are never copied into opencode.json unless you ask.

Migrating context files

Context files are handled by a separate wizard.

It follows the same plan-then-approve flow as /migrate, and because a merge appends to an AGENTS.md you may already rely on, it backs up the existing file first.

Context in a subdirectory is worth a moment's attention. Both Tabnine CLI and opencode read your global context file and every context file from the current directory up to the project root. They differ further down: Tabnine CLI picks up a subdirectory's context whenever the agent works in that subtree, while opencode reads context from the session's directory upward only. A file migrated to packages/api/AGENTS.md therefore applies when you start tabnine-opencode inside packages/api, but not from the repository root. The wizard points this out for each such file and offers to fold its content into the project-root AGENTS.md instead, which makes it always apply at the cost of widening the instruction to the whole repository. You choose per file.

/migrate-context is scoped per repository, so run it in each project whose context files you want to bring over. The global ~/.tabnine/agent/TABNINE.md file is offered too and only needs migrating once.

Uninstalling the helper

The helper is only there so you can run the migration. Once you're happy with your migrated configuration, you can remove it:

For a project install, replace ~/.config/opencode with .opencode. Restart tabnine-opencode after.

Your migrated MCP servers, skills, agents, and commands stay where the wizard wrote them — removing the helper does not remove them.

Troubleshooting

  • ConfigInvalidError at startup after a migration means one of the migrated fields is not accepted by opencode's config schema. The wizard reports which file it wrote; open it and fix the offending field, using the mapping tables in the helper's reference docs as a guide. For project-scoped issues, you can start tabnine-opencode with project config disabled while you fix it: OPENCODE_DISABLE_PROJECT_CONFIG=1 tabnine-opencode.

  • A migrated MCP server returns auth errors on first use. This is expected — OAuth tokens do not carry over. Re-authenticate through the server's normal flow.

  • A migrated skill or agent doesn't appear in tabnine-opencode. Confirm the migration wrote to the same config directory the plugin reads. You can list what opencode has loaded with opencode debug skill and opencode agent list; the wizard can also verify this for you if you ask.

For general tabnine-opencode troubleshooting, see Troubleshooting.

Last updated

Was this helpful?