#Openclaw App Close Due to Mic

1 messages · Page 1 of 1 (latest)

burnt egretBOT
#

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

green pasture
#

How do I upload markdown or crashreport?

#

ased on your provided crash log, here are the three critical sections you should share:

  1. The Core Exception & Termination Reason
    This part tells the developer what kind of crash occurred and which system service was involved.

Exception Type: EXC_CRASH (SIGABRT)

Termination Reason: Namespace SIGNAL, Code 6, Abort trap: 6
+1

Triggered by Thread: 4

  1. The Faulting Method (The "Smoking Gun")
    This is the most important part. It shows that the crash happened during the VoiceWake initialization sequence.
    +4

Failed Method: VoiceWakeRuntime.start(with:)
+2

Underlying Error: AVAudioEngineImpl::InstallTapOnNode
+4

Krill needs to know this because it indicates the app crashed while trying to set up a "tap" for speech recognition, likely because the audio system was already in use or blocked.

  1. The Last Exception Backtrace
    Copy these specific lines from the "Last Exception Backtrace" section:
    +1

3 AVFAudio 0x234494468 AVAudioEngineImpl::InstallTapOnNode 4 AVFAudio 0x234471f24 -[AVAudioNode installTapOnBus:bufferSize:format:block:] 5 OpenClaw 0x10281910c VoiceWakeRuntime.start(with:)
+4

Context for your Mac Mini M4
When you message Krill, it would be helpful to mention that you are running this on a Mac Mini M4 (Mac16,10) with macOS 26.3.

Suggested message to Krill:

"Hi Krill, my OpenClaw app (v2026.2.9) is crashing on launch on my Mac Mini M4. The report shows a SIGABRT in VoiceWakeRuntime.start when calling AVAudioEngineImpl::InstallTapOnNode. I suspect it's an audio engine conflict. Are there any known issues with VoiceWake on the M4 chip?"

inland hazelBOT
#

This is a known macOS “TCC permissions got weird” failure mode — the macOS app can crash right when granting Microphone / Speech Recognition, and then it can get stuck in a crash-on-launch loop.

First, can you paste:

  • openclaw --version
  • your macOS version (e.g. 15.x)
  • how you installed the macOS app (release dmg vs built from source)

Quick fix (usually works)

  1. Quit OpenClaw (make sure it’s not still running as a menu bar app).
  2. Reset the permission grants for the macOS app bundle id (ai.openclaw.mac):
tccutil reset Microphone ai.openclaw.mac
tccutil reset SpeechRecognition ai.openclaw.mac
# or reset everything for the app:
#
tccutil reset All ai.openclaw.mac
  1. Go to System Settings → Privacy & Security → Microphone (and Speech Recognition) and remove/disable OpenClaw if it’s listed.
  2. Reboot (macOS sometimes won’t re-prompt cleanly until a restart).
  3. Launch OpenClaw again (ideally from /Applications, not from Downloads), and re-allow the prompts.

Docs reference (this exact symptom):
https://docs.openclaw.ai/platforms/mac/dev-setup#app-crashes-on-permission-grant
and background on why this happens: https://docs.openclaw.ai/platforms/mac/permissions

If it still “refuses to open”

Please attach/paste the crash report from:

~/Library/Logs/DiagnosticReports/OpenClaw_*.crash

#

(or grab it in Console.app → Crash Reports). The top exception + backtrace is usually enough to tell if it’s a signing/TCC mismatch vs an audio-device bug.

green pasture
#

Translated Report (Full Report Below)

Process: OpenClaw [1370]
Path: /Applications/OpenClaw.app/Contents/MacOS/OpenClaw
Identifier: bot.molt.mac
Version: 2026.2.9 (9194)
Code Type: ARM-64 (Native)
Role: Default
Parent Process: launchd [1]
Coalition: bot.molt.mac [965]
User ID: 501

Date/Time: 2026-02-13 08:05:15.4478 -0500
Launch Time: 2026-02-13 08:05:15.1197 -0500
Hardware Model: Mac16,10
OS Version: macOS 26.3 (25D125)
Release Type: User

Crash Reporter Key: C8A43703-C46F-991E-2617-167EC4380D45
Incident Identifier: 72D5460C-60E3-4C09-8E7D-9D772AE1945C

Time Awake Since Boot: 270 seconds

System Integrity Protection: enabled

Triggered by Thread: 4, Dispatch Queue: com.apple.root.user-initiated-qos.cooperative

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000

Termination Reason: Namespace SIGNAL, Code 6, Abort trap: 6
Terminating Process: OpenClaw [1370]

Application Specific Information:
abort() called

#

Last Exception Backtrace:
0 CoreFoundation 0x18fdc38f0 __exceptionPreprocess + 164
1 libobjc.A.dylib 0x18f89a418 objc_exception_throw + 88
2 CoreFoundation 0x18fe91564 -[NSException initWithCoder:] + 0
3 AVFAudio 0x234494468 AVAudioEngineImpl::InstallTapOnNode(AVAudioNode*, unsigned long, unsigned int, AVAudioFormat*, void (AVAudioPCMBuffer*, AVAudioTime*) block_pointer) + 1556
4 AVFAudio 0x234471f24 -[AVAudioNode installTapOnBus:bufferSize:format:block:] + 608
5 OpenClaw 0x10281910c VoiceWakeRuntime.start(with:) + 1244
6 OpenClaw 0x102818771 VoiceWakeRuntime.refresh(state:) + 1
7 OpenClaw 0x10248e53d closure #2 in AppState.init(preview:) + 1
8 OpenClaw 0x10249bda1 partial apply for closure #2 in AppState.init(preview:) + 1
9 OpenClaw 0x1022e6149 specialized thunk for @escaping @isolated(any) @callee_guaranteed @async () -> (@out A) + 1
10 OpenClaw 0x1022ed9c1 partial apply for specialized thunk for @escaping @isolated(any) @callee_guaranteed @async () -> (@out A) + 1
11 libswift_Concurrency.dylib 0x28f02831d completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*) + 1

green pasture
#

Thoughts?

inland hazelBOT
#

Yep — this specific “toggle mic → app quits → won’t reopen” on macOS is usually TCC (permissions) getting into a bad state (sometimes combined with an app identity/signature change), so the app crashes immediately on launch when it tries to touch the audio/speech APIs.

Try this first (release app bundle id is ai.openclaw.mac):

  1. Quit OpenClaw fully (menu bar icon gone).
  2. Reset mic + speech permissions:
tccutil reset Microphone ai.openclaw.mac
tccutil reset SpeechRecognition ai.openclaw.mac
# if needed:
tccutil reset All ai.openclaw.mac
  1. System Settings → Privacy & Security → Microphone + Speech Recognition:
  • remove/disable OpenClaw if it’s listed
  1. Reboot (macOS sometimes won’t re-prompt cleanly without this)
#
  1. Re-open OpenClaw (make sure it’s in /Applications and you’re always launching the same copy)

If you built from source/debug at any point, you might also have legacy bundle ids; tell me how you installed and I’ll give the exact IDs to reset.

If it still won’t open, paste:

  • macOS version
  • OpenClaw app version
  • openclaw --version
  • and the top part of the crash report from ~/Library/Logs/DiagnosticReports/OpenClaw_*.crash (or Console.app → Crash Reports)

Docs that mention this exact crash-on-mic/speech grant symptom: https://docs.openclaw.ai/platforms/mac/dev-setup#app-crashes-on-permission-grant

green pasture
#

getting this error - 2026-02-13T14:55:04.710-05:00 Gateway auth is set to token, but no token is configured.
Set gateway.auth.token (or OPENCLAW_GATEWAY_TOKEN), or pass --token.
Error: exit status 1

inland hazelBOT
#

That error means your config has gateway.auth.mode: "token" enabled, but gateway.auth.token is empty/missing — so the Gateway refuses to start.

Fix (on the Mac where the Gateway runs):

  1. Generate a token (only fills it in if missing):
openclaw doctor --generate-gateway-token
  1. Verify it exists:
openclaw config get gateway.auth.token
  1. Restart the Gateway:
#
openclaw gateway restart

If you prefer setting it manually:

openclaw config set gateway.auth.token "$(openssl rand -hex 32)"
openclaw gateway restart

Then use:

openclaw dashboard
green pasture
#

Does the openclaw app conflict with running it through brew or powershell? Should one be deleted or removed?

inland hazelBOT
#

No real conflict between the macOS app and “Homebrew” / “PowerShell” by themselves — the thing that causes problems is running multiple OpenClaw installs / multiple Gateways on the same machine (or having the app use a different openclaw binary/config than the one you’re testing in a terminal).

Key points:

  • OpenClaw.app (macOS) does not bundle the Gateway runtime. It expects an external openclaw CLI install and usually manages a launchd Gateway service. Docs: https://docs.openclaw.ai/platforms/mac/bundled-gateway
  • Homebrew is fine (often used just to install Node 22+, ffmpeg, etc.). You don’t need to delete Homebrew.
  • PowerShell is only relevant on Windows; it won’t conflict with your Mac app unless you’re connecting to the same remote gateway and mixing configs.

What is worth avoiding on the Mac mini:

  1. Two different openclaw binaries on PATH (e.g. one from npm, one from somewhere else)
    Check:
which -a openclaw
openclaw --version
#
  1. Starting a second Gateway manually while the app/launchd service is also trying to run one on the same port (default 18789).
    Check:
openclaw gateway status

(This also helps spot “service is using a different config path than my terminal” situations.)

So: you generally don’t need to delete anything. Just pick one way to run the Gateway on that machine (usually: let the macOS app / launchd manage it), and make sure the CLI the app uses is the same version you’re testing (openclaw --version should match the app version).

If you paste the output of which -a openclaw + openclaw gateway status, I can tell you if you’ve got a double-install / double-config situation.

green pasture
#

this is what came back -
tonylam@Tonys-Mac-mini media-server % openclaw gateway status

🦞 OpenClaw 2026.2.12 (f9e444d) — IPC, but it's your phone.

│
â—‡
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-02-13.log
Command: /opt/homebrew/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 6794, state active)
RPC probe: ok

Listening: 127.0.0.1:18789
Other gateway-like services detected (best effort):

  • ai.openclaw.mac (user, plist: /Users/tonylam/Library/LaunchAgents/ai.openclaw.mac.plist)
    Cleanup hint: launchctl bootout gui/$UID/ai.openclaw.gateway
    Cleanup hint: rm ~/Library/LaunchAgents/ai.openclaw.gateway.plist

Recommendation: run a single gateway per machine for most setups. One gateway supports multiple agents (see docs: /gateway#multiple-gateways-same-host).
If you need multiple gateways (e.g., a rescue bot on the same host), isolate ports + config/state (see docs: /gateway#multiple-gateways-same-host).

Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
Failed to discover Ollama models: TimeoutError: The operation was aborted due to timeout
Failed to discover Ollama models: TimeoutError: The operation was aborted due to timeout
tonylam@Tonys-Mac-mini media-server % which -a openclaw + openclaw gateway status
/opt/homebrew/bin/openclaw
/opt/homebrew/bin/openclaw

inland hazelBOT
#

That output is actually good news: it shows you only have one openclaw on PATH (/opt/homebrew/bin/openclaw), and the Gateway is healthy (RPC probe: ok, listening on 127.0.0.1:18789). So this is not a “brew vs app fighting” situation.

A couple important takeaways though:

1) You’re on OpenClaw 2026.2.12

Your status shows OpenClaw 2026.2.12. If your macOS app is a newer build (many folks are already on 2026.2.13), version skew can cause weirdness. I’d update the CLI to match the app version.

After updating, re-check:

openclaw --version
openclaw gateway restart

2) The “Gateway auth is set to token but no token is configured” error

That happens when your config has gateway.auth.mode: "token" but gateway.auth.token is empty.

Run:

#
openclaw config get gateway.auth.mode
openclaw config get gateway.auth.token

If mode is token and token is blank, fix with:

openclaw doctor --generate-gateway-token
openclaw gateway restart

3) Mic permission crash is almost certainly TCC, not Homebrew

The microphone is used by the macOS app (Voice Wake / PTT), not the Gateway. When macOS TCC gets corrupted or the app identity/path changed, you can get “grant mic → app quits → can’t reopen”.

Reset TCC for the release bundle id:

#
tccutil reset Microphone ai.openclaw.mac
tccutil reset SpeechRecognition ai.openclaw.mac
# if needed:
tccutil reset All ai.openclaw.mac

Then:

  • remove OpenClaw from Privacy & Security lists if present
  • reboot
  • make sure OpenClaw.app lives in /Applications (not Downloads / a second copy)

Docs for this exact symptom: https://docs.openclaw.ai/platforms/mac/dev-setup#app-crashes-on-permission-grant

About the “other gateway-like services detected: ai.openclaw.mac”

That’s the macOS app LaunchAgent, not a second Homebrew install. You don’t need to delete it.

#

If after the TCC reset it still crashes, paste the top of:
~/Library/Logs/DiagnosticReports/OpenClaw_*.crash
(“Exception Type” + first backtrace chunk is enough).

green pasture
#

is stable, beta or dev updates better?

inland hazelBOT
#

For most people: stable.

How the channels shake out:

  • stable (latest): most tested, lowest chance of new breakage. Best default if you just want it to work.
  • beta: gets fixes earlier (often the “next stable”), but you’re a bit more likely to hit a regression. Good if you’re blocked on a bug and want the newest patch without living on main.
  • dev: straight from main (git). Best only if you’re comfortable debugging/filing issues and occasionally having to roll back.

In your specific situation (macOS app oddities + you’re on 2026.2.12): I’d try beta first, because it’s the most likely to include a fix while still being reasonably tested. Also try to keep the macOS app version and CLI/Gateway version aligned.

Commands (if you want them):

openclaw update status
openclaw update --channel beta
openclaw gateway restart
green pasture
#

how would i run the same ai agent on both a windows pc and mac?

inland hazelBOT
#

If you want the same agent (same config, same memory/state, same conversations) available from both a Windows PC and a Mac, the clean mental model in OpenClaw is:

1 Gateway (“the brain”), multiple Nodes (“the hands/eyes”).

Option A (recommended): one shared Gateway, both computers connect to it

  • Run one OpenClaw Gateway on whichever machine is always on (Mac mini, home server, VPS, etc.).
  • From either your Windows PC or your Mac you can:
    • chat via the Control UI (dashboard) pointing at that same gateway, and/or
    • chat via the same channel (Discord/Telegram/etc.), which is handled by the gateway.

Then, if you want the agent to be able to run commands locally on each machine:

Add your Mac as a node

  • Use the macOS menubar app in node mode (or remote mode if the gateway is elsewhere), then approve it on the gateway.

Add your Windows PC as a node (headless node host)

  • Run a node host on Windows (this gives you system.run on that Windows machine) and approve it on the gateway.
#

Docs:

Switching which machine runs commands

Once both are paired as nodes, you can tell OpenClaw where exec/system.run should go:

  • Set a default node in config (tools.exec.node), or
  • switch per session with the /exec host=node node=<node-name-or-id> style override.

(That way you can run tasks on Windows sometimes, on Mac other times, while keeping one shared agent “brain”.)


Option B: run two separate Gateways (one on Windows, one on Mac)

This works, but they will be two separate bots unless you build your own syncing:

  • separate session state
  • separate memories/files unless you manually sync workspaces
#
  • more moving parts

This is mainly for “hard isolation” or totally different setups. Docs: https://docs.openclaw.ai/gateway/multiple-gateways


If you tell me which machine you want as the always-on “brain” (Mac mini, Windows PC, or VPS) and whether you need the agent to run local commands on both machines, I can suggest the simplest setup path.

green pasture
#

mac mini is the brain agent to run local commands on both machines

inland hazelBOT
#

If the Mac mini is the brain (Gateway) and you want the agent to be able to run commands on both the Mac mini and your Windows PC, you want:

  • Gateway on the Mac mini
  • Windows PC runs a “node host” (headless node) that exposes system.run to the gateway

1) Make the Mac mini Gateway reachable from Windows

By default the gateway often binds to loopback, so Windows can’t reach it directly. Easiest options:

2) Get the Gateway token

The Windows node host authenticates with the gateway token (gateway.auth.token).

On the Mac mini you can view it via the config CLI (or open the dashboard URL which includes a token).

#

Docs context: https://docs.openclaw.ai/nodes (see “Remote node host”)

3) Run the Windows node host

On Windows, install OpenClaw, then run a node host that points at the Mac mini gateway.

If using an SSH tunnel

First create the tunnel (keep it running):

ssh -N -L 18790:127.0.0.1:18789 <user>@<mac-mini-host>

Then in another terminal on Windows:

setx OPENCLAW_GATEWAY_TOKEN "<gateway-token>"
#
openclaw node run --host 127.0.0.1 --port 18790 --display-name "Windows PC"

If using Tailscale / direct network

Just point --host at the Mac mini’s tailnet/LAN address and use port 18789.

4) Approve the node on the Mac mini

On the Mac mini (gateway host):

openclaw nodes pending
openclaw nodes approve <requestId>
openclaw nodes status

5) Actually run commands on either machine

#
  • Mac mini commands: default exec runs on the gateway host (your Mac mini).
  • Windows commands: switch exec to the node host:

In a session, use the /exec override (or set defaults in config):

  • Per-session idea:
    • set exec to Windows node, run a task, then switch back.

Docs: https://docs.openclaw.ai/nodes (section “Point exec at the node”) + https://docs.openclaw.ai/tools/exec


If you paste:

  1. openclaw --version from both machines, and
  2. which connection you prefer (Tailscale vs SSH tunnel),
    I can give you the exact minimal command set for your setup.
green pasture
#

Translated Report (Full Report Below)

Process: OpenClaw [1806]
Path: /Applications/OpenClaw.app/Contents/MacOS/OpenClaw
Identifier: bot.molt.mac
Version: 2026.2.13 (9846)
Code Type: ARM-64 (Native)
Role: Default
Parent Process: launchd [1]
Coalition: bot.molt.mac [867]
User ID: 501

Date/Time: 2026-02-14 12:48:04.8079 -0500
Launch Time: 2026-02-14 12:48:04.5885 -0500
Hardware Model: Mac16,10
OS Version: macOS 26.3 (25D125)
Release Type: User

Crash Reporter Key: C8A43703-C46F-991E-2617-167EC4380D45
Incident Identifier: D304EA94-C213-4406-A622-A74D7DA2B80F

Time Awake Since Boot: 540 seconds

System Integrity Protection: enabled

Triggered by Thread: 1, Dispatch Queue: com.apple.root.user-initiated-qos.cooperative

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000

Termination Reason: Namespace SIGNAL, Code 6, Abort trap: 6
Terminating Process: OpenClaw [1806]

Application Specific Information:
abort() called

inland hazelBOT
#

That crash (SIGABRT / abort() called) right when you grant Microphone is often a macOS TCC permission cache problem (or two app installs/signatures confusing macOS).

Try this sequence on the Mac mini (bundle id in your report is bot.molt.mac):

1) Fully quit OpenClaw, then reset just the relevant permissions

In Terminal:

tccutil reset Microphone bot.molt.mac
tccutil reset SpeechRecognition bot.molt.mac

Then launch OpenClaw again and re-grant the prompts.

2) If that didn’t work, reset all permissions for OpenClaw

(This will make macOS re-prompt for everything: notifications, screen recording, etc.)

#
tccutil reset All bot.molt.mac

Then reboot (or at least log out/in) and try again.

3) Sanity checks that also matter

  • Make sure there is only one OpenClaw.app on the machine (e.g. not one in /Applications and another in ~/Downloads).
  • After resetting, check System Settings → Privacy & Security → Microphone and ensure OpenClaw is allowed (after it re-appears).

4) If it still crashes: I’ll need the “Last Exception Backtrace”

The snippet you pasted is the header; the useful part is further down in the crash report:

  • “Last Exception Backtrace” section
  • the top of Thread 1 stack

If you paste those parts (or attach the full .crash file from ~/Library/Logs/DiagnosticReports/), it’ll be clear what code path is aborting.

green pasture
#

I cant attach the full file

inland hazelBOT
#

No problem — you don’t need to attach the whole crash file. If you can paste just these sections, it’s usually enough to pinpoint the abort:

  • Last Exception Backtrace
  • the first ~30–60 lines of Thread 1 (or whichever thread is marked “Triggered by Thread”)
  • any lines mentioning TCC, Microphone, Speech, AVAudioSession, NSSpeechRecognizer, etc.

Here are two easy ways to extract that on the Mac mini:

Option 1: Terminal (recommended)

  1. Get the newest crash report path:
ls -t ~/Library/Logs/DiagnosticReports/OpenClaw_*.crash | head -1
  1. Print just the important chunks (copy/paste output back here):
#
CRASH="$(ls -t ~/Library/Logs/DiagnosticReports/OpenClaw_*.crash | head -1)"
echo "CRASH: $CRASH"
sed -n '/Last Exception Backtrace/,+80p' "$CRASH"
echo "-----"
sed -n '/Thread 1/,+120p' "$CRASH"

If “Thread 1” doesn’t exist in the text, replace Thread 1 with Thread 0 or whatever thread is present.

Option 2: Open in Console/TextEdit and copy sections

  • Finder → Go menu → Go to Folder…
  • Paste: ~/Library/Logs/DiagnosticReports/
  • Open the latest OpenClaw_....crash and copy the sections above.

Quick question

Did running these fix attempts change anything?

#
tccutil reset Microphone bot.molt.mac
tccutil reset SpeechRecognition bot.molt.mac

If you paste those crash snippets + confirm whether the TCC reset helped, we can tell if it’s (a) a macOS TCC cache issue, (b) a permissions prompt edge-case on macOS 26.3, or (c) a specific OpenClaw app bug worth a GitHub issue.

#

You pasted the commands (perfect) — now we need the output they produce.

On the Mac mini, run this exactly, then copy/paste everything it prints back into the thread:

CRASH="$(ls -t ~/Library/Logs/DiagnosticReports/OpenClaw_*.crash | head -1)"
echo "CRASH: $CRASH"
sed -n '/Last Exception Backtrace/,+80p' "$CRASH"
echo "-----"
sed -n '/Thread 1/,+120p' "$CRASH"

If it says “No such file” or doesn’t print a “Last Exception Backtrace”, run these two and paste output:

ls -t ~/Library/Logs/DiagnosticReports/ | head
#
open -R "$(ls -t ~/Library/Logs/DiagnosticReports/OpenClaw_*.crash | head -1)"

(That second one reveals the crash file in Finder so you can open it and copy the sections manually.)

Also: did tccutil reset Microphone bot.molt.mac change anything, or does it still crash immediately on the permission prompt?

green pasture
#

Translated Report (Full Report Below)

Process: OpenClaw [773]
Path: /Applications/OpenClaw.app/Contents/MacOS/OpenClaw
Identifier: bot.molt.mac
Version: 2026.2.13 (9846)
Code Type: ARM-64 (Native)
Role: Default
Parent Process: launchd [1]
Coalition: bot.molt.mac [950]
User ID: 501

Date/Time: 2026-02-14 13:03:15.7080 -0500
Launch Time: 2026-02-14 13:03:15.2890 -0500
Hardware Model: Mac16,10
OS Version: macOS 26.3 (25D125)
Release Type: User

Crash Reporter Key: C8A43703-C46F-991E-2617-167EC4380D45
Incident Identifier: 671BDA5F-5376-4E2C-98FD-F249E4C658BD

Time Awake Since Boot: 22 seconds

System Integrity Protection: enabled

Triggered by Thread: 3, Dispatch Queue: com.apple.root.user-initiated-qos.cooperative

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000

Termination Reason: Namespace SIGNAL, Code 6, Abort trap: 6
Terminating Process: OpenClaw [773]

Application Specific Information:
abort() called

#

ast Exception Backtrace:
0 CoreFoundation 0x18f8eb8f0 __exceptionPreprocess + 164
1 libobjc.A.dylib 0x18f3c2418 objc_exception_throw + 88
2 CoreFoundation 0x18f9b9564 -[NSException initWithCoder:] + 0
3 AVFAudio 0x233fbc468 AVAudioEngineImpl::InstallTapOnNode(AVAudioNode*, unsigned long, unsigned int, AVAudioFormat*, void (AVAudioPCMBuffer*, AVAudioTime*) block_pointer) + 1556
4 AVFAudio 0x233f99f24 -[AVAudioNode installTapOnBus:bufferSize:format:block:] + 608
5 OpenClaw 0x1005c0664 VoiceWakeRuntime.start(with:) + 1244
6 OpenClaw 0x1005bfcc9 VoiceWakeRuntime.refresh(state:) + 1
7 OpenClaw 0x100234195 closure #2 in AppState.init(preview:) + 1
8 OpenClaw 0x10023efb1 partial apply for closure #2 in AppState.init(preview:) + 1
9 OpenClaw 0x10008a149 specialized thunk for @escaping @isolated(any) @callee_guaranteed @async () -> (@out A) + 1
10 OpenClaw 0x1000919c1 partial apply for specialized thunk for @escaping @isolated(any) @callee_guaranteed @async () -> (@out A) + 1
11 libswift_Concurrency.dylib 0x28eb5031d completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*) + 1

#

Thread 0:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x18f7bcc34 mach_msg2_trap + 8
1 libsystem_kernel.dylib 0x18f7cf028 mach_msg2_internal + 76
2 libsystem_kernel.dylib 0x18f7c598c mach_msg_overwrite + 484
3 libsystem_kernel.dylib 0x18f7bcfb4 mach_msg + 24
4 CoreFoundation 0x18f89ebb0 __CFRunLoopServiceMachPort + 160
5 CoreFoundation 0x18f89d508 __CFRunLoopRun + 1188
6 CoreFoundation 0x18f957f3c _CFRunLoopRunSpecificWithOptions + 532
7 HIToolbox 0x19c3d9790 RunCurrentEventLoopInMode + 316
8 HIToolbox 0x19c3dcab8 ReceiveNextEventCommon + 488
9 HIToolbox 0x19c566b64 _BlockUntilNextEventMatchingListInMode + 48
10 AppKit 0x1941b9014 _DPSBlockUntilNextEventMatchingListInMode + 236
11 AppKit 0x193cb6e48 DPSNextEvent + 588
12 AppKit 0x19477de8c -[NSApplication(NSEventRouting) nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688
13 AppKit 0x19477db98 -[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:] + 72
14 AppKit 0x193caf780 -[NSApplication run] + 368
15 AppKit 0x193c9b6dc NSApplicationMain + 880
16 SwiftUI 0x1c3ae33ec specialized runApp(
:) + 168
17 SwiftUI 0x1c3e9cc88 runApp<A>(
:) + 112
18 SwiftUI 0x1c4167320 static App.main() + 224
19 OpenClaw 0x100423b2c OpenClaw_main + 64
20 dyld 0x18f435d54 start + 7184

inland hazelBOT
#

That’s still only the crash report header — the useful part is further down where it shows the crashing stack.

Since your header says “Triggered by Thread: 3”, please paste the output of this (it prints the “Thread 3 Crashed” section):

CRASH="$(ls -t ~/Library/Logs/DiagnosticReports/OpenClaw_*.crash | head -1)"
echo "CRASH: $CRASH"
sed -n '/Thread 3 Crashed/,+180p' "$CRASH"
echo "-----"
sed -n '/Binary Images/,+40p' "$CRASH"

If that prints nothing (wording can vary), run this and paste the output so we can see what the crash file calls the section:

CRASH="$(ls -t ~/Library/Logs/DiagnosticReports/OpenClaw_*.crash | head -1)"
#
grep -n "Thread 3" "$CRASH" | head -20

To get you unstuck (if the app now crashes on launch)

If enabling microphone “bricked” the app and it now won’t open, do these two quick resets:

  1. Reset mic/speech TCC (then reboot):
tccutil reset Microphone bot.molt.mac
tccutil reset SpeechRecognition bot.molt.mac
  1. Reset the app’s saved preferences (this often clears the “mic enabled” toggle that’s causing the crash loop):
defaults delete bot.molt.mac
#

Then launch OpenClaw again.

Once you paste the Thread 3 Crashed block, we can tell whether this is:

  • a macOS 26.3 TCC edge case,
  • a specific OpenClaw assertion firing on mic init,
  • or something like an audio device/permission API returning an unexpected state.
green pasture
#

Thread 1:: Dispatch queue: app exceptions timeout queue
0 libobjc.A.dylib 0x18f3e72e8 bool objc::DenseMapBase<objc::DenseMap<DisguisedPtr<objc_object const>, unsigned long, (anonymous namespace)::RefcountMapValuePurgeable, objc::DenseMapInfo<DisguisedPtr<objc_object const>>, objc::detail::DenseMapPair<DisguisedPtr<objc_object const>, unsigned long>>, DisguisedPtr<objc_object const>, unsigned long, (anonymous namespace)::RefcountMapValuePurgeable, objc::DenseMapInfo<DisguisedPtr<objc_object const>>, objc::detail::DenseMapPair<DisguisedPtr<objc_object const>, unsigned long>>::LookupBucketFor<DisguisedPtr<objc_object const>>(DisguisedPtr<objc_object const> const&, objc::detail::DenseMapPair<DisguisedPtr<objc_object const>, unsigned long>&) + 20
1 libobjc.A.dylib 0x18f3e7288 objc::DenseMapBase<objc::DenseMap<DisguisedPtr<objc_object const>, unsigned long, (anonymous namespace)::RefcountMapValuePurgeable, objc::DenseMapInfo<DisguisedPtr<objc_object const>>, objc::detail::DenseMapPair<DisguisedPtr<objc_object const>, unsigned long>>, DisguisedPtr<objc_object const>, unsigned long, (anonymous namespace)::RefcountMapValuePurgeable, objc::DenseMapInfo<DisguisedPtr<objc_object const>>, objc::detail::DenseMapPair<DisguisedPtr<objc_object const>, unsigned long>>::find(DisguisedPtr<objc_object const> const&) + 36
2 libobjc.A.dylib 0x18f3b355c objc_object::sidetable_clearDeallocating() + 96
3 libobjc.A.dylib 0x18f3e26e8 objc_destructInstance_nonnull_realized(objc_object
) + 152
4 libobjc.A.dylib 0x18f3b33d0 objc_destructInstance + 44

#

Thread 3 Crashed:: Dispatch queue: com.apple.root.user-initiated-qos.cooperative
0 libsystem_kernel.dylib 0x18f7c55b0 __pthread_kill + 8
1 libsystem_pthread.dylib 0x18f7ff888 pthread_kill + 296
2 libsystem_c.dylib 0x18f704850 abort + 124
3 libc++abi.dylib 0x18f7b3858 __abort_message + 132
4 libc++abi.dylib 0x18f7a24d4 demangling_terminate_handler() + 304
5 libobjc.A.dylib 0x18f3cc414 _objc_terminate() + 156
6 libc++abi.dylib 0x18f7b2c2c std::__terminate(void ()()) + 16
7 libc++abi.dylib 0x18f7b6394 __cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception
) + 88
8 libc++abi.dylib 0x18f7b633c __cxa_throw + 92
9 libobjc.A.dylib 0x18f3c2580 objc_exception_throw + 448
10 CoreFoundation 0x18f9b9564 +[NSException raise:format:] + 128
11 AVFAudio 0x233fbc468 AVAudioEngineImpl::InstallTapOnNode(AVAudioNode*, unsigned long, unsigned int, AVAudioFormat*, void (AVAudioPCMBuffer*, AVAudioTime*) block_pointer) + 1556
12 AVFAudio 0x233f99f24 -[AVAudioNode installTapOnBus:bufferSize:format:block:] + 608
16 OpenClaw 0x10023efb1 partial apply for closure #2 in AppState.init(preview:) + 1
17 OpenClaw 0x10008a149 specialized thunk for @escaping @isolated(any) @callee_guaranteed @async () -> (@out A) + 1
18 OpenClaw 0x1000919c1 partial apply for specialized thunk for @escaping @isolated(any) @callee_guaranteed @async () -> (@out A) + 1
19 libswift_Concurrency.dylib 0x28eb5031d completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*) + 1

inland hazelBOT
#

That backtrace is the smoking gun: the crash is happening inside VoiceWakeRuntime when it tries to start audio capture and calls:

AVAudioNode.installTapOnBus(...) → AVAudioEngineImpl::InstallTapOnNode(...)

On macOS, that call throws an Obj‑C exception if the audio node/bus/format is in a bad state (Swift can’t catch it → the app aborts).

Most common triggers

  1. Bad/unsupported mic format (sample rate / channel count mismatch), often with USB interfaces / Bluetooth headsets.
  2. Previously selected mic device is gone (app tries to tap a device that disconnected).
  3. CoreAudio is wedged right after permission grant.

Fastest workaround (get the app opening again)

  1. Revoke Mic permission temporarily so Voice Wake won’t start on launch:
  • System Settings → Privacy & Security → Microphone → toggle OpenClaw off
  • Launch OpenClaw (it should stop crashing)
  1. In OpenClaw settings, turn off “Voice Wake” (and anything “push-to-talk” / talk mode if enabled), and set mic to Built‑in Microphone if there’s a picker.
#
  1. Re-enable Mic permission in System Settings and try again.

Fix the underlying audio state

Do these in order:

  1. In System Settings → Sound → Input
  • Select Built‑in Microphone
  • Make sure input level moves when you talk
  1. If you use any of these, unplug them and retry:
  • USB audio interface / mic
  • Bluetooth headset (AirPods, etc.)
  • “Aggregate Device” / “Multi-Output Device” (Audio MIDI Setup)
  1. Restart CoreAudio (safe, it auto-restarts):
#
sudo killall coreaudiod

If you can paste one more line, we can file a solid bug

In the .crash file there’s usually a line like:

Terminating app due to uncaught exception '…', reason: '…'

If you can extract/paste just that “reason” line, it’ll tell us exactly what installTap is unhappy about (wrong bus, invalid format, tap already installed, etc.).

Likely a real bug

Since this is OpenClaw 2026.2.13 on macOS 26.3, and it’s crashing in VoiceWakeRuntime.start(with:), this is very plausibly an app bug. If the workaround above doesn’t stick, the next step is a GitHub issue with:

  • that backtrace you pasted
  • the “uncaught exception reason” line (if available)
  • what mic hardware is connected
#

That’s enough to diagnose the class of crash.

Your Thread 3 shows an uncaught Obj‑C exception coming from:

AVFAudio -> AVAudioNode installTapOnBus(...)

and it’s being triggered by OpenClaw’s VoiceWakeRuntime.start(with:) (voice wake / push-to-talk pipeline). When AVFAudio throws, Swift can’t catch it → the app hits abort() and dies.

Get the app usable again (quick recovery)

Do this on the Mac mini:

  1. Turn Mic permission off so the app stops trying to start Voice Wake on launch
    System Settings → Privacy & Security → Microphone → toggle OpenClaw OFF
    Then launch OpenClaw (should stop crash-looping).

  2. Inside OpenClaw, disable Voice Wake / talk features (anything that listens constantly / PTT).

#
  1. Set macOS input device to something sane:
    System Settings → Sound → Input → choose Built-in Microphone (for now).

  2. Optional but often fixes “tap install” weirdness:

sudo killall coreaudiod

Then you can re-enable mic permission and try again.

If OpenClaw still won’t open: reset its saved settings

This often clears the “voice wake enabled” toggle that’s causing the crash:

defaults delete bot.molt.mac
#

(If you want a backup first: defaults export bot.molt.mac - > ~/Desktop/openclaw-prefs.plist)

One missing piece: the exception reason

To know the exact root cause (e.g. “tap already installed”, “bus out of range”, “format not supported”), please paste the single “uncaught exception … reason …” line from the crash.

Run:

CRASH="$(ls -t ~/Library/Logs/DiagnosticReports/OpenClaw_*.crash | head -1)"
grep -n "uncaught exception" "$CRASH" -n | head -5
sed -n '/uncaught exception/,+3p' "$CRASH"

Also: what mic hardware is connected?

When it crashes, are you using:

  • Built-in mic only, or
  • AirPods/Bluetooth headset, or
#
  • a USB mic / audio interface / aggregate device?

That combo + the exception reason line is enough to confirm whether this is a device/format edge case or a straight app bug we should send to GitHub.

green pasture
#

I am running this on a mac mini m4 which doesn't have a microphone it seems.

inland hazelBOT
#

Yep — Mac mini has no built‑in microphone. If OpenClaw’s Voice Wake / push‑to‑talk path turns on and it tries to start an audio tap with no valid input device, AVFAudio can throw an Obj‑C exception… and the app currently aborts (matches your stack trace in VoiceWakeRuntime.start(with:)).

What to do

If you don’t need voice features on the Mac mini (common for a “brain” box):

  1. System Settings → Privacy & Security → Microphone → toggle OpenClaw OFF
  2. Open OpenClaw → disable Voice Wake / talk / push‑to‑talk (anything that listens)
  3. You can still use the agent normally via Discord/Control UI/etc.

If you do want voice on the Mac mini:

  • Plug in / pair an actual mic input:
    • USB mic, USB audio interface, wired headset (via interface), AirPods/Bluetooth headset, etc.
  • Then go to System Settings → Sound → Input and select that device as the input.

If the app is stuck crash-looping

Reset the app’s saved settings so it stops trying to start Voice Wake on launch:

#
defaults delete bot.molt.mac

(Then reopen the app.)

This is still a bug

OpenClaw shouldn’t crash just because there’s no mic device; it should fall back gracefully. If you’re up for it, filing a GitHub issue with your backtrace + “Mac mini (no mic device)” would help get it fixed:
https://github.com/openclaw/openclaw/issues

Do you want voice wake on the Mac mini specifically, or are you happy doing voice on another device (e.g. a laptop/iPhone) while the Mac mini stays the gateway “brain”?

green pasture
#

Let's report the bug

inland hazelBOT
#

Good call. Since I can’t file it for you, here’s a ready-to-post GitHub issue you can copy/paste.

Open an issue here: https://github.com/openclaw/openclaw/issues/new

Suggested title

macOS app crashes (SIGABRT) when enabling Microphone / Voice Wake on Mac mini (no input mic) — AVAudioNode installTapOnBus throws

Issue body (copy/paste)

Describe the bug
OpenClaw macOS app crashes immediately (SIGABRT / abort() called) after enabling Microphone (and/or Voice Wake). This happens on a Mac mini M4 which has no built-in microphone, so there may be no valid audio input device.

Expected behavior
App should not crash. If no mic input device is available, Voice Wake should disable itself or show an error and continue running.

Actual behavior
App aborts with an uncaught Objective‑C exception originating in AVFAudio when installing an audio tap.

#

Environment

  • App: OpenClaw 2026.2.13 (9846)
  • Bundle id: bot.molt.mac
  • macOS: 26.3 (25D125)
  • Hardware: Mac mini M4 (Mac16,10)
  • Mic hardware: none available (Mac mini has no built-in mic)

Repro steps

  1. Install/Open OpenClaw.app on Mac mini.
  2. Enable Microphone permission (or toggle Voice Wake / talk features).
  3. App crashes immediately on startup / when starting VoiceWakeRuntime.

Crash snippet (Last Exception Backtrace)

Last Exception Backtrace:
0   CoreFoundation  __exceptionPreprocess
#
1   libobjc.A.dylib objc_exception_throw
3   AVFAudio        AVAudioEngineImpl::InstallTapOnNode(...)
4   AVFAudio        -[AVAudioNode installTapOnBus:bufferSize:format:block:]
5   OpenClaw        VoiceWakeRuntime.start(with:)
6   OpenClaw        VoiceWakeRuntime.refresh(state:)

Thread that crashed

Thread 3 Crashed:
...
9   libobjc.A.dylib objc_exception_throw
10  CoreFoundation  +[NSException raise:format:]
11  AVFAudio        AVAudioEngineImpl::InstallTapOnNode(...)
12  AVFAudio        -[AVAudioNode installTapOnBus:bufferSize:format:block:]
#
... OpenClaw ... VoiceWakeRuntime ...

Workaround

  • Disable Microphone permission for OpenClaw, and/or disable Voice Wake / voice features.
  • (If stuck in crash loop) defaults delete bot.molt.mac

Additional info
If you want, I can paste the full “uncaught exception reason” line from the crash report too (tell me what to grep for).


If you want, paste the GitHub issue link after you file it and I’ll sanity-check it / suggest any extra details to add (like the exact “reason” line from the exception, which often names the precise audio/tap failure).

green pasture
inland hazelBOT
#

Nice — that’s the right place.

Two quick suggestions to make issue #16418 maximally actionable for the maintainer who picks it up:

  1. Add the “uncaught exception … reason …” line from the crash report (that line usually tells exactly why installTapOnBus failed). You can grab it with:
CRASH="$(ls -t ~/Library/Logs/DiagnosticReports/OpenClaw_*.crash | head -1)"
sed -n '/Terminating app due to uncaught exception/,+2p' "$CRASH"
# or, if wording differs:
grep -n "uncaught exception" "$CRASH" | head -20
  1. Confirm whether Voice Wake was enabled (or if simply granting Microphone permission triggers VoiceWakeRuntime to start automatically). That helps them decide whether to:
  • guard VoiceWake startup behind “mic device present”, or
  • catch/avoid the AVFAudio exception path.
#

If you paste the exception “reason” line here, I can tell you which of those is more likely and what fix they’ll probably implement.

green pasture
#

Openclaw app general settings states openclaw cli not found in path;install the cli

inland hazelBOT
#

That warning just means the macOS app can’t find an openclaw binary on your system PATH (so Terminal commands like openclaw status won’t work yet).

Easiest (from the macOS app)

In the OpenClaw app, go to the CLI section (in onboarding or Settings) and click Install CLI. It’ll typically drop a usable openclaw into a standard PATH location (may ask for admin permission).

If you want to do it manually (Terminal)

Docs: https://docs.openclaw.ai/install

Recommended install:

curl -fsSL https://openclaw.ai/install.sh | bash

Or via pnpm:

pnpm add -g openclaw@latest
#
pnpm approve-builds -g

Then verify:

openclaw --version
which openclaw

If it’s installed but still “not found in PATH”

Run:

npm prefix -g
echo "$PATH"
#

If the global bin dir isn’t in your PATH, add this to ~/.zshrc:

export PATH="$(npm prefix -g)/bin:$PATH"

Open a new terminal and re-check openclaw --version.

If you tell me what npm prefix -g prints on your Mac mini, I can tell you the exact PATH line you need.

green pasture
#

What is the gateway token? setx OPENCLAW_GATEWAY_TOKEN "<gateway-token>"

#

tonylam@Tonys-Mac-mini ~ % openclaw node run --host 127.0.0.1 --port 18790 --display-name "Windows PC"

🦞 OpenClaw 2026.2.13 (203b5bd) — Works on Android. Crazy concept, we know.

node host PATH: /opt/homebrew/bin:/usr/local/bin:/Users/tonylam/Library/pnpm:/Users/tonylam/.local/bin:/usr/bin:/bin:/System/Cryptexes/App/usr/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/opt/pmk/env/global/bin
node host gateway connect failed: connect ECONNREFUSED 127.0.0.1:18790

inland hazelBOT
#

connect ECONNREFUSED 127.0.0.1:18790 just means: nothing is listening on port 18790 on the machine where you ran the command.

In your case you ran this on the Mac mini, so unless you have an SSH tunnel or something else forwarding to 18790, that port will be closed → refused.

What you probably meant (Windows as the node)

You want openclaw node run ... "Windows PC" to run on the Windows machine, and connect back to the Mac mini Gateway.

Option A (easiest): SSH tunnel from Windows → Mac mini

On Windows (PowerShell or WSL), start a tunnel (keep it running):

ssh -N -L 18790:127.0.0.1:18789 tonylam@<mac-mini-ip-or-hostname>

Then in a second terminal on Windows:

PowerShell:

#
$env:OPENCLAW_GATEWAY_TOKEN="...your gateway token..."
openclaw node run --host 127.0.0.1 --port 18790 --display-name "Windows PC"

Now 127.0.0.1:18790 is the Windows end of the tunnel, so it works.

Option B: direct connect (no tunnel)

Only works if your Gateway is reachable from Windows over the network (not loopback-only). Then you’d run on Windows:

openclaw node run --host <mac-mini-ip> --port 18789 --display-name "Windows PC"

Approve the Windows node on the Mac mini (Gateway)

On the Mac mini, approve the pairing request:

#
openclaw devices list
openclaw devices approve <requestId>
openclaw nodes status

Quick question

Are you currently trying to run the node host on Windows native, or WSL2? (WSL2 is usually the smoothest path.)

green pasture
#

PowerShell 7.5.4
PS C:\Users\Tony> openclaw node run --host 127.0.0.1 --port 18790 --display-name "Windows PC"

🦞 OpenClaw 2026.2.13 (203b5bd) — I'll butter your workflow like a lobster roll: messy, delicious, effective.

node host PATH: C:\Program Files\PowerShell\7;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\System32\OpenSSH;C:\Windows\AtlasModules;C:\Windows\AtlasModules\Tools;C:\Windows\AtlasModules\Scripts;C:\Program Files\NVIDIA Corporation\NVIDIA App\NvDLISR;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\nodejs;C:\Program Files\Git\cmd;C:\Program Files\PowerShell\7;C:\Program Files\PowerShell\7-preview\preview;C:\Users\Tony\AppData\Roaming\npm;C:\Program Files\Go\bin;C:\tools\gog;C:\Program Files\GitHub CLI;C:\Users\Tony\AppData\Local\Programs\Ollama;C:\Program Files\Tailscale;C:\Users\Tony\AppData\Local\Programs\Python\Python314\Scripts;C:\Users\Tony\AppData\Local\Programs\Python\Python314;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\System32\OpenSSH;C:\Windows\AtlasModules;C:\Windows\AtlasModules\Tools;C:\Windows\AtlasModules\Scripts;C:\Program Files\NVIDIA Corporation\NVIDIA App\NvDLISR;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\nodejs;C:\Program Files\Git\cmd;C:\Program Files\PowerShell\7;C:\Program Files\PowerShell\7-preview\preview;C:\Users\Tony\AppData\Roaming\npm;C:\Program Files\Go\bin;C:\tools\gog;C:\Program Files\GitHub CLI;C:\Users\Tony\AppData\Local\Programs\Ollama;C:\Program Files\Tailscale;C:\Program Files\GitHub CLI;C:\Users\Tony\AppData\Local\Programs\Ollama;;C:\Users\Tony\AppData\Local\Programs\Ollama
node host gateway connect failed: connect ECONNREFUSED 127.0.0.1:18790
node host gateway closed (1006):

inland hazelBOT
#

127.0.0.1:18790 is your Windows machine, and right now there’s nothing listening there — that’s why you get ECONNREFUSED.

You need an SSH tunnel from Windows → Mac mini (Gateway), then point the Windows node host at the tunnel.

1) On the Mac mini: confirm Gateway is running (port 18789)

openclaw gateway status

Also get your Gateway token (you’ll need it on Windows):

openclaw config get gateway.auth.token

Make sure Remote Login (SSH) is enabled on the Mac mini:
System Settings → General → Sharing → Remote Login → ON

#

2) On Windows: start the tunnel (keep this window open)

Replace <mac-mini-host> with your Mac’s LAN IP / hostname / Tailscale name:

ssh -N -L 18790:127.0.0.1:18789 tonylam@<mac-mini-host>

Quick check (in a second PowerShell window) that the tunnel is up:

Test-NetConnection 127.0.0.1 -Port 18790

3) On Windows: run the node host (new PowerShell window)

Set the token you grabbed from the Mac mini:

#
$env:OPENCLAW_GATEWAY_TOKEN="PASTE_TOKEN_HERE"
openclaw node run --host 127.0.0.1 --port 18790 --display-name "Windows PC"

4) Back on the Mac mini: approve the node pairing

openclaw devices list
openclaw devices approve <requestId>
openclaw nodes status

If you tell me what you’re using as <mac-mini-host> (LAN IP, .local hostname, or Tailscale name) I can give you the exact SSH command line for your setup.

green pasture
#

where should the tailscale link get pointed to since i'm running nginx

inland hazelBOT
#

For the Windows node host, the “Tailscale link” should point at the Gateway WebSocket endpoint (same place the Control UI connects). Whether nginx is involved depends on which Tailscale mode you pick:

Recommended (ignore nginx): Tailscale Serve

This keeps OpenClaw bound to 127.0.0.1:18789 and Tailscale provides the HTTPS/WSS front door.

On the Mac mini (Gateway host):

openclaw gateway --tailscale serve

Then on Windows (node host), point it at your Mac’s MagicDNS name on 443:

$env:OPENCLAW_GATEWAY_TOKEN="...token from: openclaw config get gateway.auth.token ..."
openclaw node run --host <mac-mini-magicdns> --port 443 --tls --display-name "Windows PC"
  • <mac-mini-magicdns> looks like tonys-mac-mini.tailnet-xxxx.ts.net (or whatever Tailscale shows).
#
  • nginx does not need to be in the path for this.

Docs: https://docs.openclaw.ai/gateway/tailscale (Serve mode)

Simple (no HTTPS, no nginx): bind Gateway to the tailnet IP

If you don’t want Serve/Funnel at all:

Configure/run the Gateway on the Mac mini with bind: "tailnet" (or CLI equivalent), then Windows connects to:

  • host = Mac’s Tailscale IP (or tailnet DNS)
  • port = 18789
    (no --tls)

Docs: https://docs.openclaw.ai/gateway/tailscale#tailnet-only-bind-to-tailnet-ip

If you want nginx in front

Then nginx must reverse-proxy WebSockets to http://127.0.0.1:18789 (Upgrade/Connection headers + long timeouts). OpenClaw docs have a working nginx snippet here:
https://docs.openclaw.ai/install/exe-dev (section “Setup nginx to proxy OpenClaw…”)

#

Then Windows would point at nginx’s tailnet hostname and 443 with --tls.


If you tell me which one you prefer (Serve vs tailnet bind vs nginx proxy) and what your Mac mini’s Tailscale name/IP is, I’ll give you the exact commands for your case.

green pasture
#

is
"allowedOrigins": [
can be used in openclaw .json?

inland hazelBOT
#

Yes — but it’s not a top-level config key. In OpenClaw it lives at:

gateway.controlUi.allowedOrigins

And the config file is JSON5 (default path: ~/.openclaw/openclaw.json), so an array like ["https://…"] is totally fine.

Example:

{
  gateway: {
    controlUi: {
      // full origins only (scheme + host + optional port)
      allowedOrigins: ["http://localhost:5173"],
    },
  },
#
}

This is specifically for allowing Control UI / WebChat websocket connections from a different browser origin (otherwise you’ll see “origin not allowed”).

Docs: https://docs.openclaw.ai/web/control-ui

If you’re asking because the macOS app crashes when enabling mic: can you also paste openclaw --version and what macOS version you’re on?

green pasture
#

Let's fix the json

I added this

  "talk": {
    "voiceId": "elevenlabs_voice_id",
    "modelId": "eleven_v3",
    "outputFormat": "mp3_44100_128",
    "apiKey": "agent_key",
    "interruptOnSpeech": true
  }

however giving me error - agents.defaults: Unrecognized key: "talk"

inland hazelBOT
#

talk isn’t an agents.defaults setting — it’s a top-level config section.

So instead of:

{
agents: {
defaults: {
talk: { ... } // ❌ not valid here
}
}
}

do:

#
{
agents: {
defaults: {
// your agent defaults here (model, tools, etc)
},
},

talk: {
voiceId: "elevenlabs_voice_id",
modelId: "eleven_v3",
outputFormat: "mp3_44100_128",
apiKey: "elevenlabs_api_key",
interruptOnSpeech: true,
},
}
green pasture
#

I thought adding elevenlabs voice will allow better speech with talk mode

inland hazelBOT
#

Adding ElevenLabs config does help Talk mode — but only for the assistant’s spoken output (TTS voice quality).

It does not improve what the mic hears / speech-to-text accuracy, because the input side is handled by macOS Speech Recognition (Apple), not ElevenLabs.

What ElevenLabs affects in Talk mode:

  • talk.voiceId = which voice is used
  • talk.modelId = which ElevenLabs TTS model is used (default is already eleven_v3)
  • talk.outputFormat = latency/quality tradeoff (on macOS, pcm_44100 is usually the lowest-latency; mp3_* is fine but a bit more overhead)
  • talk.interruptOnSpeech = whether you can “barge in” while it’s speaking

Config goes at top-level like:

{
talk: {
apiKey: "ELEVENLABS_API_KEY", // don’t paste real keys in Discord
#
voiceId: "…",
modelId: "eleven_v3",
outputFormat: "pcm_44100",
interruptOnSpeech: true,
},
}

If your original issue is still happening (app closes when enabling mic): that’s separate from ElevenLabs config. If you paste openclaw --version + macOS version, we can narrow down whether it’s a known macOS permission crash.

green pasture
#

how would i make openclaw open talk sound more realistic?

inland hazelBOT
#

For Talk mode, “more realistic” is basically all ElevenLabs voice + settings + audio format (it won’t change mic input quality).

Here are the biggest levers:

1) Use a great ElevenLabs voice (this matters most)

Pick a higher-quality voice in ElevenLabs (or create/clone one there), then set that voiceId in OpenClaw:

{
talk: {
apiKey: "…", // don’t paste real keys here
voiceId: "…", // this is the big one
modelId: "eleven_v3", // good default
},
}
#

2) Don’t force MP3 if you want “natural”

MP3 can sound a bit more “radio/compressed”. On macOS, use PCM for the most natural audio:

{
talk: {
outputFormat: "pcm_44100",
},
}

(Or just remove outputFormat and let the macOS default kick in.)

3) Tune ElevenLabs voice settings via a Talk directive (optional but powerful)

Talk mode supports a one-line JSON directive at the top of the assistant’s reply to control things like stability/similarity/style.

Example you can try (and keep it persistent with once: false):

#
{ "stability": 0.5, "similarity": 0.85, "style": 0.15, "speakerBoost": true, "speed": 1.0, "once": false }

Rule: it has to be the first non-empty line of the reply.

Docs: https://docs.openclaw.ai/nodes/talk

If you tell me what vibe you want (calm, excited, “real person on a call”, etc.), I can suggest a couple good starting values for stability/similarity/style.

green pasture
#

I thought i changed the voiceid however its the same voice coming out by default still

inland hazelBOT
#

If changing talk.voiceId doesn’t change what you hear, it’s almost always one of these:

1) You edited the wrong config file (CLI vs service)

On macOS, the app/gateway might be running as a service and reading a different config path than the one you edited.

Run this and check Config (service):

openclaw gateway status

Then make sure you edited that file (default is ~/.openclaw/openclaw.json).

Quick sanity check:

openclaw config get talk.voiceId
#

2) Talk mode is not using ElevenLabs (bad/missing key → fallback voice)

If talk.apiKey isn’t set/valid, Talk may fall back to a default/system voice, and then changing voiceId won’t do anything.

Make sure your config has (top-level!):

{
talk: {
apiKey: "…", // don’t post it here
voiceId: "…", // real ElevenLabs voice id
},
}

3) You need to stop Talk mode and start it again

If Talk mode was already running, it can keep the previous voice “latched” until you exit/re-enter Talk mode (or restart the app).


#

If you paste only (redacted) the output of:

  • openclaw gateway status (just the config path lines), and
  • openclaw config get talk.voiceId

…I can tell you exactly which of the above is happening.

green pasture
#

why does it seem like the ai restarted again or reset?

inland hazelBOT
#

In OpenClaw it can feel like a “reset” for a couple different reasons — most commonly it’s not the model restarting, it’s you ending up in a different session.

1) You switched sessions (very common with Talk mode)

  • Talk mode always talks to the main session (session.mainKey, default "main").
  • Your Discord thread/channel is a different session.
    So if you go back and forth between Talk (mac app) and Discord, it’ll seem like it “forgot everything” because it’s literally different chat history.

You can confirm by listing recent sessions:

openclaw sessions --active 180

2) The Gateway/app actually restarted (crash/reload)

This can happen from:

  • the mac app crashing (your mic-permission issue could cause this),
  • a config change that triggers a restart (some sections require it),
  • sleep/wake weirdness.
#

Check:

openclaw gateway status
openclaw logs --limit 200

(Feel free to paste the output here, but redact tokens/keys.)

3) You started a fresh session manually

If you hit /new (or UI “new session”), that’s a real reset of the conversation context.

If you tell me whether the “reset” happened inside Talk mode or in Discord, I can point to the exact cause.

green pasture
#

[Sun 2026-02-15 10:27 EST] Talk Mode active. Reply in a concise, spoken tone. You may optionally prefix the response with JSON (first line) to set ElevenLabs voice (id or alias), e.g. {"voice":"<id>","once":true}. Hello

inland hazelBOT
#

Hello!

If you’re testing Talk mode: it uses the mac app + the main session, so it can feel like a “reset” when you’re chatting here in Discord (different session/history).

If your goal is “different, more realistic voice” in Talk:

  1. Put your ElevenLabs settings under top-level talk (not agents.defaults)
  2. Make sure talk.apiKey is valid (don’t paste it here)
  3. Exit Talk mode and start it again (so it reloads the voice)

If you tell me the exact ElevenLabs voiceId you want to use (or the alias name you set in talk.voiceAliases), I can show the cleanest config + a one-line directive to test it.

green pasture
#

onwK4e9ZLuTAKqWW03F9

inland hazelBOT
#

Tell me what you want me to say—or what you want to test.

If you’re trying to confirm the voice actually changed, do a quick A/B test by forcing a voice just for this one reply (replace with your real ElevenLabs voiceId or an alias you defined in talk.voiceAliases):

{"voice":"<voiceId-or-alias>","once":true}

Then if it still sounds identical, it usually means either:

  • Talk mode is falling back (API key not being used), or
  • you changed the wrong config file / Talk didn’t reload yet (toggle Talk off/on).
#

{"voice":"onwK4e9ZLuTAKqWW03F9","once":true}
Alright — I’m using that voice for this reply. How does it sound now?

green pasture
#

I can't hear you on talk mode

inland hazelBOT
#

Talk mode doesn’t play audio in Discord — you only hear it on the device that’s running Talk (the macOS app overlay, or an iOS/Android node). So if you’re looking at this Discord thread and expecting sound here, you won’t get any.

If you are in the macOS app and still hear nothing, the usual culprits are:

  1. Wrong audio output / muted (System Settings → Sound → Output, and volume up)
  2. ElevenLabs not actually configured (invalid/missing talk.apiKey ⇒ TTS request fails ⇒ silence)
  3. Talk is failing — check logs while you toggle Talk on and speak one sentence:
openclaw --version
openclaw gateway status
openclaw logs --follow

Then start Talk, say “hello”, wait for a reply, and paste the relevant error lines (redact keys/tokens).

Also: are you enabling Talk from the macOS menubar app, or from the web Control UI? (That changes where the audio is supposed to play.)

green pasture
#

15:40:56 info {"0":"","_meta":{"runtime":"node","runtimeVersion":"25.6.1","hostname":"unknown","name":"openclaw","date":"2026-02-15T15:40:56.719Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///opt/homebrew/lib/node_modules/openclaw/dist/entry.js:1255:46","fileName":"entry.js","fileNameWithLine":"entry.js:1255","fileColumn":"46","fileLine":"1255","filePath":"/opt/homebrew/lib/node_modules/openclaw/dist/entry.js","filePathWithLine":"/opt/homebrew/lib/node_modules/openclaw/dist/entry.js:1255","method":"console.log"}},"time":"2026-02-15T15:40:56.720Z"}
15:40:56 info Listening: 127.0.0.1:18789
15:40:56 info Troubles: run openclaw status
15:40:56 info Troubleshooting: https://docs.openclaw.ai/troubleshooting

inland hazelBOT
#

Those lines you pasted are just the Gateway starting up (“Listening: 127.0.0.1:18789”) — nothing there indicates Talk audio is working or failing yet.

A few quick checks to pinpoint why you can’t hear anything:

  1. Where are you expecting to hear audio?
  • You will not hear Talk audio “in Discord”.
  • You only hear it on the device running Talk (the macOS menubar app overlay, or a connected iOS/Android node).
  1. Are you starting Talk from the macOS app, or from the Control UI?
  • If you start Talk from Control UI/WebChat, it expects a connected iOS/Android node to do the audio. Without a mobile node, it won’t play anything.
  1. Capture the actual Talk/TTS error
    Run this, then toggle Talk on and say one sentence:
openclaw logs --follow

You’re looking for lines mentioning talk, tts, elevenlabs, 401, voice not found, etc. Paste those (redact keys/tokens).

#
  1. macOS permissions + output device
    In System Settings → Privacy & Security make sure OpenClaw is allowed for:
  • Microphone
  • Speech Recognition

And in System Settings → Sound, confirm the correct Output device + volume (not muted / not on the wrong speakers/headphones).

If you tell me “I start Talk from (mac app / control UI)” I can give the exact next step.

green pasture
#

when trying to update i'm getting this error
WARN npm install failed; showing last log lines
WARN npm install failed; retrying
WARN npm install failed; showing last log lines

green pasture
#

Config was last written by a newer OpenClaw (2026.2.15); current version is 2026.2.12.

green pasture
#

ran openclaw app and got this

Install failed: npm error code EACCES
npm error syscall open
npm error path /Users/chrisleggio/.npm/_cacache/tmp/b3f4d2db
npm error errno EACCES
npm error
npm error Your cache folder contains root-owned files, due to a bug in
npm error previous versions of npm which has since been addressed.
npm error
npm error To permanently fix this problem, please run:
npm error sudo chown -R 501:20 "/Users/chrisleggio/.npm"
npm error A complete log of this run can be found in: /Users/chrisleggio/.npm/_logs/2026-02-17T03_25_09_185Z-debug-0.log

@inland hazel

inland hazelBOT
#

That error is just an npm permissions problem (your ~/.npm cache has some files owned by root), so the OpenClaw app can’t install/update dependencies and bails.

Fix it by changing ownership of the npm cache back to your user, then retry:

sudo chown -R "$(id -u):$(id -g)" "$HOME/.npm"

(Equivalent to what npm suggested with 501:20, just more future-proof.)

Then run the app again (or reinstall OpenClaw if that’s what you were doing).

Two tips to avoid this coming back:

  • Don’t run npm commands with sudo (that’s usually what causes root-owned cache files).
  • If you’re using nvm/Volta/asdf for Node, keep global installs inside your user home (no sudo needed).

If it still fails after the chown, paste the next error block (and please redact any tokens/keys).

green pasture
#

how to complete remove openclaw from mac mini m4 @inland hazel

inland hazelBOT
#

If you want to completely remove OpenClaw from your Mac mini:

1) Recommended (if the CLI still works)

Run the built-in uninstaller:

openclaw uninstall

If you just want to nuke everything without prompts:

openclaw uninstall --all --yes --non-interactive
# or (if you only have npx)
npx -y openclaw uninstall --all --yes --non-interactive
#

2) Remove the macOS app (if you installed it)

Delete:

rm -rf /Applications/OpenClaw.app

(or just drag it to Trash in Finder)

3) If the app/CLI is gone but the Gateway service still runs (manual cleanup)

OpenClaw’s macOS service is a launchd agent. Run:

launchctl bootout gui/$UID/bot.molt.gateway
rm -f ~/Library/LaunchAgents/bot.molt.gateway.plist
#

(If you used a profile, it may be bot.molt.<profile> instead.)

4) Delete OpenClaw’s local data (this wipes config/state/workspace)

Only do this if you’re sure you don’t need your agent workspace/memory:

rm -rf ~/.openclaw

5) Remove the CLI install (depending on how you installed)

Pick one:

npm rm -g openclaw
# or
pnpm remove -g openclaw
#

To completely remove OpenClaw from your Mac mini (M4), do this in order:

1) Use the built-in uninstaller (recommended)

In Terminal:

openclaw uninstall

Fully automatic wipe (no prompts):

openclaw uninstall --all --yes --non-interactive
# or, if you don’t have the CLI but have npx:
npx -y openclaw uninstall --all --yes --non-interactive
#

2) Delete the macOS app (if you installed it)

  • Finder → Applications → OpenClaw → Move to Trash
    or Terminal:
rm -rf /Applications/OpenClaw.app

3) Remove any leftover background “Gateway” service (launchd) if it’s still running

launchctl bootout gui/$UID/bot.molt.gateway
rm -f ~/Library/LaunchAgents/bot.molt.gateway.plist

4) Remove OpenClaw local data (this deletes config/state/workspace)

Only if you’re sure you don’t need any of your agent workspace/memory:

#
rm -rf ~/.openclaw

5) Uninstall the CLI package (if installed via npm/pnpm/bun)

Pick the one you used:

npm rm -g openclaw
# or
pnpm remove -g openclaw
# or
bun remove -g openclaw

Official guide (same steps): https://docs.openclaw.ai/install/uninstall

#

If you tell me how you installed (macOS app vs install.sh vs npm/pnpm), I can tell you exactly which of the steps above you can skip.

green pasture
#

chrisleggio@Mac-mini ~ % npm rm -g openclaw

npm error code EACCES
npm error syscall rename
npm error path /Users/chrisleggio/.npm-global/lib/node_modules/openclaw
npm error dest /Users/chrisleggio/.npm-global/lib/node_modules/.openclaw-G91xCN05
npm error errno -13
npm error
npm error Your cache folder contains root-owned files, due to a bug in
npm error previous versions of npm which has since been addressed.
npm error
npm error To permanently fix this problem, please run:
npm error sudo chown -R 501:20 "/Users/chrisleggio/.npm"
npm error A complete log of this run can be found in: /Users/chrisleggio/.npm/_logs/2026-02-17T04_11_14_555Z-debug-0.log
chrisleggio@Mac-mini ~ %

inland hazelBOT
#

That error means some files under your npm dirs are owned by root, usually because at some point sudo npm ... was used. Fix the ownership, then uninstall again (don’t run npm with sudo long-term).

Run this in Terminal:

sudo chown -R "$(id -u):$(id -g)" ~/.npm ~/.npm-global

Then retry:

npm rm -g openclaw

If it still complains, paste the next error line(s) — but in most cases the chown above fixes it.

(For reference, npm’s own hint only mentions ~/.npm, but your failure path is in ~/.npm-global, so it’s good to fix both.)

green pasture
#

openclaw app onboarding

inland hazelBOT
#

The macOS app onboarding flow is basically:

  1. Open the OpenClaw app
  2. Click through the macOS permission prompts (local network, etc.)
  3. Choose where the Gateway runs:
    • This Mac (Local) (simplest)
    • Remote (SSH/Tailnet; creds must be on the gateway host)
    • Configure later
  4. Pick which Permissions to grant (you can grant fewer now and enable later)
  5. (Optional) let it install the openclaw CLI
  6. It opens a dedicated onboarding chat session to finish setup/bootstrapping

Docs with screenshots: https://docs.openclaw.ai/start/onboarding

If your app is still crashing when you enable Microphone during onboarding, try this workaround:

  • Go to System Settings → Privacy & Security → Microphone
  • Disable OpenClaw there (or don’t grant Mic in onboarding), relaunch the app, finish onboarding, then enable Mic later.
#

If you tell me whether you’re doing Local or Remote gateway, I can point you to the exact next steps from there.

green pasture
#

how to redo the onboarding for openclaw app

inland hazelBOT
#

To redo onboarding for the macOS OpenClaw app, there are two “reset levels”:

A) Re-run setup without deleting your workspace/memory (recommended)

  1. Quit OpenClaw.app (menu bar icon → Quit)
  2. Re-run the onboarding wizard from Terminal:
openclaw onboard

Then reopen the app and connect to the Gateway again.

B) Full “first-run” reset (start onboarding from scratch)

This wipes/renames your local OpenClaw state, so do this only if you’re ok resetting config (and possibly your workspace if you delete it).

  1. Quit the app
  2. Backup your state dir (safer than deleting):
#
mv ~/.openclaw ~/.openclaw.bak
  1. Launch OpenClaw.app again → it should behave like a fresh install and walk you through onboarding.

(If you truly want to delete everything instead of backing up: rm -rf ~/.openclaw — but I’d backup first.)

If your goal is to re-trigger macOS permission prompts (Mic, etc.)

Go to System Settings → Privacy & Security and remove/disable OpenClaw’s permission entry, then relaunch the app and re-grant.

If you tell me which one you want (A: keep workspace, or B: full reset), I can tailor the exact steps.

green pasture
#

when running openclaw onboard it gives me this error -zsh: command not found: openclaw

inland hazelBOT
#

That just means the OpenClaw CLI isn’t on your PATH (or it’s not installed anymore).

Fastest fix (no install needed)

Run onboarding via npx:

npx -y openclaw onboard

Proper fix (install the CLI)

Install globally (no sudo):

npm install -g openclaw@latest
# then:
openclaw onboard
#

If you previously set a custom global npm dir (like ~/.npm-global) make sure this is in your zsh PATH (in ~/.zshrc):

export PATH="$HOME/.npm-global/bin:$PATH"

Then restart Terminal (or source ~/.zshrc) and try again.

If it still says command not found, paste:

which node
node -v
npm -v
npm prefix -g
echo $PATH
green pasture
#

Backups will be saved to /var/folders/0z/2_l29mhn07q5tbmhj4h19q_40000gn/T/ollama-backups/

Added ministral-3:8b-cloud to OpenClaw

Launching OpenClaw with ministral-3:8b-cloud...
Error: openclaw is not installed, install from https://docs.openclaw.ai

inland hazelBOT
#

That output is basically saying: the thing that’s trying to “launch OpenClaw with ministral…” can’t find the OpenClaw CLI (openclaw) on your system / in your PATH.

Install the OpenClaw CLI (recommended way on macOS)

curl -fsSL https://openclaw.ai/install.sh | bash

Or install via npm (no sudo)

npm install -g openclaw@latest

Verify it’s installed

Open a new Terminal window and run:

openclaw --version
#

If you still get “command not found”, you likely have a custom npm global prefix (like ~/.npm-global). Add this to ~/.zshrc:

export PATH="$HOME/.npm-global/bin:$PATH"

Then:

source ~/.zshrc
openclaw --version

Once openclaw --version works, you can redo onboarding with:

openclaw onboard
green pasture
#

400 model is required

inland hazelBOT
#

That “400: model is required” error is coming from your model provider (OpenAI-compatible style). It means OpenClaw sent a request without a model field, which usually happens when no default model is configured (or the selected model got cleared).

Fix (most common)

  1. Check what OpenClaw thinks your default model is:
openclaw --version
openclaw models status
  1. If it shows no primary model (or missing auth), re-run the wizard to set one:
openclaw onboard

If openclaw isn’t on PATH, use npx

#
npx -y openclaw models status
npx -y openclaw onboard

What I need from you to point to the exact fix

Paste the output of:

openclaw --version
openclaw models status

(and tell me if you’re using Ollama / “ministral-3:8b-cloud” / a custom endpoint / OpenAI / Anthropic).

green pasture
#

why do i need to approve node?

inland hazelBOT
#

You need to approve a node because a node is a separate device that can expose powerful capabilities to the Gateway (depending on platform): camera/screen recording/location, and in some setups even running shell commands (system.run).

So OpenClaw does a device pairing step the first time a new node identity connects, to prevent “any random device on your network / tailnet” from attaching itself to your gateway.

Important: pairing ≠ exec approvals:

  • Device pairing = “is this device allowed to connect as a node at all?”
  • Exec approvals/allowlist = “is this node allowed to run this specific command?”

Docs: https://docs.openclaw.ai/nodes/troubleshooting#pairing-versus-approvals

If you’re stuck at the approval step, the usual flow is:

openclaw devices list
openclaw devices approve <requestId>
green pasture
#

05:46:32 warn Config was last written by a newer OpenClaw (2026.2.15); current version is 2026.2.13.

inland hazelBOT
#

That warning means your ~/.openclaw/openclaw.json was last written by OpenClaw 2026.2.15, but you’re currently running 2026.2.13 (so you effectively downgraded at some point — often because you ran npx -y openclaw ... which uses the latest, then later used an older global install).

  • It’s just a warning. If everything works, you can ignore it.
  • If you start seeing weird config/model/provider errors, the fix is to get your CLI + gateway/app onto the same (newer) version.

Recommended fix (upgrade to match/newer)

If you installed via npm:

npm install -g openclaw@latest
openclaw --version
openclaw gateway restart

If you want to match exactly 2026.2.15:

npm install -g openclaw@2026.2.15
#

If you intentionally want to stay on 2026.2.13

Restore an older config backup (or re-run onboarding) so the config matches that version.

If you paste:

openclaw --version

and tell me whether you’re using the macOS app or CLI-only, I can tell you the cleanest path.

green pasture
#

14:50:38 warn gateway/ws {"subsystem":"gateway/ws"} Proxy headers detected from untrusted address. Connection will not be treated as local. Configure gateway.trustedProxies to restore local client detection behind your proxy.
14:50:38 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=a8b8c92f-331e-4a54-9eba-24772af22e12 remote=127.0.0.1 client=openclaw-control-ui webchat vdev
14:57:57 error [tools] write failed: Missing required parameter: path (path or file_path). Supply correct parameters before retrying.
14:57:57 error [tools] write failed: Missing required parameter: path (path or file_path). Supply correct parameters before retrying.
14:59:57 info typing TTL reached (2m); stopping typing indicator
15:03:01 error Embedded agent failed before reply: All models failed (2): ollama/glm-4.7-flash: LLM request timed out. (unknown) | ollama/qwen3:8b: No available auth profile for ollama (all in cooldown or unavailable). (rate_limit)
15:03:05 error Embedded agent failed before reply: All models failed (2): ollama/glm-4.7-flash: Provider ollama is in cooldown (all profiles unavailable) (rate_limit) | ollama/qwen3:8b: Provider ollama is in cooldown (all profiles unavailable) (rate_limit)
15:03:27 error Embedded agent failed before reply: All models failed (2): ollama/glm-4.7-flash: Provider ollama is in cooldown (all profiles unavailable) (rate_limit) | ollama/qwen3:8b: Provider ollama is in cooldown (all profiles unavailable) (rate_limit)

inland hazelBOT
#

Those log lines are 3 separate issues:

1) Proxy headers detected from untrusted address… trustedProxies

This happens when something in front of the Gateway (nginx/Caddy/Cloudflare tunnel/Tailscale Serve/etc.) is sending X-Forwarded-For / X-Real-IP, but the Gateway doesn’t trust that proxy yet. Result: the connection won’t be treated as “local”.

If you are using a reverse proxy on the same Mac, trust it:

openclaw config set gateway.trustedProxies '["127.0.0.1"]'
openclaw gateway restart

Docs: https://docs.openclaw.ai/gateway/security#reverse-proxy-configuration

If you’re not using a reverse proxy, you can usually ignore it (or figure out what is injecting those proxy headers).

2) [tools] write failed: Missing required parameter: path

#

That’s an internal tool-call error: the model tried to call the write tool but didn’t provide the required path.

In practice this most often happens with local/Ollama models that sometimes generate malformed tool JSON. If you see this a lot, switch to a more tool-reliable model for setup (Anthropic/OpenAI) and keep Ollama for “chat-only” usage.

3) All models failed… ollama… timed out / provider ollama is in cooldown

This is the big one: OpenClaw tried your Ollama models, got timeouts, then put the provider into cooldown (temporary backoff), so it stops hammering it.

Fix checklist:

  1. Make sure Ollama is actually up:
ollama serve
ollama list
curl http://localhost:11434/api/tags
  1. Make sure OpenClaw has Ollama “enabled” (it wants an API key value even though Ollama doesn’t really need one):
#
export OLLAMA_API_KEY="ollama-local"
# or:
openclaw config set models.providers.ollama.apiKey "ollama-local"

Docs: https://docs.openclaw.ai/providers/ollama

  1. Wait a minute or two (cooldown is exponential), or restart the gateway after Ollama is healthy:
openclaw gateway restart

If you paste the output of:

openclaw models status
#

…I can tell you exactly what OpenClaw thinks your active model(s) and Ollama provider config are.

green pasture
#

is this correct?

"gateway": {
"port": 18789,
"mode": "local",
"bind": "0.0.0.0",
"auth": {
"mode": "token",
"token": "token"
},
"tailscale": {
"mode": "serve",
"resetOnExit": false
},
"remote": {
"url": "ws://tonys-mac-mini.tail05f6d8.ts.net:18789",
"sshTarget": "tonylam@tonys-mac-mini.tail05f6d8.ts.net"
}
},

#

@inland hazel

inland hazelBOT
#

Not quite.

1) gateway.bind: "0.0.0.0" is not a valid value

gateway.bind is an enum, e.g. loopback | lan | tailnet | auto | custom — not an IP string.
If you want “0.0.0.0”, use:

gateway: {
bind: "lan", // (= 0.0.0.0)
}

Source: /gateway/configuration-reference (Gateway section)

2) tailscale.mode: "serve" usually wants bind: "loopback"

Recommended Serve setup is loopback + Serve:

#
gateway: {
mode: "local",
port: 18789,
bind: "loopback",
auth: { mode: "token", token: "..." , allowTailscale: true },
tailscale: { mode: "serve", resetOnExit: false },
}

Source: https://docs.openclaw.ai/gateway/tailscale

3) gateway.remote is only for clients (when gateway.mode: "remote")

If this config is on the machine that actually runs the Gateway, you typically don’t need gateway.remote at all.

If this config is on a client machine that should connect to the Mac mini via SSH tunneling, then you’d normally do:

#
gateway: {
mode: "remote",
remote: {
url: "ws://127.0.0.1:18789", // after the SSH forward
token: "...", // same token as the gateway auth token
sshTarget: "tonylam@tonys-mac-mini.tail05f6d8.ts.net",
},
}

Source: https://docs.openclaw.ai/gateway/remote and /cli/gateway (Remote over SSH)


If you tell me where this config lives (on the Mac mini gateway host, or on a separate client Mac), and whether you want Serve or direct ws://…:18789, I can paste the exact “correct” block for your setup.

#

Also: if the app is “closing instantly”, run openclaw doctor once — invalid bind values will fail schema validation and can make things look like a crash.

green pasture
#

The config and gateway is on the mac and uses the model which is on a windows pc running ollama model glm-4.7-flash

#

@inland hazel

inland hazelBOT
#

If you pinged because of the mic-toggle crash: yep, that’s a known macOS failure mode sometimes (TCC permissions cache / signature mismatch). It’s not caused by the gateway config.

Docs mention this exact symptom: https://docs.openclaw.ai/platforms/mac/dev-setup#app-crashes-on-permission-grant

Try this on the Mac mini

  1. Find the app bundle id
osascript -e 'id of app "OpenClaw"'
  1. Reset permissions for that bundle id (replace <BUNDLE_ID> with the output above)
tccutil reset All <BUNDLE_ID>
  1. Re-open OpenClaw and re-grant Microphone + Speech Recognition in System Settings → Privacy & Security.
#

If it still crashes

Please paste:

  • openclaw --version
  • your macOS version
  • the newest crash file from ~/Library/Logs/DiagnosticReports/ (OpenClaw*.crash) with tokens/redactions if any

Also, on your config snippet: gateway.bind should be "lan" (not "0.0.0.0").

green pasture
#

The config and gateway is on the mac and uses the model which is on a windows pc running ollama model glm-4.7-flash
@inland hazel

green pasture
#

The config and gateway is on the mac and uses the model which is on a windows pc running ollama model glm-4.7-flash
@inland hazel

green pasture
#

It looks like I've hit a security mismatch (device token mismatch). This usually happens after a configuration change or a manual restart if the Mac mini app hasn't "refreshed" its session token with the Gateway.
@inland hazel where is that

green pasture
#

why does the gateway dashboard close when the openclaw app launch on mac

#

why does the gateway dashboard close when the openclaw app launch on mac @inland hazel

inland hazelBOT
#

The “Gateway Dashboard” is just the UI (a webview/browser window) talking to the Gateway. On macOS, turning on “use microphone” can crash/close the Dashboard window if the app/webview hits a macOS privacy/permission edge case (WebRTC getUserMedia → mic permission prompt/entitlement/permission state). That’s why it looks like “the dashboard closes when the app launches” — it’s usually the UI process dying, not the gateway itself.

A few quick checks/workarounds:

  1. What versions?
    Paste:
  • openclaw --version
  • macOS version (e.g. 14.x / 15.x)
  • Does the Gateway stay running? (openclaw gateway status)
  1. Reset mic permission for the app + retry
    System Settings → Privacy & Security → Microphone → toggle OpenClaw off/on (or remove permission if it’s stuck), then relaunch.

  2. Workaround: use the Dashboard in a normal browser
    Run openclaw dashboard and open the URL in Chrome/Edge. If the mic toggle works there, the issue is specifically the mac app/webview.

  3. Grab the crash log (this is the smoking gun)

#

Open Console.app → Crash Reports and look for an OpenClaw crash at the time you enable the mic. If you can paste the top of that report (or the exception line), we can tell if it’s a known WebRTC/mic permission crash.

If you confirm it’s reproducible, please file a bug with those details: https://github.com/openclaw/openclaw/issues (version + macOS + crash snippet).

green pasture
#

Trying to set up peekaboo but keep getting

Error: Screen recording permission is required. Please grant it in System Settings > Privacy & Security > Screen Recording.

green pasture
#

Is mac app needed for openclaw? Whats the point of the app vs terminal

inland hazelBOT
#

No — the macOS app is not required to use OpenClaw.

What you actually need

  • The Gateway running (usually started/managed from the terminal): that’s the real “server” that connects to Discord/Telegram/etc, runs agents, tools, crons, nodes, etc.
  • Any client UI (optional) to control it.

Point of the macOS app

It’s basically a convenience UI bundle:

  • quick way to open the Dashboard/Control UI
  • manage/view sessions more comfortably than tailing logs
  • (depending on build) extra desktop niceties like tray/window management

But it’s not where the core automation lives.

Point of the terminal/CLI

The terminal is the authoritative control plane:

  • start/stop/restart gateway: openclaw gateway restart
#
  • check status/logs: openclaw status, openclaw doctor
  • configure providers, tokens, models, etc.
  • it keeps working even if the UI crashes (like your mic situation)

Practical advice

If the mac app is crashing when mic is enabled, you can just:

  • run the gateway from terminal
  • open the dashboard in Chrome via openclaw dashboard

If you tell me what you’re trying to do with the microphone (voice chat in Discord? speech-to-text? talking to the agent locally?), I can point you at the best path that avoids the app crash.

green pasture
#

how would i go about agent to agent communication? one agent on the mac and the other is on windows

green pasture
#

🦞 OpenClaw 2026.2.19-2 (45d9b20) — I'm like tmux: confusing at first, then suddenly you can't live without me.
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-02-20.log
Command: /opt/homebrew/Cellar/node/25.6.1/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 8117, state active)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
tonylam@Tonys-Mac-mini ~ % openclaw gateway status

🦞 OpenClaw 2026.2.19-2 (45d9b20) — Type the command with confidence—nature will provide the stack trace if needed.

│
â—‡
Service: LaunchAgent (not loaded)
File logs: /tmp/openclaw/openclaw-2026-02-20.log
Command: /opt/homebrew/Cellar/node/25.6.1/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.
Runtime: unknown (Bad request.
Could not find service "ai.openclaw.gateway" in domain for user gui: 501)

RPC target: ws://127.0.0.1:18789
gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: cli --url
Config: /Users/tonylam/.openclaw/openclaw.json
@inland hazel