Repository navigation
Feature Request - Remote Executor support #88
Description
In order to help task/process isolation ... being able to delegate to a remote executor like Coder or Docker or a remote VM (via SSH) seems like a nice way to help mitigate some of the LLM-generated code risk.
Coder has an MCP Server, so this may not be necessary .. but I can't say the same thing for pre-configured remote execution via SSH (to a known / specific instance) or otherwise -- that seems like a nice capability that OpenClaw project spent a good chunk of time on.
Activity
arefbehboudi commentedon Sep 13, 2026
Good call — this is worth doing, and I want to get the design right from the start.
The key principle: the agent stays on the host, only execution moves. JavaClaw's brain — LLM calls, channels, scheduling, skills, memory, and chat history — stays local. What gets delegated is tool execution: bash commands and the file operations tied to them, running in an isolated
sandbox/scratch directory. So a skill stays on the host, but when it runsgit cloneandnpm build, those happen remotely.One thing we want to get right:
execand file ops (read/write/edit) have to go through the same executor, or they can drift — runnpm installremotely but read files locally, and the agent won't see what it just created.Planned shape: an
Executorinterface withLocalExecutor(default),DockerExecutor, andSshExecutor. Docker first — it gives us a well-defined isolation boundary with relatively little setup — then SSH to a known instance, which is the case you raised. Daytona and others can follow once the abstraction is stable.As you noted, MCP-based tools like Coder already work through the existing MCP client, so this focuses on the non-MCP paths. Pairs naturally with skill-sandboxing, so we'll design them together. Keeping this open to track it.