#Openclaw App Close Due to Mic
1 messages · Page 1 of 1 (latest)
How do I upload markdown or crashreport?
ased on your provided crash log, here are the three critical sections you should share:
- 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
- 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.
- 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?"
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)
- Quit OpenClaw (make sure it’s not still running as a menu bar app).
- 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
- Go to System Settings → Privacy & Security → Microphone (and Speech Recognition) and remove/disable OpenClaw if it’s listed.
- Reboot (macOS sometimes won’t re-prompt cleanly until a restart).
- 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.
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
Thoughts?
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):
- Quit OpenClaw fully (menu bar icon gone).
- Reset mic + speech permissions:
tccutil reset Microphone ai.openclaw.mac
tccutil reset SpeechRecognition ai.openclaw.mac
# if needed:
tccutil reset All ai.openclaw.mac
- System Settings → Privacy & Security → Microphone + Speech Recognition:
- remove/disable OpenClaw if it’s listed
- Reboot (macOS sometimes won’t re-prompt cleanly without this)
- 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
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
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):
- Generate a token (only fills it in if missing):
openclaw doctor --generate-gateway-token
- Verify it exists:
openclaw config get gateway.auth.token
- 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
…and paste that same token into the Control UI settings if it prompts.
Docs: https://docs.openclaw.ai/help/faq#the-control-ui-says-unauthorized-or-keeps-reconnecting-what-now
If you paste openclaw config get gateway.auth.mode + openclaw config get gateway.bind, I can tell you if you need token auth (lan/tailnet/remote) or if you’re just on loopback.
Does the openclaw app conflict with running it through brew or powershell? Should one be deleted or removed?
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
openclawCLI 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:
- Two different
openclawbinaries on PATH (e.g. one from npm, one from somewhere else)
Check:
which -a openclaw
openclaw --version
- 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.
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
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).
is stable, beta or dev updates better?
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
openclaw --version
Docs:
- Stable vs beta: https://docs.openclaw.ai/help/faq#whats-the-difference-between-stable-and-beta
- Channels (beta/dev): https://docs.openclaw.ai/install/development-channels
how would i run the same ai agent on both a windows pc and mac?
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.runon that Windows machine) and approve it on the gateway.
Docs:
- Nodes overview: https://docs.openclaw.ai/nodes
- FAQ section (“Remote gateways and nodes”): https://docs.openclaw.ai/help/faq#remote-gateways-and-nodes
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.
mac mini is the brain agent to run local commands on both machines
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.runto 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:
-
Tailscale (recommended): put both machines on the same tailnet and expose the Gateway over tailnet
Docs: https://docs.openclaw.ai/gateway/tailscale + https://docs.openclaw.ai/gateway/remote -
SSH tunnel (simple + secure): from Windows, forward a local port to the Mac mini’s gateway port.
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
execruns 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:
openclaw --versionfrom both machines, and- which connection you prefer (Tailscale vs SSH tunnel),
I can give you the exact minimal command set for your setup.
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
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.appon the machine (e.g. not one in/Applicationsand 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.
Reference (docs mention this exact mic/speech crash pattern, even though it’s under dev setup):
https://docs.openclaw.ai/platforms/mac/dev-setup (see “App Crashes on Permission Grant”)
If it turns out to be a real app bug on macOS 26.3, the right escalation is a GitHub issue with the full crash log: https://github.com/openclaw/openclaw/issues
I cant attach the full file
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)
- Get the newest crash report path:
ls -t ~/Library/Logs/DiagnosticReports/OpenClaw_*.crash | head -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_....crashand 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?
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
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:
- Reset mic/speech TCC (then reboot):
tccutil reset Microphone bot.molt.mac
tccutil reset SpeechRecognition bot.molt.mac
- 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.
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
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
- Bad/unsupported mic format (sample rate / channel count mismatch), often with USB interfaces / Bluetooth headsets.
- Previously selected mic device is gone (app tries to tap a device that disconnected).
- CoreAudio is wedged right after permission grant.
Fastest workaround (get the app opening again)
- 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)
- 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.
- Re-enable Mic permission in System Settings and try again.
Fix the underlying audio state
Do these in order:
- In System Settings → Sound → Input
- Select Built‑in Microphone
- Make sure input level moves when you talk
- 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)
- 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
Issue tracker: https://github.com/openclaw/openclaw/issues
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:
-
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). -
Inside OpenClaw, disable Voice Wake / talk features (anything that listens constantly / PTT).
-
Set macOS input device to something sane:
System Settings → Sound → Input → choose Built-in Microphone (for now). -
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.
I am running this on a mac mini m4 which doesn't have a microphone it seems.
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):
- System Settings → Privacy & Security → Microphone → toggle OpenClaw OFF
- Open OpenClaw → disable Voice Wake / talk / push‑to‑talk (anything that listens)
- 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”?
Let's report the bug
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
- Install/Open OpenClaw.app on Mac mini.
- Enable Microphone permission (or toggle Voice Wake / talk features).
- 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).
Nice — that’s the right place.
Two quick suggestions to make issue #16418 maximally actionable for the maintainer who picks it up:
- Add the “uncaught exception … reason …” line from the crash report (that line usually tells exactly why
installTapOnBusfailed). 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
- 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.
Openclaw app general settings states openclaw cli not found in path;install the cli
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.
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
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.)
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):
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.
where should the tailscale link get pointed to since i'm running nginx
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 liketonys-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.
is
"allowedOrigins": [
can be used in openclaw .json?
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?
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"
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,
},
}
Docs: https://docs.openclaw.ai/nodes/talk
(Separate thing: if what you want is TTS for normal text replies in chat, that config lives under messages.tts, not talk.)
I thought adding elevenlabs voice will allow better speech with talk mode
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 usedtalk.modelId= which ElevenLabs TTS model is used (default is alreadyeleven_v3)talk.outputFormat= latency/quality tradeoff (on macOS,pcm_44100is 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.
how would i make openclaw open talk sound more realistic?
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.
I thought i changed the voiceid however its the same voice coming out by default still
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), andopenclaw config get talk.voiceId
…I can tell you exactly which of the above is happening.
why does it seem like the ai restarted again or reset?
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
mainsession (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.
[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
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:
- Put your ElevenLabs settings under top-level
talk(notagents.defaults) - Make sure
talk.apiKeyis valid (don’t paste it here) - 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.
onwK4e9ZLuTAKqWW03F9
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?
I can't hear you on talk mode
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:
- Wrong audio output / muted (System Settings → Sound → Output, and volume up)
- ElevenLabs not actually configured (invalid/missing
talk.apiKey⇒ TTS request fails ⇒ silence) - 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.)
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
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:
- 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).
- 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.
- 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).
- 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.
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
Config was last written by a newer OpenClaw (2026.2.15); current version is 2026.2.12.
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
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
npmcommands withsudo(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).
how to complete remove openclaw from mac mini m4 @inland hazel
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
# or
bun remove -g openclaw
Docs (same steps, kept up to date): https://docs.openclaw.ai/install/uninstall
If you tell me how you installed (macOS app vs npm/pnpm vs install.sh), I can give you the shortest exact set of steps for your setup.
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.
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 ~ %
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.)
openclaw app onboarding
The macOS app onboarding flow is basically:
- Open the OpenClaw app
- Click through the macOS permission prompts (local network, etc.)
- Choose where the Gateway runs:
- This Mac (Local) (simplest)
- Remote (SSH/Tailnet; creds must be on the gateway host)
- Configure later
- Pick which Permissions to grant (you can grant fewer now and enable later)
- (Optional) let it install the
openclawCLI - 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.
how to redo the onboarding for openclaw app
To redo onboarding for the macOS OpenClaw app, there are two “reset levels”:
A) Re-run setup without deleting your workspace/memory (recommended)
- Quit OpenClaw.app (menu bar icon → Quit)
- 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).
- Quit the app
- Backup your state dir (safer than deleting):
mv ~/.openclaw ~/.openclaw.bak
- 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.
when running openclaw onboard it gives me this error -zsh: command not found: openclaw
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
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
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
400 model is required
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)
- Check what OpenClaw thinks your default model is:
openclaw --version
openclaw models status
- 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).
why do i need to approve node?
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>
05:46:32 warn Config was last written by a newer OpenClaw (2026.2.15); current version is 2026.2.13.
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.
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)
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:
- Make sure Ollama is actually up:
ollama serve
ollama list
curl http://localhost:11434/api/tags
- 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
- 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.
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
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.
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
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
- Find the app bundle id
osascript -e 'id of app "OpenClaw"'
- Reset permissions for that bundle id (replace
<BUNDLE_ID>with the output above)
tccutil reset All <BUNDLE_ID>
- 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").
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
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
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
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
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:
- What versions?
Paste:
openclaw --version- macOS version (e.g. 14.x / 15.x)
- Does the Gateway stay running? (
openclaw gateway status)
-
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. -
Workaround: use the Dashboard in a normal browser
Runopenclaw dashboardand open the URL in Chrome/Edge. If the mic toggle works there, the issue is specifically the mac app/webview. -
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).
Trying to set up peekaboo but keep getting
Error: Screen recording permission is required. Please grant it in System Settings > Privacy & Security > Screen Recording.
Is mac app needed for openclaw? Whats the point of the app vs terminal
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.
how would i go about agent to agent communication? one agent on the mac and the other is on windows
🦞 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