OpenClaw (formerly clawdbot and moltbot) is a viral AI assistant that has been trending in Google searches and GitHub stars. The project has risen significantly since January 25, 2026.

The project works by chaining skills such as email access, browser automation, or calendar, and it enables users to create complex automations such as management of email inboxes, news triage, and integrations with messaging apps.

This practical aspect makes it a great productivity booster but due to safety concerns such as wide OS and filesystem access, security practitioners may want to detect and prevent installation of OpenClaw.

How can you detect the presence of OpenClaw?

For this experiment, I used a VPS running Ubuntu 24.04.3 LTS with a Splunk Universal Forwarder to ship available host telemetry. To approximate endpoint detection and response (EDR) functionality on a Linux system, I combined Zeek for network monitoring (running on a cooked mode capture) with auditd for syscall-level visibility into command execution and real-time filesystem changes.

This setup represents a Linux-specific detection approach; artifacts and telemetry will differ on macOS and Windows systems. In production environments, many of these signals would be more reliably and efficiently collected using a full EDR platform or tools such as osquery.

The goal here is to demonstrate how OpenClaw can be detected using commonly available, open-source telemetry sources.

Using running process data

The presence of the openclaw-gateway process is a good indication that OpenClaw is running on a host. In this case I’m using process telemetry collected using Splunk Add-on for Unix and Linux.

index=main sourcetype=ps
| rex field=_raw "(?m)^(?<line>(?!USER\s+PID).*(openclaw-gateway|openclaw).*)$"
| where isnotnull(line)
| stats latest(_time) AS _time latest(line) AS line by host

Using network data - listening ports

By default, the OpenClaw gateway runs on port 18789. There’s a high likelihood that if you see this port open and listening on a host, you’ve spotted an installation of the gateway.

18789 - OpenClaw Gateway

18792 - OpenClaw Browser

index=main sourcetype=netstat
| rex field=_raw max_match=0 "(?m)^(?<line>(?:tcp|tcp6)\s+\S+\s+\S+\s+\S+:(?:18792|18789)\s+\S+\s+LISTEN\s*)$"
| where isnotnull(line)
| mvexpand line
| rex field=line "^(?<proto>\S+)\s+(?<recv_q>\S+)\s+(?<send_q>\S+)\s+(?<local_addr>\S+)\s+(?<foreign_addr>\S+)\s+(?<state>\S+)"
| rex field=local_addr ":(?<local_port>\d+)$"
| stats
    count as listen_rows
    values(local_addr) as local_addresses
    values(foreign_addr) as foreign_addresses
    values(local_port) as ports
    latest(_time) as _time
  by host

Using network data - mDNS broadcasts

When the OpenClaw gateway starts, it announces itself via multicast DNS (mDNS) on the local network. This behavior enables automatic discovery by companion components (such as the browser relay) and is observable on UDP/5353 -> 224.0.0.251.

The gateway advertises a custom service type and publishes rich metadata via PTR, SRV, TXT, A, and AAAA records. This makes mDNS a strong network-based indicator of OpenClaw activity, especially in environments where endpoint telemetry is limited.

Below is a representative tcpdump capture taken during gateway startup:

IP 192.0.2.10.5353 > 224.0.0.251.5353: 0*- [0q] PTR om-test._openclaw-gw._tcp.local.,
    (Cache flush) SRV openclaw.local.:18789 0 0,
    (Cache flush) TXT "role=gateway" "gatewayPort=18789"
        "lanHost=openclaw.local" "displayName=om-test"
        "transport=gateway",
    (Cache flush) A 192.0.2.10,
    (Cache flush) AAAA 2001:db8::10

IP 192.0.2.10.5353 > 224.0.0.251.5353: 0 [2q] ANY (QM)?
    om-test._openclaw-gw._tcp.local. ANY (QM)? openclaw.local.

Looking for installation of the companion Chrome extension

The OpenClaw extension is loaded as an unpacked extension via Developer Mode. The extension ID is derived from the absolute path on disk, so each install with a different path or on a different machine results in a different ID.

However the extension name is consistent. So you can look in your Chrome extensions telemetry for an extension called “OpenClaw Browser Relay”.

Looking for install-time indicators

Command-line activity can be monitored to detect both direct installer script downloads and package-manager–based installations.

This includes executions that fetch OpenClaw installer scripts (for example via curl one-liner) as well as global installs performed with package managers such as npm.

In this case, I track these installations using Linux auditd, which provides visibility into executed commands at the syscall level.

Most popular openclaw installation methods:

// One-liner script

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

// Using npm

npm i -g openclaw

index=os sourcetype=linux:audit type=EXECVE (openclaw AND curl) OR (openclaw AND npm)
| rex max_match=0 field=_raw " a\d+=\"(?<argv>[^\"]*)\""
| eval cmdline=mvjoin(argv," ")
| table _time host cmdline 
| sort - _time

Looking for file indicators

OpenClaw’s default installation and state directory is ~/.openclaw. The presence of this path on a system is a strong indicator that the OpenClaw agent has been installed or used.

Key artifacts under this directory include:

~/.openclaw/openclaw.json - the primary configuration file.

~/.openclaw/workspace/ - the workspace directory

These filesystem artifacts provide a high-confidence signal of OpenClaw installation or prior usage, even when the gateway process is not currently running.

Example Splunk search using auditd file events:

index=os sourcetype=linux:audit .openclaw/.openclaw.json