Inbound events fire—Telegram, webhooks, cron—but users see no assistant text. That is often silent failure, not a lazy model: heartbeat paired with thinking, a gateway bound only to 127.0.0.1, phantom workflow paths in context, or a process that already exited while you stare at an old chat. This article gives a fixed sequence: openclaw status → doctor → health → logs, then heartbeat/thinking and scheduler parity; plus how to open the web console in a VNC session on a remote Mac so SSH-only checks stop lying to you.
For ten concrete error recipes see the common-errors post; for launchd see the daemon checklist; for containers see the Docker guide. This page targets one class: trigger present, no visible reply.
After reading you should answer three checks: Is the gateway process still running? Do scheduled jobs share the same environment and model flags as your interactive shell? Is the console bound to the interface you are actually testing? If any answer is no, pause before swapping models.
1. Symptom buckets
- Channel stays empty: inbound OK, no outbound text; logs may show a run without user-visible output.
- Only scheduled jobs mute: interactive chat works; cron/heartbeat silent—suspect thinking, heartbeat model, or different env under scheduler.
- False dead gateway: curl works locally but not remotely; listener on loopback—browser test inside VNC clarifies fast.
These buckets often overlap: a scheduled job may log a run while thinking consumes visible tokens, and you may be probing ports from the wrong host. Label the symptom first, then follow the fixed command chain below instead of mixing three different hypotheses at once.
2. Why silence instead of stack traces
- Thinking without channel text: model spends steps internally; short heartbeat windows look like nothing happened.
- Context pollution: repeated ENOENT for a hallucinated workflow file leaks control tokens and scrambles delivery.
- Config fork: interactive shell has PATH and keys; launchd or Docker does not—doctor passes in one session and fails in another.
- Bind and firewall: console on 18789 only on localhost looks like total outage from another host.
- Retries swallowed by the channel: some transports stop surfacing errors after backoff; the UI may still look “connected.” Correlate with
logsfor retry or channel errors, not only green indicators. - Multiple binaries or stale launchd paths: the
openclawyou run in an interactive shell may not match the daemon’s binary;doctorcan look healthy while the running process is an older build.
3. Symptom × first checks matrix
| You see | Check first | Then |
|---|---|---|
| Manual OK, schedule mute | heartbeat model + thinking | launchd/cron env vs shell |
| Always mute | openclaw status | doctor + health --json |
| Logs show run, no reply | outbound path / model output | long thinking without flush |
| Console won’t load | listen address + firewall | browser inside VNC |
| Sometimes text, usually empty | channel throttling / retry lines in logs | model timeouts + thinking steps |
The matrix is a first-glance aid, not an exhaustive taxonomy. When in doubt, return to status → doctor → health → logs before changing providers.
4. Seven-step command flow
openclaw status
Verify processes under expected user; after plist edits, reload launchd.
openclaw doctor
Capture dependency and permission failures once for the ticket.
openclaw health --json
Diff two runs to spot drift in endpoints or versions.
openclaw logs --follow
Reproduce with tail running; note timestamps before Ctrl+C.
Heartbeat/cron thinking
If docs recommend off for heartbeat, apply and retest scheduled path.
Clear phantom workflow context
Reset agent context or fix config when ENOENT loops appear.
Browser console inside VNC
Cross-check loopback vs LAN/tunnel; pair with Docker/launchd posts for ports.
Minimal ticket template
Copy these five fields into every repro note: (1) trigger type (manual / cron / Telegram); (2) one-line status takeaway; (3) whether doctor reported blockers; (4) gateway + model endpoint versions from health --json; (5) ~30 lines from logs --follow with timestamps. Two weeks of discipline turns “silent” bugs into bisectable work.
5. Reference notes and checklist
- Saved doctor + health output once?
- Heartbeat shares config with interactive chat?
- Checked bind address (0.0.0.0 vs 127.0.0.1)?
- Captured logs with timestamps during repro?
6. FAQ and related posts
Vs common-errors article? That list is error-centric; this is silent, no-string failures and command order.
Docker? Run the same commands inside the container; map ports and test from host/VNC per Docker guide.
Headless cloud VMs vs a Mac with VNC? Daemons can run headless, but local callbacks, trust prompts, or “click once in the browser” steps stall without a GUI. A rented Mac with VNC buys end-to-end observability, not just CPU.
Closing
No reply usually means config, process, thinking, and bind address—not a broken model. If your daily OS is Windows or Linux but the gateway must run on real macOS, renting a VNC-accessible remote Mac keeps doctor, logs, and browser checks on one desktop. VNCMac plus the site’s OpenClaw series helps turn silence into a reproducible ticket.
When everything looks blank, ask whether the channel truly lacks outbound text or thinking/formatting ate it—logs usually split those paths in seconds and save you from rotating API keys blindly.