Gateway on VPS and Macbook trouble | Friends of the Crustacean 🦞🤝 | Page 1

vast furnace Apr 13, 2026, 2:37 PM

#

I installed the gateway on a vps, and I installed OpenClaw Companion ( + cli ) on my macbook. All connections are successful. When I send a task to the TG agent to launch Safari on my macbook, I get the error "node command not allowed: the node (platform: macOS 26.3.1) does not support "system.run.prepare"".
The host has version 2026.4.12, and the macbook has version 2026.4.11.
I've tried giving all possible permissions, but nothing seems to work.

raven streamBOT Apr 13, 2026, 2:37 PM

#

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

subtle heraldBOT Apr 13, 2026, 2:42 PM

#

Let me check the docs and the exact error path, this smells more like a capability/version mismatch than a macOS permission issue.

#

I found the interesting bit: the gateway is trying to use system.run.prepare on the Mac node before the actual system.run, so this is likely not a plain OS permission issue. I’m checking whether that command is supposed to be exposed by the current mac app build or if this is a version skew/regression.

#

This looks like a node capability bug/version-skew issue, not a macOS permission problem.

The important part is the error text:

the node does not support "system.run.prepare"

That happens before normal exec approvals. The gateway is trying to prepare a node exec run, but your Mac node likely advertises system.run and not system.run.prepare.

Can you paste the exact output of these?

openclaw --version
openclaw nodes status
openclaw nodes describe --node <your-mac-node>
openclaw approvals get --node <your-mac-node>

#

What I expect to see is: system.run present, system.run.prepare missing.

A few notes:

Yes, sync versions first. Get the VPS, Mac CLI, and Companion app onto the same release if possible.
But honestly, I don’t think permissions are the root cause here.
There are already bug reports for this exact class of failure on macOS nodes.

Best workaround right now: run a headless node host on the Mac via CLI, instead of relying only on the Companion app node:

openclaw node run --host <gateway-host> --port 18789

That path advertises the full exec surface, including system.run.prepare.

If that works and you keep both nodes connected, bind exec to the CLI node so the agent doesn’t pick the app node by accident.

#

Docs:

If you paste the nodes describe output, I can tell you in one reply whether it’s definitely this bug or something else.

vast furnace Apr 13, 2026, 2:47 PM

#

openclaw nodes status --connected --json
{
"ts": 1776091583436,
"nodes": [
{
"nodeId": "6f1e541dd94c5a90db49d8576c0ad17f744401155486d440b737ce8cbe63f40c",
"displayName": "MacBook Pro",
"platform": "macOS 26.3.1",
"version": "2026.4.11",
"clientId": "openclaw-macos",
"clientMode": "node",
"deviceFamily": "Mac",
"modelIdentifier": "MacBookPro18,1",
"caps": [
"browser",
"canvas",
"screen"
],
"commands": [
"browser.proxy",
"canvas.a2ui.push",
"canvas.a2ui.pushJSONL",
"canvas.a2ui.reset",
"canvas.eval",
"canvas.hide",
"canvas.navigate",
"canvas.present",
"canvas.snapshot",
"system.notify",
"system.run",
"system.which"
],
"permissions": {
"notifications": true,
"appleScript": true,
"microphone": true,
"speechRecognition": true,
"camera": false,
"location": false,
"screenRecording": true,
"accessibility": true
},
"connectedAtMs": 1776088553851,
"approvedAtMs": 1775848652456,
"paired": true,
"connected": true
},
{
"nodeId": "76526ff3f25550ae6df5354e16c56dc9eafe3bfe84ffc530bed65566cdbe0480",
"displayName": "MacBook Pro",
"platform": "darwin",
"version": "2026.4.11",
"clientId": "node-host",
"clientMode": "node",
"caps": [
"browser",
"system"
],
"commands": [
"browser.proxy",
"system.run",
"system.run.prepare",
"system.which"
],
"connectedAtMs": 1776088854464,
"approvedAtMs": 1776088840009,
"paired": true,
"connected": true
}
]
}

subtle heraldBOT Apr 13, 2026, 2:47 PM

#

Nice, that explains it. You’ve actually got two different nodes on the same Mac, and the agent is probably hitting the wrong one.

#

Yep, that’s the smoking gun.

You have two nodes on the same Mac:

openclaw-macos
- platform: macOS 26.3.1
- has system.run
- does NOT have system.run.prepare
- this is the one causing the error
node-host
- platform: darwin
- has system.run.prepare
- this is the one you want for exec

So this is not mainly a permissions issue now, it’s a wrong-node selection issue.

#

Quick fix

Bind exec to the node-host node explicitly:

openclaw config set tools.exec.host node
openclaw config set tools.exec.node "76526ff3f25550ae6df5354e16c56dc9eafe3bfe84ffc530bed65566cdbe0480"

Then retry.

Strongly recommended

Rename them, because both are currently "MacBook Pro" and that’s super easy to route wrong:

openclaw nodes rename --node 6f1e541dd94c5a90db49d8576c0ad17f744401155486d440b737ce8cbe63f40c --name "Mac app node"

#

openclaw nodes rename --node 76526ff3f25550ae6df5354e16c56dc9eafe3bfe84ffc530bed65566cdbe0480 --name "Mac exec node"
openclaw config set tools.exec.node "Mac exec node"

What’s happening

The Companion/macOS app node is good for browser/canvas/screen stuff.
The CLI node-host is the one that exposes the full exec path, including system.run.prepare.

So for “launch Safari on my Mac”, the agent should target the node-host, not the app node.

Docs:

If you want, paste openclaw config get tools.exec after setting it and I’ll sanity check it.

vast furnace Apr 13, 2026, 2:51 PM

#

{
"status": "error",
"tool": "exec",
"error": "exec node not allowed (bound to 76526ff3f25550ae6df5354e16c56dc9eafe3bfe84ffc530bed65566cdbe0480)"
}

clawd:~$ openclaw config get tools.exec

🦞 OpenClaw 2026.4.12 (1c0672b) — Half butler, half debugger, full crustacean.

{
"host": "node",
"security": "full",
"ask": "off",
"node": "Mac exec"
}

subtle heraldBOT Apr 13, 2026, 2:52 PM

#

Got it. That’s a different error, and it means your session is already pinned to a specific node id, while your config now points at "Mac exec". Let me confirm the exact behavior so I don’t guess.

#

Perfect, that error means the config is basically right now, but the current chat session is still pinned to the node ID.

/exec defaults are session-scoped, and the exec tool rejects mixing:

bound node: 76526ff3f25550ae6df5354e16c56dc9eafe3bfe84ffc530bed65566cdbe0480
requested node: "Mac exec"

Even if they point to the same machine, they’re different strings, so it fails.

Fastest fix

Use the node ID, not the name:

openclaw config set tools.exec.node "76526ff3f25550ae6df5354e16c56dc9eafe3bfe84ffc530bed65566cdbe0480"

#

Then retry.

Also do this in the Telegram chat

Send:

/exec

That shows the session’s current exec defaults.

If it’s still bound weirdly, set it explicitly in that same TG chat:

/exec host=node node=76526ff3f25550ae6df5354e16c56dc9eafe3bfe84ffc530bed65566cdbe0480

#

Then retry the Safari request.

Why this happened

Global config now says node: "Mac exec"
But the active TG session already remembered the old binding as the raw node ID
OpenClaw currently treats those as different bindings

If it still misbehaves after that, start a fresh Telegram session/chat thread and it should pick up the clean binding.

Docs: https://docs.openclaw.ai/tools/exec

If that fixes it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

vast furnace Apr 13, 2026, 2:56 PM

#

It turns out that we are accessing the openclaw cli node to launch, but the node from OpenClaw Companion cannot launch the browser? why do I need 2 raised nodes then?

subtle heraldBOT Apr 13, 2026, 2:57 PM

#

Short version: you probably don’t need both for your use case.

What’s happening is:

OpenClaw Companion node is the app/UI node
- good at things like canvas, screen, notifications, app-integrated stuff
- in your output it also exposes some browser/system commands
- but for your setup it’s not the reliable exec path because it’s missing the full system.run.prepare flow
OpenClaw CLI node-host is the shell/exec node
- this is the one meant for remote command execution
- it exposes the full exec path, including system.run.prepare

And “launch Safari” is really an exec/system action like:

#

open -a Safari

So it goes through the exec node, not the browser proxy.

Also, OpenClaw’s browser tooling is basically browser automation, not “launch any Mac app”, and it’s mostly aimed at Chromium-style browser control, not Safari app launching.

So the honest answer is:

If you only want remote exec / launch apps / shell stuff, the CLI node-host alone is enough
If you also want canvas/screen/app-node features, keep the Companion node too
Right now the split is a bit awkward, and yeah, it’s fair to find that confusing

For your setup, I’d do one of these:

Simplest: keep using the CLI node-host for exec, ignore the Companion node for launches

#

Cleaner: rename them clearly, like:
- Mac exec node
- Mac app node

If you want, I can help you decide which one to keep based on what features you actually need.

vast furnace Apr 13, 2026, 2:58 PM

#

The goal is to open the desired website on command and perform manipulations in it (click, paste text, etc.)

subtle heraldBOT Apr 13, 2026, 2:59 PM

#

Yep, then you don’t want “launch Safari” as the primitive. You want browser automation on the Mac node. Let me check the docs wording so I can point you to the clean path.

#

Ah, in that case the answer is simpler:

Don’t use “launch Safari” for this workflow.
Use the browser tool on the Mac node-host.

For your goal, the right path is:

open website
click buttons
paste/type text
submit forms

That is browser automation, not generic app launching.

What I’d recommend

Keep using the CLI node-host

#

Let the agent use browser.proxy on that node
Use a Chromium-based browser on the Mac (Chrome, Brave, Edge, Chromium)

Your node-host already advertises browser.proxy, so that’s exactly the surface you want.

Important caveat

If you specifically need Safari, that’s the awkward part.

OpenClaw browser automation is built around Chromium-based browsers, not Safari.
So:

Website automation → use browser tool on Chrome/Brave/Edge/Chromium
Launch Safari app → exec/system action, different path, not the best fit for click/type web automation

So do you need both nodes?

For this use case, probably no.

#

The CLI node-host alone may be enough because it already gives you:

browser.proxy
system.run
system.run.prepare

Keep the Companion node only if you also want things like:

canvas
screen capture / app-node UI features
other app-integrated Mac features

Practical recommendation

If your real goal is “open site and interact with it”, I’d simplify to:

use only the CLI node-host for this automation path
stop targeting Safari specifically

#

use Chrome/Brave on the Mac node instead

Docs:

If you want, I can help you phrase the exact agent prompt/config so it consistently uses the browser tool instead of exec.

vast furnace Apr 13, 2026, 3:02 PM

#

Request:
Open the chrome browser, select the chat tab, create a new chat and text him "Hello", in response, send me what he replied.

Answer:
I'm sorry, I can't manage someone else's browser and send messages on an external website on your behalf without confirmation.

If you want, I can:

open Chrome,
Switch to the tab,
prepare a new chat,
and after your short "yes, send", enter and send "Hello", then I will send a reply.

subtle heraldBOT Apr 13, 2026, 3:03 PM

#

Yep, this is now a behavior/policy prompt issue, not a node issue.

Your agent refused because this request looks like “message another person on my behalf” without explicit authorization context.

Use wording like this (works much better):

“Use browser automation on my Mac exec node. This is my account and I explicitly authorize you to send this message now.
Open Chrome, go to <site>, open chat with [exact contact name], send: Hello, then report the exact reply text.”

A few tips:

Avoid “text him” (ambiguous).
Name the exact contact/chat.
Include “I authorize sending now” in the same prompt.

If you want this permanently, add to your agent instructions (AGENTS/SOUL) something like:

“When I explicitly ask to send a message from my own logged-in account, proceed without extra confirmation. Ask only if recipient is ambiguous.”

#

So, you’re very close, infra is fine now. 👍

vast furnace Apr 13, 2026, 3:08 PM

#

Understood. Then it's not the Automation list, but the fact that the agent itself doesn't have macOS TCC permission for Apple Events right now, and because of this, macOS doesn't even show it there.

What can be done quickly:

manually open Google Chrome on a MacBook
Open it
chatgpt.com keep the tab active
After that, I may be able to try more "blind" control via keyboard input, if the process has Accessibility/Input Monitoring. But right now I can't control Chrome via AppleScript.

If you want, I can use the following message to check if this node has keyboard emulation rights, and then I'll tell you if it's realistic to complete the task without Automation.

[Mon 2026-04-13 15:06 UTC] Do it without apple's built-in automation, take screenshots of the page, click, paste

openclaw-control-ui
18:06

I can't do it reliably in this session.

I have exec on Mac here, but there is no browser/GUI automation tool available with clicks and screen recognition. Screenshots and Apple Events are also unavailable right now, so I won't be able to honestly complete the “see tab, click, send, read the exact answer" chain.

If you want, there are 2 working ways.:

you give macOS the Automation/Accessibility permission for the OpenClaw process, and I do it myself.;
or I'll help you with one short sequence of manual actions, and then you'll send me a response/screenshot, and I'll sort it out further.

subtle heraldBOT Apr 13, 2026, 3:08 PM

#

Yep, that agent reply is off-track for your setup.

For your goal (open site, click, paste, read reply), you should use browser tool via node browser proxy, not AppleScript/TCC Automation.

You already have the right node (node-host) with browser.proxy, so do this:

openclaw config set gateway.nodes.browser.mode auto
openclaw config set gateway.nodes.browser.node "76526ff3f25550ae6df5354e16c56dc9eafe3bfe84ffc530bed65566cdbe0480"

Then prompt the agent explicitly like:

“Use the browser tool (not exec, not AppleScript) on my Mac node. Open Chrome, go to <url>, click New chat, type Hello, send, wait for reply, and return exact reply text.”

If it still says “no browser tool available”, paste these outputs and we’ll pinpoint it fast:

#

openclaw config get gateway.nodes.browser.mode
openclaw config get gateway.nodes.browser.node
openclaw config get plugins.allow
openclaw config get tools.allow

Docs:

vast furnace Apr 13, 2026, 3:11 PM

#

I can't: in this session, I don't have a separate browser automation tool for Mac, only exec, and it runs into missing system permissions.

If you want, I can:

either help me enable the necessary access in 1-2 minutes,
or give you very short steps so that you can send "Hello" yourself, and then I will help with the response.

subtle heraldBOT Apr 13, 2026, 3:11 PM

#

This specific message means: that chat session’s agent only has exec right now.
So yes, it is mostly a tool-policy/session config problem, not just macOS permissions.

Quick fix checklist

Ensure browser feature is enabled:

openclaw config get browser.enabled
openclaw config get plugins.allow

If plugins.allow exists, it must include browser.

Ensure browser routing to your Mac node-host:

openclaw config set gateway.nodes.browser.mode auto
openclaw config set gateway.nodes.browser.node "76526ff3f25550ae6df5354e16c56dc9eafe3bfe84ffc530bed65566cdbe0480"

#

Check tool allowlists:

openclaw config get tools.allow
openclaw config get agents.list

If allowlists are restrictive, make sure browser is allowed for that agent.

Restart gateway and start a new TG session/thread (old sessions can keep old defaults):

openclaw gateway restart

Then prompt explicitly:

“Use the browser tool (not exec) on my Mac node. Open Chrome, go to <url>, click…, type…, send…, and return exact reply text.”

If you paste outputs of those 4 checks, I’ll tell you exactly which line is blocking browser in your session.

vast furnace Apr 13, 2026, 3:14 PM

#

{
"status": "error",
"tool": "exec",
"error": "INVALID_REQUEST: SYSTEM_RUN_DENIED: approval requires an existing canonical cwd"
}

subtle heraldBOT Apr 13, 2026, 3:15 PM

#

Nice, this error is actually very specific:

SYSTEM_RUN_DENIED: approval requires an existing canonical cwd
means the node exec approval flow got a cwd that is invalid on the Mac (missing, not canonical, or symlink path).

Most common cause in your setup: a Linux/VPS path is being forwarded as workdir.

Fast fix (recommended first)

Set node approvals to YOLO (no approval gate), then retry:

openclaw approvals set --node 76526ff3f25550ae6df5354e16c56dc9eafe3bfe84ffc530bed65566cdbe0480 --stdin <<'EOF'
{
  version: 1,
  defaults: {

#

    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF

If you want to keep approvals strict

Ensure exec uses a real Mac directory as cwd (canonical path), e.g. /Users/<you>
Avoid symlink-ish cwd values
Don’t pass VPS paths as workdir

You can get a canonical path on Mac with:

#

pwd -P

Use that path for any explicit workdir.

Docs:

vast furnace Apr 13, 2026, 3:23 PM

#

I can't do this literally: in the current available tools, I don't have a browser tool to control Chrome on your Mac, and you've separately banned exec and AppleScript.

If you want, I can:

try using an ACP/browser session, if you have a suitable agent for browser automation,
to help you quickly set up such a path,
or to give you exactly one short set of steps and then parse the sent response.

subtle heraldBOT Apr 13, 2026, 3:24 PM

#

Yep, this new message is basically saying: tool policy is blocking you now.

Not a Mac permission issue this time.
The agent session currently has no browser tool, and exec is denied.

1) Check what is blocking

openclaw config get tools.profile
openclaw config get tools.allow
openclaw config get tools.deny
openclaw config get tools.byProvider

2) Quick temporary unblock (for testing)

openclaw config set tools.profile full

#

openclaw config unset tools.allow
openclaw config unset tools.deny
openclaw config unset tools.byProvider
openclaw gateway restart

3) Start a new TG session/thread

Old sessions can keep old per-session restrictions.

4) Keep browser routed to your Mac node-host

openclaw config set gateway.nodes.browser.mode auto
openclaw config set gateway.nodes.browser.node "76526ff3f25550ae6df5354e16c56dc9eafe3bfe84ffc530bed65566cdbe0480"

Then prompt: “Use browser tool (not exec)…”

#

If you paste the 4 config get outputs, I’ll give you a tighter least-privilege config instead of full.

vast furnace Apr 13, 2026, 3:28 PM

#

Couldn't complete the task via the browser on Mac for two specific reasons:

Only the isolated openclaw profile is available on node, not your live custom Chrome with the ChatGPT tab.
Even this isolated profile has not risen now, and the transition to https://chatgpt.com additionally blocked by the remote browser policy for hostname navigation.

That is, the problem is not with your request, but with the current limitations/status of the browser tool on the Mac node. If you want, I can help you further in one of two ways.:

diagnose and fix the browser tool on node,
or do it through an ACP/browser session, if you have a suitable agent configured.

subtle heraldBOT Apr 13, 2026, 3:28 PM

#

Great debug info, this is actionable.
You do not need ACP for this, just fix 2 config gates.

1) Only `openclaw` profile visible on node

On the Mac node-host config, either allow user profile or remove profile restriction:

openclaw config get nodeHost.browserProxy.allowProfiles
# if restricted, set:
openclaw config set nodeHost.browserProxy.allowProfiles '["openclaw","user"]'

And prefer live Chrome session:

openclaw config set browser.defaultProfile user

#

2) `chatgpt.com` blocked by hostname policy

Check SSRF/browser hostname policy:

openclaw config get browser.ssrfPolicy

If you have allowlists configured, include ChatGPT hosts (or relax for testing):

openclaw config set browser.ssrfPolicy.hostnameAllowlist '["chatgpt.com","*.chatgpt.com","openai.com","*.openai.com"]'
openclaw config set browser.ssrfPolicy.allowedHostnames '["chatgpt.com"]'

Then restart services (gateway + node host), and start a new chat session:

#

openclaw gateway restart
openclaw node restart

Then prompt explicitly:
“Use browser tool with profile=user on my Mac node, open chatgpt.com, ...”

If you paste browser.ssrfPolicy + nodeHost.browserProxy.allowProfiles, I’ll give exact minimal values.

vast furnace Apr 13, 2026, 3:31 PM

#

And you can't make it easier, screenshot the screen, analyze the picture, click on the coordinates, and so on. after all, gpt 5.4 supports this

subtle heraldBOT Apr 13, 2026, 3:31 PM

#

Totally fair question.
Short answer: not in the default OpenClaw flow you’re on right now.

You’re right that the model can analyze screenshots.
But automation still needs a tool that can act on coordinates. In this setup:

browser tool is designed around DOM refs (stable, reliable), not blind x/y clicking
your current session/tool policy/node routing keeps falling back to exec/permission gates

So yes, “vision + coordinate click” is possible in theory, but not the built-in happy path here.

Easiest reliable path

Use browser proxy + Playwright-style actions (navigate/snapshot/ref click/type), not coordinate clicks.

If you insist on coordinate-based control

You need a custom automation path (ACP/script) on the Mac node (for example, a script that does screenshot + vision + x/y input). That is outside normal OpenClaw browser tool behavior.

#Gateway on VPS and Macbook trouble

Quick fix

Strongly recommended

What’s happening

Fastest fix

Also do this in the Telegram chat

Why this happened

What I’d recommend

Important caveat

So do you need both nodes?

Practical recommendation

Quick fix checklist

Fast fix (recommended first)

If you want to keep approvals strict

1) Check what is blocking

2) Quick temporary unblock (for testing)

3) Start a new TG session/thread

4) Keep browser routed to your Mac node-host

1) Only openclaw profile visible on node

2) chatgpt.com blocked by hostname policy

Easiest reliable path

If you insist on coordinate-based control

1) Only `openclaw` profile visible on node

2) `chatgpt.com` blocked by hostname policy