#OpenClaw TUI and Dashboard swallow input on macOS

1 messages · Page 1 of 1 (latest)

fickle marshBOT Mar 14, 2026, 5:56 AM

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

rough kindleBOT Mar 14, 2026, 6:02 AM

This symptom pattern on macOS (curl works, but TUI + Control UI “eat” sends / no replies) is most often: the Gateway process doesn’t actually have the Moonshot/Kimi key (because it’s running via launchd/service, not your interactive shell), so every run fails immediately and the UIs don’t surface it nicely.

Can you paste the output of these (redact tokens/keys)?

openclaw --version
openclaw status
openclaw gateway status
openclaw models status
openclaw doctor

Then do this to capture the real error:

In one terminal:

openclaw logs --follow

In another terminal, send one message from openclaw tui (or the dashboard) and copy the log lines that appear right after.

Quick “most likely fix” to try (service env)

If you start the Gateway as a background service, put your key in ~/.openclaw/.env (so launchd can see it), then restart:

Env vars accepted for Kimi/Moonshot are typically MOONSHOT_API_KEY (also KIMI_API_KEY in some setups).
Docs: https://docs.openclaw.ai/help/faq#i-started-the-gateway-via-the-service-and-my-env-vars-disappeared-what-now

Alternative: enable shell import (opt-in):
https://docs.openclaw.ai/help/faq#i-started-the-gateway-via-the-service-and-my-env-vars-disappeared-what-now

One fast isolation test

Stop the service and run the gateway in the foreground (inherits your current env), then try the TUI again:

openclaw gateway
# in another terminal:
openclaw tui

If that works, it’s 99% an env/service config issue (not a Kimi API issue).

If you drop the openclaw logs --follow snippet from a failed send here, I can tell you exactly which branch it is (missing key vs auth/token mismatch vs provider error).

rough kindleBOT Mar 14, 2026, 6:56 AM

Nice, that rules out the “launchd ate my env vars” class of problems.

What you’re describing now (“TUI shows the message”, then run stays running, and no new log lines appear) usually means one of these two things:

the Gateway is stuck before it emits any useful logs (commonly session-store / transcript lock weirdness), or
the Gateway did start the run but is now hanging inside the first network call (Moonshot request never returns / streaming handshake stalls), so nothing errors and nothing new gets logged at info.

Given doctor is already complaining about missing transcripts + stale session lock, I’d chase (1) first, then prove/disprove (2).

1) Quick “session-store isolation” test (no nuking)

In the TUI, before sending any text, run:

/new
then send: hello

If /new suddenly makes replies work, your old “main” session key is pointing at a busted/missing transcript entry and the gateway is getting wedged on session init/write.

Also please paste:

openclaw sessions --json
openclaw sessions cleanup --dry-run --json

(That will show whether the session index references transcript files that don’t exist, and what cleanup would do. Don’t run --enforce yet.)

2) Force the gateway to show what it’s stuck on

Instead of relying on openclaw logs --follow, run the gateway with debug logging in the foreground and watch that terminal:

OPENCLAW_LOG_LEVEL=debug openclaw gateway

Then reproduce once from the TUI (/new, send hello). If it’s hanging in session-store locking or in the Moonshot HTTP call, debug logs should make that obvious (or at least show the last subsystem it touched).

3) Prove whether Moonshot calls hang from Node (vs curl)

While the gateway is up, run a live provider probe:

openclaw models status --probe --probe-provider moonshot --probe-timeout 15000

If this hangs or times out, it’s almost certainly a Node↔Moonshot connectivity/streaming/TLS thing (even if curl works).
If probes succeed quickly but chat runs hang, it’s more likely session-store / run-queue.

Two quick context questions

What macOS version is this?
When the TUI is stuck in running, what does /status inside the TUI show (especially model + run id)?

If you paste the sessions --json + cleanup --dry-run --json + the last ~30 lines from the debug gateway terminal right after you hit Enter, I can tell you which branch you’re in and what the next “real fix” is.

rough kindleBOT Mar 14, 2026, 7:39 AM

That’s super actionable data — and it basically rules out “TUI/dashboard input bug” and “session store corruption” as the primary cause.

You’ve now proven:

Gateway receives the message and starts the embedded run
Provider/model resolution is correct (provider=moonshot, model=kimi-k2.5)
The Moonshot probe works but is insanely slow (45s)
The actual chat run can sit “running” effectively forever

That combination is very consistent with the first Moonshot completion call hanging at the transport layer (most likely the streaming call: connection established, then no/never-ending SSE body).

Here are the two fastest “fix-or-narrow” switches to try:

1) Force IPv4 first (fixes a lot of “Node is slow but curl is fine” cases)

If your network has flaky IPv6, Node can burn ages trying v6 before falling back.

Try this for both the probe and the gateway:

NODE_OPTIONS="--dns-result-order=ipv4first" openclaw models status --probe --probe-provider moonshot
NODE_OPTIONS="--dns-result-order=ipv4first" openclaw gateway

If probe time drops from ~45s to ~1–3s and chats start completing, that’s the culprit.

2) Disable model streaming for Moonshot (workaround for “SSE hangs”)

OpenClaw’s OpenAI-compatible adapters typically stream by default. If SSE is what’s wedging, forcing non-streaming JSON responses often fixes it.

Add this to your openclaw.json (JSON5) under the agent defaults, then restart the gateway:

{
agents: {
defaults: {
models: {
"moonshot/kimi-k2.5": {
params: {
streaming: false,
},
},
},
},
},
}

Even if this is “just” a workaround, it should unstick runs immediately if the hang is in SSE.

Quick confirmation test (optional, but decisive)

Run a curl with stream=true (SSE) to see if streaming itself hangs on your machine/network. If curl streaming also stalls, it’s not an OpenClaw-specific bug — it’s Moonshot streaming + your network path.

About the “removed stale session lock … (dead-pid)”

Given /new doesn’t help and sessions cleanup reports missing: 0, I’d treat that message as noise/cleanup behavior, not the root cause.

If you try (1) IPv4-first and (2) params.streaming:false, tell me which one changes behavior (probe latency + whether “hello” completes). If neither helps, the next step is: paste the last ~30 debug lines right after it logs the Moonshot request starting, because we’ll want to see whether it’s stuck before connect, after headers, or after first chunk.

rough kindleBOT Mar 14, 2026, 7:56 AM

Got it — with this extra data, I agree: it’s not “input swallowed”, and it’s probably not purely “SSE streaming hangs” either.

One important clarification though: params.streaming in OpenClaw is used in a few places for channel preview streaming behavior (Discord/Slack/etc). It is not guaranteed to disable LLM transport streaming for api: "openai-completions" providers like Moonshot. So the fact that params.streaming=false didn’t change the hang doesn’t actually rule much out yet.

At this point the fastest way to stop guessing is to answer one binary question:

Is the gateway receiving any model stream events back from Moonshot for that run?

Do this: capture raw model stream events

Run the gateway with raw stream logging:

OPENCLAW_LOG_LEVEL=debug openclaw gateway --raw-stream --raw-stream-path /tmp/moonshot-raw.jsonl

Then in TUI: /new → hello, wait ~30–60s.

Now check whether the raw stream file grows:

wc -l /tmp/moonshot-raw.jsonl
tail -n 20 /tmp/moonshot-raw.jsonl

Interpretation:

If /tmp/moonshot-raw.jsonl stays empty (or has only an initial “request start” but no deltas):
the run is hanging before the first byte of model output → this is almost certainly a network/proxy/TLS/connectivity stall on the actual completion request (even if the probe endpoint works).
If it contains deltas / content / message_end events:
Moonshot is responding, and the bug is in OpenClaw’s event handling / run finalization / broadcast to clients (TUI + Control UI both missing it would make sense then).

One more high-value environment check (because probes are slow)

On the Mac, do you have any proxy env vars set? These can make Node behave very differently from curl:

env | rg -i '(_proxy|https_proxy|http_proxy|all_proxy|no_proxy)'

If you see anything, try a clean test shell with them unset (just for the gateway process).

If you paste:

whether the raw stream file gets events, and
the last ~10 lines of tail -n 20 /tmp/moonshot-raw.jsonl (redact if needed)

…I can tell you which side of the fence it’s on and what the next specific fix/workaround is.

rough kindleBOT Mar 14, 2026, 8:22 AM

Yep — if the gateway is started with --raw-stream --raw-stream-path … and the file never even gets created, that strongly suggests you’re hanging before the first model stream event arrives (i.e. stuck in DNS/connect/TLS/request/TTFB on the actual chat/completions call).

At this point I’d do two very targeted checks to pinpoint where it’s stuck:

1) Compare curl timings against the chat completions endpoint (not just “curl works”)

Can you run one non-streaming and paste the timing line?

curl -sS -o /dev/null \
-w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
-H "Authorization: Bearer $MOONSHOT_API_KEY" \
-H "Content-Type: application/json" \
https://api.moonshot.ai/v1/chat/completions \
--data '{"model":"kimi-k2.5","messages":[{"role":"user","content":"hello"}],"stream":false}'

If curl shows a normal TTFB (say <5s) but OpenClaw never gets any bytes back, that points to a Node/undici-specific networking issue on that machine.

If curl’s ttfb is also huge / hangs, it’s upstream/network-path.

2) Try disabling compression / keepalive for Moonshot (easy config-side experiment)

Some “works in curl, hangs in Node” cases end up being weirdness around Accept-Encoding + streaming/chunked responses.

OpenClaw supports provider headers. Try adding:

{
models: {
providers: {
moonshot: {

headers: {
"Accept-Encoding": "identity",
"Connection": "close",
},
},
},
},
}

Restart gateway, retry once. (No secrets needed in the paste.)

Also: can you paste the output of this (even if it’s empty)?

env | rg -i '(_proxy|https_proxy|http_proxy|all_proxy|no_proxy)'

If those two tests don’t change anything, the next step is grabbing the last ~20 gateway debug lines right after “provider=moonshot model=kimi-k2.5” (there’s usually a “making request …” log we can anchor on). If it looks like a reproducible Node↔Moonshot hang on macOS 26.2, that’s GitHub-issue-worthy with the curl timing + log snippet.

At this point you’ve basically exhausted the “obvious knobs”. Given:

gateway does start the run and resolves provider=moonshot model=kimi-k2.5
raw stream file is never created → zero model stream events arrive
probe is “ok” but very slow

…the remaining question is why the actual chat completion request never reaches “first byte of response” in Node/OpenClaw on your Mac.

To move forward we need one of these two artifacts (either one is enough to identify the failure mode):

A) Curl timing to the chat completions endpoint (TTFB)

Please run exactly this and paste the single timing line it prints (no secrets included):

curl -sS -o /dev/null \
-w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
-H "Authorization: Bearer $MOONSHOT_API_KEY" \
-H "Content-Type: application/json" \
https://api.moonshot.ai/v1/chat/completions \
--data '{"model":"kimi-k2.5","messages":[{"role":"user","content":"hello"}],"stream":false}'

If curl’s ttfb is low (a few seconds) but OpenClaw never gets any bytes, that screams Node/undici/macOS issue (not Moonshot itself).

B) The last ~30 gateway log lines after it starts the run

Run the gateway with trace (just for one reproduction):

OPENCLAW_LOG_LEVEL=trace openclaw gateway

Then /new → hello, wait ~20–30 seconds, and paste the last ~30 lines from the gateway terminal. I’m looking for the last line that mentions an HTTP request / “request start” / “calling provider”.

One more “likely win” question: what Node version are you on?

Can you paste:

node -v
which node

If you’re on a bleeding-edge Node (24/25/nightly), it’s worth doing one clean test with Node 22 LTS. A bunch of “hangs forever” reports end up being undici/TLS regressions in non-LTS Node builds on new macOS releases.