LM Studio Code

A real coding agent in VS Code — running entirely on the models you already have in LM Studio.

Not autocomplete. This is a full agent panel: it reads and edits your files, runs shell commands, asks permission before it touches anything, works through a todo list, and keeps going until the job is done. Everything runs on your machine against LM Studio — no cloud round-trip, no API key, no token bill, works on a plane.

Powered by the open-source OpenCode agent, bundled right in. Install, pick a model, start working.

Demo

---

The agent

• Real tools — reads files, writes edits, runs shell commands, searches your codebase. Every step shows up as a tool card you can expand.
• You stay in control — inline permission prompts with Allow once, Allow always, or Deny, plus a permissions picker in the composer: Auto (the default — safe actions run on their own; outside-the-workspace access and .env reads ask first), Manual (every tool call asks), or Bypass (nothing asks — for workspaces you trust).
• Build or plan mode — build edits your code; plan is strictly read-only for when you just want a strategy.
• Live todo list — the agent's plan renders as a checklist that ticks off in place as it works, with a progress count.
• See it think — reasoning models get collapsible Thinking blocks, folded away with how long the model thought once a turn ends. Toggle Show reasoning in the behavior menu to hide them without changing how the model works.
• Dial the thinking — set reasoning effort per model from the behavior menu's Thinking slider or /effort. The levels offered are the ones the model actually reports: most local reasoning models are on/off, so you get Auto · Off · On rather than a low/medium/high slider that would do nothing. Models with no reasoning support hide the control entirely.
• Streaming everything — responses render as markdown with syntax-highlighted code as they arrive.

Agents — specialists you define

• Bring your own agent — drop a .opencode/agent/<name>.md in your workspace (YAML frontmatter + a body that becomes its system prompt) and it shows up in the agent picker. Each agent can pin its own model, restrict which tools it may use, and set its own reasoning effort.
• mode decides who reaches it — primary puts it in your picker; subagent keeps it out of the picker and lets the model delegate to it through the built-in task tool when your request matches its description; all does both.
• Delegation saves context, it doesn't spend it — a subagent runs in its own session with its own context window and returns only its answer, so a long search doesn't fill up the conversation you're having.
• /agents shows both halves — what you can select, and what the model can delegate to. /agents new <name> scaffolds a definition and opens it.
• Heads up: new agents are picked up when the OpenCode server restarts, and delegation depends on your local model reliably calling tools — smaller models may just answer directly instead.

Goals — point it at an objective and walk away

• /goal <objective> starts an autonomous loop. After each turn, an isolated judge — running on your local model — decides whether the goal is actually met. If it isn't, the agent continues with specific feedback about what's still missing.
• A pinned goal bar tracks the objective, round count, and elapsed time, with edit / pause / resume / clear controls.
• It can't run away — a 25-round cap plus stall detection that pauses the loop and tells you why when progress flatlines.
• It listens — change your mind mid-goal and it notices, offering a one-click Update goal instead of chasing a stale target.

Steer it mid-flight

Type while the agent is working and hit Enter — your message is handed to it at its next step, so it adjusts work already in progress instead of you stopping and starting over. Hit ⌥/Alt+Enter instead to queue it for when the current turn finishes.

Messages waiting to be picked up sit above the composer, marked Steering or Queued: switch one between the two, or cancel it before the agent ever sees it. Each lands in the conversation at the moment the agent actually reads it, so the transcript stays in the order the model saw things. The stop button still stops.

Your models, your machine

• Live model picker — every model in LM Studio, showing loaded ● / unloaded ○, context size, publisher, format (MLX/GGUF), and quantization, so same-named models are never ambiguous. Load or eject right from the menu.
• Context handled for you — the extension reloads your model with an adequate context window via the lms CLI, so a 4096-token default never blows up mid-task.
• Room to think — the output budget scales with the context window (up to 32k), so long reasoning doesn't get chopped off mid-answer. If a response does hit the ceiling, you're told.
• Multiple servers — register several LM Studio instances, local or remote, and switch between them in a click.
• Per-server API keys — connect to remote instances behind authentication. Keys live in VS Code's encrypted Secret Storage: never in a settings file, never sent back to the UI, never inherited by tool processes the agent spawns.
• Quiet by default — a 30-second liveness check shared across panels, paused when hidden. Your LM Studio log stays readable, and a busy server no longer flashes "offline" mid-generation.

Context, without the busywork

• Highlight to share — select code in any file and it's automatically attached to your next message, exact lines and range included. The + menu lists what's going along, so nothing rides invisibly.
• /file toggles the open file as context.
• Paste images — screenshots and mockups attach as labelled chips with dimensions; click for a full-size lightbox.
• /compact summarizes the conversation to reclaim context when you're running low, and shows you the summary it produced.
• A context meter above the composer so you always know where you stand.

Sessions that survive

• Auto-restored — reopen VS Code and your last conversation is right where you left it, per workspace.
• Full history — browse, resume, rename, and delete past sessions. Empty chats never clutter the list.
• Work in parallel — Open in Editor Tab gives a conversation its own tab, so you can run several at once.

Extend it — MCP servers and skills

• MCP tools — browser automation, databases, issue trackers, docs. Local (stdio) and remote (http/sse) servers both work, and their tools get the same tool cards and permission prompts as built-ins.
• Nothing to re-enter — the .mcp.json you already wrote for Claude Code and the .vscode/mcp.json you wrote for VS Code are discovered automatically.
• /mcp shows live status per server: 🟢 connected, 🟡 disabled, 🔴 failed with the reason. A broken server never blocks your chat.
• /skills lists the skills available to the model with their source (project / global / built-in) and path — your .opencode/skill and .claude/skills are picked up too.
• Slash commands — type / for a filterable menu: /clear, /compact, /file, /mcp, /skills, /goal, /help, plus your own skills and OpenCode commands, with arguments.

Fits your window

The panel lives in the Activity Bar (or the secondary side bar). The composer keeps four controls — + for context, ? for slash commands, the model chip and the permissions chip — with everything else one click inside them, so it stays legible in a narrow side bar.

---

Quick start

1. Start LM Studio's server and load a model.
2. Install this extension.
3. Click the spark icon in the Activity Bar.
4. Pick a model, type a task, hit Enter.

Requirements

• VS Code 1.104+
• LM Studio running with its local server started (default http://127.0.0.1:1234) and at least one chat model
• (recommended) the lms CLI for automatic context-window management

OpenCode 2 runs inside the extension — there is no separate server to install, start or stop, no port, and nothing left running when VS Code closes. It works offline. An OpenCode install elsewhere on your machine (yours, Homebrew's) is never used and never affected: the panel keeps its own sessions and settings.

OpenCode is MIT-licensed by anomalyco/opencode; its notice ships with the extension as opencode-sdk/LICENSE.opencode. This extension is an independent project and is not affiliated with or endorsed by the OpenCode maintainers.

Beta channel

New features ship to the Marketplace pre-release channel first (odd minor versions, e.g. 0.13.x; stable releases use even minors). To try betas, open the extension's Marketplace page in VS Code and click Switch to Pre-Release Version — VS Code updates you along the beta track and you can switch back any time with Switch to Release Version.

Settings

Setting	Default	Description
lmstudioCode.lmStudioBaseUrl	http://127.0.0.1:1234/v1	LM Studio OpenAI-compatible base URL
lmstudioCode.defaultModel	(first)	Default model id
lmstudioCode.agent	build	build or plan
lmstudioCode.autoEnsureContext	true	Reload model with adequate context before prompting
lmstudioCode.minContextLength	32768	Context length to (re)load with
lmstudioCode.defaultThinkingEffort	auto	Starting reasoning effort (auto/off/low/medium/high) for models you haven't set one for
lmstudioCode.gpuOffload	max	GPU offload for lms load
lmstudioCode.healthCheckSeconds	30	Health/model poll cadence while connected (5–600). Disconnected retries stay at 5s; the model list refreshes immediately while the model picker is open
lmstudioCode.mcpServers	{}	MCP servers to expose to the agent (in addition to auto-discovered ones)

MCP servers

The agent can call tools from MCP (Model Context Protocol) servers — browser automation, databases, issue trackers, docs, and more. OpenCode runs the servers; this extension just gathers them from wherever you've configured them and hands them over.

Where servers come from

Servers are merged from these sources, in increasing precedence (a later source wins on a name collision):

#	Source	Format	Top-level key
1	.mcp.json at your workspace root	Claude Code project format	mcpServers
2	.vscode/mcp.json in your workspace	VS Code workspace format	servers
3	VS Code's user-level mcp setting	VS Code user format	servers
4	lmstudioCode.mcpServers (VS Code settings)	bare map of name → server	(the map itself)

If you already use MCP with Claude Code or VS Code Copilot, those servers work here with nothing to re-enter. Use lmstudioCode.mcpServers to add a server just for LM Studio Code, or to override a discovered one.

Setting up a .mcp.json (shareable, per project)

Create .mcp.json at your project root — the same file Claude Code uses, so it's safe to commit and share with your team:

{
  "mcpServers": {
    // local (stdio) server — runs a command, talks over stdin/stdout
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest"]
    },
    // local server with a working dir and env var
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "."],
      "env": { "LOG_LEVEL": "info" }
    },
    // remote (http/sse) server, with a token pulled from the environment
    "docs": {
      "type": "http",
      "url": "https://example.com/mcp",
      "headers": { "Authorization": "Bearer ${MY_TOKEN}" }
    },
    // defined but off — won't be started
    "staging": {
      "command": "npx",
      "args": ["-y", "some-mcp-server"],
      "enabled": false
    }
  }
}

A .vscode/mcp.json is identical except the top-level key is servers instead of mcpServers (VS Code's convention) — both are supported.

What's supported

Field	Applies to	Notes
command	local (stdio)	Executable name or path (e.g. npx, uvx, an absolute path).
args	local (stdio)	Array of arguments passed to command.
env	local (stdio)	Environment variables for the server process.
type	both	"http" / "sse" mark a remote server; "stdio" / "local" a local one. Inferred from the fields when omitted (a url ⇒ remote, a command ⇒ local).
url	remote (http/sse)	The server endpoint.
headers	remote (http/sse)	HTTP headers, e.g. an Authorization token.
enabled	both	Set false to keep a server defined but not started.

• ${VAR} references in env values, headers, and url are resolved from the environment before the server launches — keep secrets in your environment, not in the file.
• Transports: local (stdio) and remote (http/sse). Both the Claude Code field shape (command + args) and the VS Code shape are accepted and normalized for you.

Checking status — the /mcp command

Type /mcp in the chat to list your configured servers and their live status:

• 🟢 connected — running and its tools are available
• 🟡 disabled — defined but "enabled": false
• 🔴 failed — couldn't start/connect; the reason is shown (a bad server never blocks the chat)

Each row shows the transport (local/remote) and the command or URL it was configured with.

Notes

• Applying changes. Edits to lmstudioCode.mcpServers (or VS Code's mcp setting) restart the agent automatically. Edits to the .mcp.json / .vscode/mcp.json files apply on the next LM Studio Code: Restart OpenCode Server (or a window reload).
• Mind the context window. Each MCP server adds its tool schemas to every request. Local models have far less context than cloud ones (OpenCode's own system prompt + built-in tools already use ~11k tokens), so enable only the servers you need and raise lmstudioCode.minContextLength if tools start crowding out the conversation.
• npx/uvx on PATH. Local servers launched with npx/uvx need Node and those tools on PATH. The extension augments PATH with common install locations (Homebrew, ~/.local/bin, nvm/fnm, bun, cargo), but if a server shows as failed, check LM Studio Code: Show Logs.

How it works

VS Code webview (chat UI)
        │  postMessage
        ▼
Extension host ─ bridge
        │  in-process calls + event stream
        ▼
OpenCode 2 (@opencode/sdk,   ──OpenAI /v1──▶  LM Studio (local model)
  embedded, no server)

OpenCode runs inside the extension host through its embedding SDK — no process, no port, no password. The LM Studio provider is handed to it in memory when it starts — nothing is written to your workspace or global config, and it is the only provider enabled (a key exported in your shell, or OpenCode's own LM Studio auto-discovery, is never picked up behind your back). Discovered LM Studio models are declared in the provider's models map with the context window LM Studio actually loaded and their vision and reasoning settings. Its sessions, database and settings live in the extension's own storage, isolated from any OpenCode you run yourself; chats from earlier versions carry over.

A server's API key never sits in the config text: it is written to a 0600 file and referenced with OpenCode's {file:…} placeholder, which the engine resolves at load.

Develop from source

npm install
npm run bundle:opencode-sdk  # build the embedded OpenCode engine into opencode-sdk/ for your platform
npm run compile              # type-check + bundle (extension + webview)
# then press F5 in VS Code to launch the Extension Development Host
npm test                     # unit tests
npm run test:integration     # drives the real webview in a VS Code instance
npm run test:live            # the engine against LM Studio on :1234
npm run test:e2e             # every feature through the panel, against LM Studio on :1234
npm run package:vsix:bundled # build a platform .vsix with the engine embedded

The engine is built from @opencode/sdk, pinned to an exact version in devDependencies — its API is still marked experimental, so upgrades are deliberate. opencode-sdk/ is generated and git-ignored; run bundle:opencode-sdk once before launching the dev host, and again after changing the pinned version.

test:e2e and test:live need a tool-capable vision model in LM Studio (default qwen/qwen3-vl-4b; the LM Studio tests eject, load and resize it through the panel; reasoning is exercised against a scripted server, so no reasoning model is loaded). Override with E2E_BASE_URL / E2E_MODEL and LIVE_BASE_URL / LIVE_MODEL.

License

MIT