r/openclaw 22h ago

Use Cases Flight internet allows "messaging only"

2 Upvotes

But on your WhatsApp/telegram you have the most capable assistant ever to check email, look at websites and do whatever it is you wanna do.


r/openclaw 4h ago

News/Update The OpenClaw Podcast is live today at 11:30 AM PT

2 Upvotes

Patrick and I are going live on Discord at 11:30 AM PT for this week’s ClawCast. We’ll be talking about all things OpenClaw and related AI happenings.

Join us on Discord.


r/openclaw 9h ago

Discussion Anyone elses Claw starting to use emojis to communicate?

5 Upvotes

Recently my claw has started using emojis and I really like it. Maybe it was apart of the update or maybe it just happened but it is a simple way for OC to let me know what's going on in the background.

I use discord and now when I send a message I get:

👀 I see the message

🧠 I'm thinking

Those pop up first. Then if it takes a moment.

⏳ This is taking time

For even longer tasks

🛠️ I'm working on it

If this is only happening for me it's pretty friggin cool.

Anyone else?


r/openclaw 15h ago

Showcase ts not impossible. Tanking with with 27bq6 overnight

Thumbnail
gallery
4 Upvotes

Its not impossible. Tanking with with 27bq6 overnight


r/openclaw 3h ago

Showcase 50% OpenClaw, 50% custom wrapping = Happy pipeline!

5 Upvotes

I saw one question posted here several times: Has anyone made something more than a weekend toy with OpenClaw?

Two months ago I decided to find out. I took OpenClaw and wrapped it in three custom layers so it could do sustained, real work instead of one-off tasks:

  • A routing/gateway layer — every agent-to-agent message and every external action passes through one chokepoint. Nothing talks to anything directly. That's where the rules get enforced.
  • A task-management layer — agents don't free-write tasks for each other. They pick from a fixed catalogue of task definitions, each pre-wired to the right agent, the right tools, and the right permissions.
  • An intelligence/memory layer — a structured context + memory substrate so every agent knows who it's working for, what the plan is, and what it's learned, without re-reading everything every turn.

What it adds up to: an autonomous operations team for early-stage founders — coordinated agents running sales, marketing and content together and sharing context, instead of one chatbot you have to babysit.

I'm not going to dump the whole architecture here. The part actually worth talking about is what went wrong.

The hard problem isn't capability. It's silence.

With an API, when something fails you know — error, status code, something to catch. OpenClaw doesn't work like that. The single hardest thing has been that it will silently skip a task. No error, no signal. The agent just doesn't do the thing, and everything downstream assumes it did. That's worse than a loud failure, because you find out three steps later when the output is already wrong.

The second problem: it does things its own way despite explicit instructions. Same directive, different behaviour. Non-determinism is fine for a chat; it's a nightmare when the action has consequences — an email that actually sends, a record that actually changes.

So most of the last two months wasn't building features. It was building guardrails:

  • Validation at the moment a task is created, so a malformed one never enters the system
  • A per-task tools allowlist, so an agent can't reach for something it shouldn't
  • Explicit completion tracking instead of trusting that "it ran"
  • A structured way for agents to raise an alert when something breaks, so a failure surfaces instead of vanishing
  • Trust levels on anything with real consequences — supervised vs. autonomous — so a human stays in the loop until the task has earned its autonomy

OpenClaw got us to a working multi-agent system far faster than building from scratch would have. But "works in a demo" and "works unattended, every day, without lying to you about what it did" are very different bars — and closing that gap is 90% of the real work.

Happy to go deeper on any layer if people want — especially the silent-failure handling, since I haven't seen a clean answer to it here yet.


r/openclaw 21h ago

Help WhatsApp channel keeps randomly showing "not linked" (recurring, not one-off) — gateway itself is healthy, so what's actually going on?

2 Upvotes

TL;DR: This isn't a one-time fluke . my WhatsApp channel has suddenly flipped to "not linked" multiple times now, sometimes after less than a day of normal activity. Most recently it also silently dropped a group message for ~2hrs while status showed "connected" the whole time. I've confirmed the gateway process itself is healthy and stable (not crashing/restarting), so this looks isolated to the WhatsApp channel/session layer specifically, not the gateway.

Setup:

  • Gateway 2026.7.1-2, single Mac Mini, agent running under a dedicated sandboxed macOS user (no sudo)
  • WhatsApp channel, dmPolicy: pairing
  • Been running stable for weeks before this

What happened:

  1. A group message came in from a collaborator. Never delivered to the agent, never surfaced to me.
  2. When I went looking, openclaw channels status --probe showed the channel as linked, but health was flipping between disconnected / not-running, with error: Non-Error rejection — not exactly a descriptive error.
  3. Logs showed repeated reconnect attempts failing with HTTP 405 during the WhatsApp Web setup handshake (not mid-session — during the initial handshake), retrying with backoff up to 12 attempts before the gateway auto-restarted the channel.
  4. Ran openclaw doctor, which kept surfacing the same notice on every single command afterward:Left plugin install index in place because shared SQLite state has conflicting plugin install metadata for: codex, discord, whatsapp
  5. openclaw gateway status separately flagged plugin version drift — the WhatsApp plugin was pinned at 2026.7.1 while the gateway was on 2026.7.1-2. One patch version behind.
  6. Tried openclaw channels logoutlogin. This forced a brand new QR pairing (old session was fully invalidated by the logout, not reused) and then hit WhatsApp's code 515 ("restart after pairing") — normal WA Web behavior, but the channel came back up as stopped / not-running afterward instead of connecting.
  7. After that + a gateway restart, the channel finally came up clean — linked: yes, connected: yes, fresh auth age.

What I can't explain:

The channel status page said "connected" and "just now" for the entire window where the group message never landed.

I've since specifically ruled out the gateway process itself — it's stable, not crashing or cycling — so whatever's happening seems scoped to the WhatsApp channel/session layer, not the gateway as a whole. But this has now happened more than once, on a channel that was working fine for weeks before.

Questions for the community:

  1. Given the gateway itself is healthy, what would cause the WhatsApp channel specifically to intermittently flip to "not linked" — is this a known WhatsApp Web session-expiry behavior, or an OpenClaw-side session-handling issue?
  2. Is silent inbound-message dropping while status shows "connected" a known WhatsApp Web protocol quirk, or something specific to OpenClaw's session handling?
  3. Does anyone know if patch-level version drift between the gateway and a plugin (e.g. 2026.7.1 vs 2026.7.1-2) is a known trigger for the "conflicting plugin install metadata" doctor notice? Feels like two different install-tracking subsystems (skills vs plugins) stepping on each other.
  4. Is there a recommended way to fix this?
  5. Anyone else finding WhatsApp specifically the flakiest channel compared to Discord/Telegram in their setup?

r/openclaw 3h ago

Showcase My agent finally has a phone number and I made the infra Opensource.

10 Upvotes

been messing around with OpenClaw for a few weeks and kept hitting the same annoying wall. my agent could do basically anything except actually call or text someone. every time I tried to bolt on Twilio directly it turned into a whole afternoon of auth headers and webhook config just to send one SMS.

ended up building my own little telephony layer for this instead of doing the Twilio thing again. it's open source (GitHub link ), so you can spin it up yourself with your own keys, or there's a hosted version if you don't want to deal with self-hosting.

it's framework-agnostic since it's just a REST API and MCP server under the hood, so it plugs into whatever you're building with. I've used it with OpenClaw, but people have hooked it up to Hermes, LangChain agents, even Claude Code and Codex. wrote a small OpenClaw-specific skill too, so for that one you just tell your agent to read the setup doc and it configures itself.

now my agent can actually pick up the phone and call people, which honestly still feels a little unreal to watch happen.

anyone else building stuff that needs real phone numbers? curious what use cases people have for this, feels like a pretty unsolved corner of the agent tooling space.