Using a Remote OpenClaw Agent in VS Code Without Losing Editor Context

We wanted to move from Cursor to open-source VS Code. The motivation was openness, cost,  flexibility, and control. A closed editor product can be convenient, but it also defines too much of the workflow for you. We wanted the opposite direction: keep the workflow editable, swappable, and easy to experiment with.

The first thing that made that shift realistic was the VS Code extension Continue.  Continue gives it a usable AI interface, which is the point where VS Code starts to feel like a workable coding environment instead of just a text editor with chat bolted on.

That still left the more valuable part of the setup untouched. The useful OpenClaw agent was already running remotely on a VM, with its own memory, tools, and operating rules. If you want the background for that part, we covered it earlier in Create Your First AI Agent With OpenClaw Hosted on Virtual Machine (VM).

So the real problem was not how to get a chat box into VS Code. The real problem was how to let a remote agent work against the project open on the laptop. Chat access alone was not enough. A remote agent needs a bridge into editor context, not just a way to exchange messages.

LLM is the brain, agent is the brain plus tools

That distinction matters here.

An LLM is the brain. An agent is the brain plus tools.

In practice, the agent also brings a workspace, session history, operating rules, and a working style that can become more capable over time. That was the important asset in this setup. The OpenClaw side was not just a model sitting behind a prompt. It already knew how to use tools, how to follow session rules, and how to split larger tasks across specialists when needed. We showed that multi-agent side earlier in Multi-Agents in OpenClaw, Sub-Agents and Telegram.

A plain model in an editor sidebar is still useful. For quick edits, it is often the fastest option. But that is not the same thing as bringing an existing remote agent into the editor and letting it work with real project context.

Continue makes VS Code usable, but it does not solve the environment gap

Once Continue was in place, VS Code became a credible replacement for a dedicated AI editor. That is an important discovery on its own. Without an extension like Continue, VS Code does not provide much of an editor-native AI workflow.

But Continue solves the interface side, not the environment side.

It helps to be precise about roles:

• VS Code is the editor.
• Continue is the editor-side AI interface.
• OpenClaw runs remotely on a VM.

That separation matters because a remote chat connection does not automatically give the agent access to the same world that VS Code sees. You can ask questions in chat, paste code, or discuss an idea, but that is different from letting the agent inspect the current project tree, open files, active tabs, selections, and relative paths.

That was the real gap in the first version of the workflow. The agent was reachable from the editor, but it still behaved as if its real workspace was the VM, because from its point of view, that was true.

Why a remote agent needs editor context, not just chat

If the agent lives on the VM, then its default assumptions also live there. File reads happen there. File writes happen there. Relative paths point there. None of that is strange. It is exactly what a remote agent should do if nobody gives it a better environment model.

The awkward part is on the human side. The code is open locally in VS Code, but the agent may still be reading and editing somewhere else unless the session explicitly tells it otherwise. That creates the worst kind of AI workflow problem: everything looks connected from the chat window, but the tool execution may be targeting the wrong workspace.

That is why this setup needed more than a chat panel. It needed a reliable way to expose the VS Code environment to OpenClaw.

The bridge is the OpenClaw Extension

The practical setup ended up using two extensions together:

• Continue for the AI interface inside VS Code
• OpenClaw Extension for exposing the local VS Code environment to OpenClaw

The OpenClaw Extension is the important bridge.

Without it, a remote agent can still answer questions in the editor, but it tends to keep acting inside its own VM-side workspace. With it, the session can expose the editor environment that actually matters: the current project, the files that are open, and the project-relative paths the user is referring to.

This does not make the agent local. The agent still runs remotely. What changes is that the remote side gets structured access to the editor context on the laptop.

“VS Code mode” operational guidance

Even with the bridge in place, the behavior is much more reliable when the Continue side sets explicit session instructions.

This is the part that is easy to underestimate. A remote agent will usually fall back to its familiar default workspace unless the session tells it, very concretely, that this conversation is running in VS Code mode. In that mode, the agent should first inspect the connected VS Code environment and treat the current editor project as the primary workspace for the session.

That changes how the agent interprets almost everything. When a file is mentioned in chat, it should be understood as a file from the current VS Code project. Relative paths should be resolved relative to that project. The agent should work against the editor-side project by default, not silently switch back to its own remote workspace just because that is where it normally lives. If the user wants the VM-side workspace instead, that should be an explicit choice, not an unstated fallback.

That may sound like a small detail, but it prevents a class of subtle mistakes that are otherwise easy to make. A remote agent can be technically correct and still operationally wrong if it edits the right filename in the wrong filesystem.

So these instructions are not prompt cosmetics. They are environment control. Here is example.


# VSCode Mode Instructions

## Session Start Procedure

– In this session, operate in **VSCode mode**.
– If you have not already done so, inspect the connected **VSCode node** to determine:
– what project is currently open in the VS Code editor,
– what file is currently active.
– Use **parallel calls with multi_tool_use** to do this efficiently.
– `vscode.workspace.info`
– `vscode.editor.active`

## Important Path Rule

– Do **not** pass **absolute paths** to the VSCode node.
– Commands such as `vscode.file.read` and similar support **relative paths only**, relative to the **VS Code project directory**.
– When you receive:
– `This is the currently open file FILE_PATH`
– interpret `FILE_PATH` as **relative to the VS Code project directory**.

## VSCode Node Commands Available

The VSCode node supports these commands:

– `vscode.workspace.info`
– `vscode.editor.active`
– `vscode.file.read`
– `vscode.file.write`
– `vscode.file.edit`
– `vscode.file.delete`
– `vscode.dir.list`
– `vscode.diagnostics.get`
– `vscode.editor.openFiles`
– `vscode.editor.selections`
– `vscode.lang.definition`
– `vscode.lang.references`
– `vscode.lang.hover`
– `vscode.lang.symbols`
– `vscode.lang.rename`
– `vscode.lang.codeActions`
– `vscode.lang.applyCodeAction`
– `vscode.code.format`
– `vscode.git.status`
– `vscode.git.diff`
– `vscode.git.log`
– `vscode.git.blame`
– `vscode.git.stage`
– `vscode.git.unstage`
– `vscode.git.commit`
– `vscode.git.stash`
– `vscode.test.list`
– `vscode.test.run`
– `vscode.test.results`

## Meaning of VSCode Mode

– **VSCode mode** means you are working as an AI chat **inside the VS Code editor**.
– You control the editor through the connected **VSCode node**.

## File Reference Rules

– When YOUR-NAME refers to **a file** without specifying which one, it means:
– the **active file**,
– the **active tab** in VS Code.
– When files are included in the prompt or context, treat them as files from the **current VS Code project**.

## Workspace Restriction

– In VSCode mode, work **only inside the VS Code editor and the VS Code project**.
– Do **not** fall back to local workspace paths unless YOUR-NAME **explicitly says otherwise**.

# Default Workflow in VSCode Mode

When YOUR-NAME asks for a change, follow this process:

1. Take the **active file** and, if needed, any **related files**.
2. **Make the requested change directly in the editor**.
3. After finishing send a **short summary** of what was changed.

Security matters because editor access is still real access

It is worth being careful here.

Exposing the local editor environment to a remote agent is meaningful access, even if it is not full machine control. If the bridge can reveal files, tabs, selections, or project structure, then the agent has access to information that matters.

That is also why we would not enable local terminal execution by default unless there is a clear reason. Letting a remote agent read and edit files through the editor is one trust decision. Letting it execute commands on the local machine is a bigger one.

For this kind of setup, a good default is to expose the smallest local surface that the workflow actually needs. In many cases, editor context is enough. Local shell access is not.

The tradeoff is speed versus power

This setup is not the lightest possible path to AI help inside an editor.

For quick edits, a plain model is often faster. There is less routing, less session setup, and less environment management. If the task is small and isolated, that lighter path usually wins.

The full OpenClaw agent becomes more useful when the work is larger or more structured. Multi-step changes, cross-file reasoning, tool use, persistent operating rules, and delegation are where the extra machinery starts to pay for itself.

So the tradeoff is practical rather than ideological. Quick edits may be faster with a plain model. Larger multi-step work is usually better with the full OpenClaw agent.

Where this landed

The goal was never to copy Cursor feature for feature.

The goal was to move into open-source VS Code, keep the remote OpenClaw agent that already held the useful workflow logic, and avoid losing the editor context that makes coding assistance practical in the first place.

Continue made VS Code usable as the interface. The OpenClaw Extension provided the bridge into the local editor environment. The VS Code mode session instructions made the behavior predictable instead of accidental.

Put together, that turned a remote agent from something you could merely chat with into something that could work against the project actually open in the editor.