OpenCursor: a local-first AI coding agent for VS Code

What OpenCursor is for, and who it is aimed at

OpenCursor is a VS Code extension that puts an agentic chat in the activity bar. The agent reads the workspace, edits files, runs shell commands and searches the codebase by meaning rather than by keyword. The README frames the target user clearly: someone who wants Cursor-style agent behaviour but does not want to leave VS Code, and who may not want their code leaving the machine at all.

The distinctive claim is local-first operation. The README states that OpenCursor is "designed to work without internet once set up", pairing a local model with a local embedding index. That combination is what separates it from extensions that assume a hosted model and a hosted embedding endpoint. The provider list is the second half of the pitch: OAuth sign-in for Claude Code, OpenAI Codex and Google Antigravity accounts, API keys for OpenAI, Anthropic, Gemini and OpenRouter, plus any OpenAI-compatible or Anthropic-style endpoint you add yourself.

The package.json declares the extension as ocursor with publisher pkrd, and the marketplace listing is at itemName=pkrd.ocursor. The engine requirement is VS Code ^1.96.0, so older builds will not load it.

The agent loop, the tool surface, and the local embedding index

The architecture visible in the repository is a standard VS Code split: an extension host process in src/ compiled by esbuild into dist/extension.js, and a webview UI in webview-ui/ with its own TypeScript config. The chat view is registered as a webview inside a view container called ocursor-sidebar, so the conversation lives in the activity bar rather than in an editor tab.

Tool execution is where the agent does its work. The README lists 25 tools covering read, write and edit, shell execution, grep and glob, semantic search, web search and fetch, notebooks, todos, subagents and MCP. Modes gate what the agent may do: Agent, Ask, Plan, Debug and Multitask, with Ask and Plan documented as read-only. Approval is handled per action with allow, ask, review or deny, and the README says the policy applies risk heuristics to patterns such as rm -rf, sudo, .env and secrets, alongside wildcard allow and deny lists. That is a more granular control surface than a single yes/no confirmation prompt.

Semantic search is the part that shapes the offline story. The README describes an on-device ONNX MiniLM model that builds an index automatically, updates it incrementally and stores it locally, with no embedding API and no key. If you prefer hosted embeddings, the README says you can point the extension at any OpenAI-compatible /embeddings endpoint. The trade-off is implicit: a MiniLM-class model is small enough to run on a laptop CPU, and small embedding models are generally weaker at distinguishing near-identical code than larger hosted models. The README does not publish retrieval accuracy numbers, so the only honest way to judge it is on your own repository.

Edits are reviewed through per-hunk Keep and Undo CodeLenses, which the README notes work without git. That matters in repositories where the working tree is already dirty, since you are not forced to commit or stash before letting the agent write.

Installing OpenCursor and running a first local session

The README gives two installation routes. The first is the VS Code Marketplace listing, or a .vsix file from the Releases page. The second is building from source. The marketplace route is the one most readers want; the source route is for anyone who needs to read or modify the extension.

The build sequence from the README uses pnpm and compiles the extension bundle:

git clone https://github.com/PawanOsman/OpenCursor.git
cd OpenCursor
pnpm install
pnpm run compile   # or: pnpm run watch

After that, pressing F5 in VS Code launches the Extension Development Host, which is the standard way to run a development build of an extension. The README also documents pnpm run vsix for producing a package. Expect the first activation to take longer than a normal extension start: the README states that native runtime dependencies, specifically ONNX runtime and image processing, are downloaded once on first activation with integrity checks because they are too heavy to ship in the VSIX. On a restricted network that download is the first thing that can fail, and the README does not describe an offline or mirror option for it.

Once the sidebar is open, provider selection is the next step. For a local run, the README offers one-click llama.cpp installation or pointing at an already-running Ollama instance. Choosing llama.cpp means searching Hugging Face for a GGUF model, picking a quantization, and letting OpenCursor spawn and manage llama-server. The README lists the launch controls exposed: context size, GPU layers, flash attention, KV cache types, speculative decoding and vision through --mmproj. Those are llama.cpp server flags, so the extension is effectively a configuration front end for llama-server rather than a wrapper around a different runtime.

With a model selected, Ctrl+L on a selection sends it to the chat, and the agent can then read files, search the index and propose edits. The per-hunk Keep and Undo CodeLenses appear on each edit.

Where OpenCursor is the wrong tool

The first limitation is version maturity. The releases listed are 0.1.1, 0.1.2 and 0.1.3, with package.json already at 0.1.4. That is pre-1.0 software with a short release history, and the README does not document a rollback procedure or a compatibility policy between versions. If you need a supported product with a deprecation path, this is not it.

The second is the dependency on VS Code. Everything runs inside the editor, so there is no headless mode, no CI integration and no terminal client described in the README. A team that wants an agent in a build pipeline cannot use this.

The third is the local model ceiling. The README advertises airplane-mode coding, but the quality of that experience depends entirely on the GGUF model you choose and the GPU layers you can afford. A quantized model small enough to run on a laptop will make more mistakes on multi-file edits than a hosted frontier model. The extension gives you the plumbing; it does not close that gap.

The fourth is documentation depth. The README describes features at a marketing level and says little about failure handling. It does not document what happens when the ONNX runtime download fails, how the index behaves when files change during a build, or how conflicts between an agent edit and a manual edit are resolved. The repository has a CHANGELOG.md, so release-level changes are tracked there, but the README is not a manual.

How OpenCursor differs from Cline and Continue

The obvious comparison is Cline, the open-source VS Code agent that popularised the plan-and-act loop with explicit approval for every file write and shell command. Both extensions live in the same sidebar, both use MCP, and both support multiple providers. The difference in approach is the local stack. Cline's model support is broad, but OpenCursor goes further by managing llama-server itself: it searches Hugging Face for GGUF files, downloads a quantization and exposes the server flags in its own settings. Cline does not ship a managed local runtime in the same way, so a fully offline setup there means running your own inference server.

Continue is the other reference point. Continue is built around customisable autocomplete and chat with configuration files that teams check into a repository, which makes it easier to standardise across a team. OpenCursor is agent-first and its configuration is extension settings such as ocursor.model and ocursor.maxResponseLength rather than a repository-level config file. If your priority is shared, versioned configuration, Continue's model fits better. If your priority is an agent that can run with no network and no API key at all, OpenCursor's built-in llama.cpp management is the more direct path.

Maintenance, upgrade cost, and the MIT licence

The repository is not archived and the last push was on 2026-09-08, nine days before this article. Release 0.1.3 landed on 2026-09-07, roughly five weeks after 0.1.2 on 2026-08-01. That cadence suggests active work, but with only three releases published there is no track record for how breaking changes are handled between versions. The practical upgrade cost is re-verifying your provider configuration after each release, since the extension fetches model lists live and the provider surface is still moving.

The licence is MIT, declared in both the README and package.json. MIT is permissive: you can use, modify and redistribute the extension, including in commercial settings, provided the copyright notice and licence text are retained. That is a statement about the licence text, not legal advice about your situation. One thing worth noting for anyone planning to fork: the extension downloads native runtime dependencies on first activation, and those components carry their own licences, which the README does not enumerate.

Editorial conclusion

Adopt OpenCursor if you already pay for a Claude, Codex or Antigravity subscription, or if you need an agent that can run with no network at all through llama.cpp and Ollama. Skip it if you want a vendor-supported product with a documented rollback path, or if you need an agent that works outside VS Code. Before installing, verify three things: whether the runtime dependencies download cleanly on your network, whether a local embedding index is accurate enough for your repository, and how the approval policy behaves on shell commands in your project.

Frequently asked questions

Official sources

1. License: MIT
2. PawanOsman/OpenCursor on GitHub
3. Project website
4. README
5. Releases