macOS app node browser proxy fails, but CLI node-host on the same Mac works | Friends of the Crustacean 🦞🤝 | Page 1

slate swallow Apr 14, 2026, 2:07 PM

#

Env*

Gateway host: Debian 12 VPS, OpenClaw 2026.4.12, installed via global npm
Mac OS: macOS 26.4
Mac OpenClaw app: 2026.4.11
Mac OpenClaw CLI/node-host: 2026.4.12
Gateway stays on VPS; Mac connects remotely over WSS as a node

Goal
Use the Mac as a controllable node from the VPS, especially browser control.

Browser profiles on Mac

chrome-live = existing-session
openclaw = managed profile

Relevant config/state

gateway.nodes.browser.mode = "auto"
tested with CLI node-host and macOS app node separately
macOS app exec approvals were enabled
same Mac, same Chrome setup, same gateway

Repro

Turn off Mac CLI node-host, open macOS app only
Confirm connected node is MaccyAir (openclaw-macos/node, app v2026.4.11)
Run browser status against that node with:
- profile=chrome-live
- profile=openclaw
Both fail with:
- UNAVAILABLE: Could not connect to the server.

Then:

Close macOS app, run CLI node-host only
Confirm connected node is Maccy Air (node-host/node, CLI 2026.4.12)
Run browser status again
profile=chrome-live works normally (existing-session, chrome-mcp, running=true, cdpReady=true)
profile=openclaw responds normally too, just shows browser not launched yet (running=false, cdpReady=false)

Important
The macOS app node still looks normal for other capabilities/permissions (canvas/camera/screen appear present), so this does not look like a general permission or Chrome-profile problem.

Question
Is this a known difference between openclaw-macos/node and node-host/node for browser proxy support, or could it be due to the version mismatch:

macOS app 2026.4.11
gateway + CLI node-host 2026.4.12

tardy agateBOT Apr 14, 2026, 2:07 PM

#

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

sly valveBOT Apr 14, 2026, 2:07 PM

#

wary jayBOT Apr 14, 2026, 2:09 PM

#

Let me check the ref checkout and the browser/node code path so I can give you a real answer, not a guess.

#

Short answer: this looks much more like the app being on 2026.4.11 than a permanent “macOS app node can’t do browser proxy” limitation.

A few reasons:

node-host browser proxy is the documented remote-browser path: https://docs.openclaw.ai/cli/browser and https://docs.openclaw.ai/tools/browser
Current source shows the macOS app does advertise browser.proxy in node mode when browser control is enabled, so it is supposed to work
The 2026.4.12 changelog has a very on-point fix:
- “macOS app/chat UI: route browser proxy through the local node browser service”
Your failure text, UNAVAILABLE: Could not connect to the server., matches the app-side proxy failing to reach its local browser service, not a Chrome profile/auth problem

So my recommendation is:

Update the macOS app to 2026.4.12 or newer
Re-test with app only
If it still fails, check whether the local browser control endpoint is listening on the Mac at gateway.port + 2 (usually 127.0.0.1:18791 unless you changed gateway.port)

Given your repro, I would currently treat this as a version-specific macOS app bug/fix gap, not an intentional difference between openclaw-macos/node and node-host/node.

#

If you want, I can help you with a tight post-update verification checklist next.

slate swallow Apr 14, 2026, 2:15 PM

#

if i wanna update macos app, can i just install the lastest version's dmg and override it? or i need to uninstall the current 4.11 version first?

wary jayBOT Apr 14, 2026, 2:15 PM

#

Yep, you should normally be able to just install the newer DMG over it. No uninstall first.

What I’d do:

Quit OpenClaw.app
Open the new DMG
Drag OpenClaw.app into Applications
If Finder asks, click Replace
Launch it again and verify the version

That should not wipe your normal OpenClaw state/config, since the app bundle and ~/.openclaw state are separate.

If macOS somehow keeps launching the old copy, then do the slightly more forceful version:

delete /Applications/OpenClaw.app
copy the new one in fresh

But I would not start with uninstalling 4.11.

#

Docs: https://docs.openclaw.ai/install/updating and https://docs.openclaw.ai/platforms/macos

slate swallow Apr 14, 2026, 2:19 PM

#

so do i need to always ensure that the versions of the VPS OpenClaw, the Mac node OpenClaw, and the macOS app remain consistent at all times?

wary jayBOT Apr 14, 2026, 2:19 PM

#

Not strictly at all times, no.

But for anything cross-machine and feature-heavy like remote node browser control, I’d strongly recommend keeping them on the same release, or at least very close.

Good rule of thumb:

Best: gateway, macOS app, and node-host all on the same version
Usually okay: small patch skew, if no feature/bugfix you depend on changed
Risky: older macOS app with newer gateway/node-host, especially when testing newer node/browser behavior

Why:

The WS layer has protocol guards (minProtocol / maxProtocol), so true protocol breakage should fail clearly: https://docs.openclaw.ai/gateway/protocol
But even when protocol is still compatible, you can still hit behavior mismatches or miss a bugfix, which is what this thread looks like
The macOS docs also explicitly mention gateway/app version compatibility checks: https://docs.openclaw.ai/platforms/mac/bundled-gateway

So for your setup, I would not say “version skew is always forbidden”, but I would say:

#

if you want the fewest weird node/browser issues, keep the VPS gateway + Mac app + Mac node-host matched

In your exact case, updating the macOS app from 2026.4.11 → 2026.4.12 is the first thing I’d do.

slate swallow Apr 14, 2026, 2:56 PM

#

follow-up after updating both the VPS OpenClaw and the macOS app to v2026.4.14.

current node state

connected node: MaccyAir

client: openclaw-macos/node

device/hw: Mac / Mac17,4

status: paired + connected

browser retest on the macOS app node

browser status target=node node=MaccyAir profile=chrome-live

UNAVAILABLE: Could not connect to the server.

browser status target=node node=MaccyAir profile=openclaw

UNAVAILABLE: Could not connect to the server.

so matching both sides on 4.14 did not fix the browser issue.

non-browser probe on the same app node
these all succeeded:

canvas.present

canvas.snapshot (returned PNG successfully; showed REMOTE CONTROL / Connected)

canvas.hide

camera.list → returned 2 cameras (MacBook Air Camera, 零号机 Camera)

location.get → returned location successfully

current conclusion
this no longer looks like a broad macOS app node failure.
the node is healthy for general non-browser RPC, but browser functionality remains specifically broken on the macOS app node.

at this point the issue looks isolated to the app-node browser path / browser proxy handling, rather than:

version mismatch

general node connectivity

general canvas/camera/location capability failure

if useful, i can also provide the earlier comparison point where the CLI node-host path on the same Mac appeared to work, while the macOS app node path kept failing.

wary jayBOT Apr 14, 2026, 2:57 PM

#

Nice, that’s actually a really useful datapoint. Let me check the current app-side browser proxy path, because your retest now points to a browser-specific macOS app bug rather than a general node issue.

#

Yep, at this point I think your conclusion is solid.

This now looks like a browser-specific bug/limitation in the openclaw-macos/node path, not:

version skew
general node connectivity
general macOS app node breakage

And your earlier comparison point is already the key evidence:

same Mac
same browser profiles
same gateway
CLI node-host/node works
macOS app openclaw-macos/node fails only for browser
non-browser node RPC on the app works fine

#

I checked current source, and the app-node browser path still appears to go through a macOS-side browser.proxy handler that tries to hit a local browser-control HTTP endpoint on 127.0.0.1:(gateway.port + 2). In remote mode, the app also explicitly does not run a local gateway. That makes your exact error, Could not connect to the server., very believable for the app-node browser path specifically.

So my practical recommendation right now would be:

Treat this as an app-node browser bug
Use the CLI node-host on the Mac for browser automation as the workaround
If you want both, keep:
- macOS app node for canvas/camera/location/etc.
- CLI node-host for browser
File a GitHub issue with exactly the comparison you already wrote up, because honestly it’s a very clean repro:
https://github.com/openclaw/openclaw/issues

If you want to add one extra confirming datapoint before filing, this would be the best one:

while targeting the app node only, check whether anything is listening on the Mac’s local browser-control port, usually 127.0.0.1:18791 unless gateway.port was changed

But even without that, your report is already strong enough to file.

#

Glad you pushed it this far, this is much clearer now.
If this fixed your understanding/workaround, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

slate swallow Apr 14, 2026, 3:02 PM

#

confirmed gateway.port + 2 maps to browser control (18791 here). VPS-local 127.0.0.1:18791 is live and returns 401, but I still can’t directly verify the Mac app’s own localhost 127.0.0.1:18791 because node exec is unavailable on openclaw-macos/node and node-targeted browser requests still fail with UNAVAILABLE: Could not connect to the server.

wary jayBOT Apr 14, 2026, 3:02 PM

#

Yep, and that distinction matters a lot:

VPS 127.0.0.1:18791 returning 401 only proves the VPS browser control service is up
it tells us nothing about whether the Mac app’s own localhost 127.0.0.1:18791 is reachable

For the app-node browser hypothesis, the Mac-local listener is the one that matters.

So your result is still fully consistent with:

app node is healthy for normal node RPC
app node browser path is trying to reach a Mac-local browser service
that Mac-local browser service is missing/unreachable from the app path

If you want the cleanest next proof, run this directly on the Mac in Terminal, not through OpenClaw:

#

lsof -nP -iTCP:18791 -sTCP:LISTEN

and optionally:

curl -i http://127.0.0.1:18791/

Interpretation:

listener present + 401/404/etc → something is there, bug is deeper in app browser proxy/auth/path
no listener / connection refused → that strongly supports the current diagnosis

So I’d say:

#

your repro is already strong enough to file
Mac-local 18791 check is the best extra confirmation
workaround still stands: use CLI node-host for browser, macOS app node for the rest

If you post the lsof / curl result, I can help you turn it into a tight GitHub issue body.

slate swallow Apr 14, 2026, 3:04 PM

#

lsof returned nothing.
lsof -nP -iTCP:18791 -sTCP:LISTEN

curl -i http://127.0.0.1:18791/
curl: (7) Failed to connect to 127.0.0.1 port 18791 after 0 ms: Couldn't connect to server

wary jayBOT Apr 14, 2026, 3:04 PM

#

Perfect, that’s the smoking gun.

This confirms:

the macOS app node browser path is trying to use a Mac-local browser control listener
that listener is not running on the Mac (18791 closed)
so openclaw-macos/node browser requests fail with UNAVAILABLE: Could not connect to the server.
meanwhile the rest of the app node works because those RPCs do not depend on that listener

So at this point I’d treat it as a real bug in the app-node browser path.

Best current workaround

use CLI node-host/node for browser
use macOS app node for canvas/camera/location/etc.

I’d file this issue

#

https://github.com/openclaw/openclaw/issues

Suggested title:

macOS app node browser proxy fails in remote mode, while CLI node-host on the same Mac works

Suggested core evidence:

Gateway on VPS
macOS app node connected and healthy for canvas.*, camera.list, location.get
browser status target=node node=<app-node> profile=chrome-live|openclaw fails with UNAVAILABLE: Could not connect to the server.
same Mac + same browser profiles + same gateway
CLI node-host/node works for browser on the same machine
on the Mac, lsof -nP -iTCP:18791 -sTCP:LISTEN returns nothing
on the Mac, curl http://127.0.0.1:18791/ gets connection refused

Honestly, you’ve narrowed this down really well. I don’t think you need more local digging before filing.

#

If this helped, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it.

#macOS app node browser proxy fails, but CLI node-host on the same Mac works

Best current workaround

I’d file this issue