Launch integrations

ollama launch <integration> is the second-largest surface in the project. It configures a third-party tool (typically a coding agent or chat client) to use the local Ollama daemon as its backend, and then launches it.

Purpose

Make Ollama useful with the AI tools users already have. Each integration knows where its config lives, what shape that config needs to point at the Ollama daemon, and how to start the underlying executable. The launcher consolidates this so the user just types ollama launch claude (or droid, codex, …).

Supported integrations

Each one has its own implementation file under cmd/launch/, registered in cmd/launch/registry.go:

Name	File	Description (from the registry)
claude	claude.go	Anthropic's coding tool with subagents (Claude Code)
cline	cline.go	Autonomous coding agent with parallel execution (hidden)
codex	codex.go	OpenAI's open-source coding agent
copilot (alias: copilot-cli)	copilot.go	GitHub Copilot CLI
droid	droid.go	Factory's coding agent
hermes	hermes.go	Hermes Agent (managed-single-model integration)
kimi	kimi.go	Moonshot's Kimi Code CLI (hidden)
opencode	opencode.go	OpenCode
openclaw (aliases: clawdbot, moltbot)	openclaw.go	OpenClaw — Ollama's first-party assistant for WhatsApp / Telegram / Slack / Discord
pi	pi.go	Pi
pool	poolside.go	Pool / Poolside
vscode (alias: code)	vscode.go	VS Code

Key abstractions

Symbol	Location	Purpose
LaunchCmd	cmd/launch/launch.go	Cobra command builder. ollama launch with no integration shows the bubbletea menu; with an integration name it dispatches.
LaunchIntegration	cmd/launch/launch.go	The orchestration entry point. Resolves the integration, runs install hints if needed, picks a model, writes config, execs the runner.
IntegrationSpec	cmd/launch/registry.go	One entry per integration: Name, Runner, Description, Install.
Runner interface	cmd/launch/launch.go	Run(model, args) — hand off to the underlying tool.
Editor interface	cmd/launch/launch.go	For multi-model integrations: Paths, Edit, Models.
ManagedSingleModel interface	cmd/launch/launch.go	For Hermes-style integrations that own a single primary model.
LaunchPolicy	cmd/launch/launch.go	Controls confirmation behavior (prompt / auto-approve / require --yes) and missing-model behavior (prompt to pull / auto-pull / fail).
DefaultSingleSelector / DefaultMultiSelector / DefaultSignIn / DefaultConfirmPrompt	cmd/launch/launch.go	Indirection points for UI; cmd.init() in cmd/cmd.go replaces them with bubbletea implementations.

How it works

sequenceDiagram
    participant User
    participant CLI as ollama launch
    participant Daemon as ollama serve
    participant Spec as IntegrationSpec (registry)
    participant Tool as third-party tool

    User->>CLI: ollama launch claude
    CLI->>Daemon: heartbeat (PreRunE)
    CLI->>Spec: resolve "claude"
    Spec-->>CLI: { Runner: Claude{}, Install: ... }
    CLI->>Spec: Install.CheckInstalled?
    alt missing
        CLI-->>User: install hint or auto-install
    end
    CLI->>CLI: pick model (TUI selector or --model)
    CLI->>CLI: rewrite Claude config to point at Ollama
    CLI->>Tool: exec claude
    Tool->>Daemon: HTTP requests

Each integration's Runner.Run execs the underlying binary. The config-rewriting step uses paths returned by the integration (e.g., ~/.claude/settings.json) and is golden-tested by huge per-integration test files (cmd/launch/<name>_test.go).

Policy modes

LaunchCmd reads --yes and whether stdin/stdout are TTYs to derive a LaunchPolicy:

• Interactive, no --yes: prompt the user; prompt to pull missing models.
• Interactive with --yes: auto-approve; auto-pull missing models.
• Non-interactive (no TTY): require --yes to confirm; fail on missing models.

This makes the same command safe in scripts and in the desktop launcher's webview.

Integration with the TUI

cmd.init (cmd/cmd.go) wires the bubbletea TUI in cmd/tui/ into the launcher's selector hooks. When the user runs ollama launch with no argument or no --model, the launcher calls tui.SelectSingle for model picking and tui.RunSignIn for cloud sign-in. The launcher itself never imports bubbletea — it relies on these injection points so unit tests can swap in raw stubs.

OpenClaw

The OpenClaw integration (openclaw.go) is the largest by far — it hosts the Ollama-published WhatsApp/Telegram/Slack/Discord bot through the same launch flow, including Onboard for first-time setup and RefreshRuntimeAfterConfigure for live config drift handling. Recent commits (launch: harden OpenClaw onboarding flow (#15777), launch: use bundled OpenClaw ollama web search (#15757)) show it's actively evolving.

Adding a new integration

1. Add cmd/launch/<name>.go implementing Runner (and Editor or ManagedSingleModel if applicable). Mirror the simplest existing integration that fits the shape.
2. Register an IntegrationSpec in cmd/launch/registry.go, including the Install recipe.
3. Add cmd/launch/<name>_test.go exercising Configure, Edit, and Run. Existing tests are large and table-driven — match the style.
4. Add the integration to the long-form Long: help text in LaunchCmd.
5. Document it under docs/integrations/ if user-facing.

Integration points

• cmd/cmd.go registers the launch subcommand and injects bubbletea selectors.
• api/client.go is the daemon client every integration uses.
• cmd/config/ is the local CLI config; some integrations remember user choices through it.

Key source files

File	Purpose
cmd/launch/launch.go	Cobra command and orchestrator.
cmd/launch/registry.go	Per-integration descriptor table.
cmd/launch/models.go	Model picking, recommendations, cloud-vs-local.
cmd/launch/selector_hooks.go	Indirection for selectors.
cmd/launch/<name>.go	One per integration.