#ACP SSH

1 messages · Page 1 of 1 (latest)

trail path
#

Can an ACP cwd to remote ssh?

lament orioleBOT
vocal solarBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

lament orioleBOT
still moatBOT
#

Not directly.

ACP cwd is just an absolute path on the machine where the ACP harness is running. It is not an SSH target, so things like ssh://host/path or user@host:/path are not valid cwd values.

What works:

  • /acp spawn codex --cwd /absolute/path
  • /acp cwd /absolute/path

What does not work:

  • /acp cwd ssh://box/home/me/repo
  • using ACP cwd to make Codex/Claude Code hop to another machine over SSH

Relevant bits:

  • ACP docs: <https://docs.openclaw.ai/tools/acp-agents>
  • Sandbox/SSH docs: <https://docs.openclaw.ai/cli/sandbox>

If you want remote-over-SSH execution, the better options are:

#
  1. run OpenClaw/ACP on the remote machine, then use a normal local path there, or
  2. use runtime="subagent" with the ssh sandbox backend instead of ACP

So, short version: ACP cwd can point to a remote machine only if ACP itself is already running on that machine. It cannot SSH there just from cwd.

trail path
#

I run openclaw on machine A, I have projects on machine B which is using Cursor to maintain.

Per you conclusion, can I interact with the cursor agent on machine B to maintain the project via openclaw agent on machine A?

still moatBOT
#

Short answer, not in the direct way you're picturing.

If OpenClaw is on machine A, ACP harness sessions like cursor are launched on machine A. So OpenClaw on A does not natively reach over SSH and “attach to Cursor on B” just by setting cwd.

So for your setup:

What does not work

  • OpenClaw on A
  • runtime: "acp" / /acp spawn cursor
  • cwd somehow pointing to a project on B
  • expecting that to drive Cursor on B

That path is not how ACP is wired today.

What can work

Option 1, best if you want Cursor specifically

#
  • run the ACP side on machine B instead
  • then Cursor on B works against the repo locally on B
  • OpenClaw can talk to that setup, but the actual harness needs to live where the files are

Option 2, best if you just want remote repo maintenance

  • keep OpenClaw on A
  • use a subagent with the SSH sandbox backend to operate on B
  • that gives you remote execution on B, but it is not Cursor ACP

Option 3, bridge Cursor on B to Gateway on A

  • Cursor on B can connect to OpenClaw on A via openclaw acp
  • but that is more “Cursor talks to OpenClaw” than “OpenClaw launches Cursor remotely”
  • I would not treat that as full remote-Cursor-control for repo maintenance

Docs:

#

If you want, I can sketch the cleanest A/B architecture depending on whether your priority is:

  1. must use Cursor on B, or
  2. just need OpenClaw to edit code on B.