Setting Up OpenClaw on IRC - AI Agents in Classic Chat Channels

IRC might seem like an odd choice for running AI agents in 2026. But there are good reasons it keeps coming up. Plenty of development teams, open source communities, and technical organisations still run their real-time communication on IRC. Libera.Chat alone has tens of thousands of active users daily. If your team lives in IRC, forcing them to switch to a different platform just to interact with an AI agent creates friction nobody needs.

OpenClaw's IRC channel documentation covers the configuration details, and it's well written. What I want to do here is walk through the setup from a practical standpoint - what the config actually means, where the gotchas are, and how to think about security when you're putting an AI agent into a channel where anyone can talk to it.

The Basic Setup

OpenClaw ships IRC support as an extension plugin, but you configure it in the main config file at ~/.openclaw/openclaw.json under channels.irc. The minimum configuration looks like this:

{
  "channels": {
    "irc": {
      "enabled": true,
      "host": "irc.libera.chat",
      "port": 6697,
      "tls": true,
      "nick": "openclaw-bot",
      "channels": ["#your-channel"]
    }
  }
}

After saving the config, start or restart the gateway with openclaw gateway run. The bot connects to the IRC server, joins the specified channels, and starts listening.

A few things to note about this basic setup. TLS is set to true, and you should keep it that way. There's no good reason to run a bot on plaintext IRC in 2026 unless you're connecting to a network that genuinely doesn't support TLS (and if that's the case, question whether you should be connecting at all). Port 6697 is the standard TLS port for most IRC networks.

The nick is what your bot will appear as in the channel. Pick something descriptive. Users need to know they're talking to a bot, not a person.

Understanding the Three Layers of Access Control

This is where IRC configuration gets interesting - and where most people trip up. OpenClaw has three separate gates that a message must pass through before the bot will respond to it:

Layer 1 - Channel access. Is the bot allowed to accept messages from this channel at all? This is controlled by groupPolicy and groups. By default, groupPolicy is set to "allowlist", meaning the bot ignores channels that aren't explicitly listed.

Layer 2 - Sender access. Is this particular user allowed to trigger the bot? Even if the channel is allowed, the sender might not be. This is controlled by groupAllowFrom (global) or per-channel allowFrom settings.

Layer 3 - Mention gating. Even if the channel and sender are both allowed, the bot defaults to only responding when it's mentioned by name. This prevents it from responding to every single message in a busy channel.

The most common support issue we see is people configuring layer 1 (adding the channel to the allowlist) but forgetting about layer 2 or 3. The bot joins the channel, sits there silently, and nobody can figure out why.

If your logs show messages like irc: drop group sender alice!ident@host (policy=allowlist), that's layer 2 blocking the message. The sender isn't in the allowlist. Fix it by setting groupAllowFrom globally or allowFrom per channel.

If the logs show drop channel ... (missing-mention), that's layer 3. The bot is waiting to be mentioned by name before it responds. You can disable this per channel with requireMention: false.

A Practical Configuration for a Team Channel

Here's what a real team channel configuration looks like, with all three layers addressed:

{
  "channels": {
    "irc": {
      "enabled": true,
      "host": "irc.libera.chat",
      "port": 6697,
      "tls": true,
      "nick": "openclaw-bot",
      "groupPolicy": "allowlist",
      "groups": {
        "#your-team": {
          "allowFrom": ["*"],
          "requireMention": false
        }
      }
    }
  }
}

This configuration says: allow messages from the #your-team channel, allow any sender in that channel to interact with the bot, and don't require the bot to be mentioned. For a private team channel where everyone is trusted, this is usually what you want.

For a public channel, you'd want much tighter controls. Which brings us to security.

Security for Public Channels

Putting an AI agent in a public IRC channel where allowFrom: ["*"] means anyone on the internet can prompt your bot. That's a real attack surface. Someone could try to prompt-inject it, use it to exfiltrate information, or abuse its tool access.

OpenClaw lets you restrict which tools are available per channel. This is where you want to be conservative:

{
  "channels": {
    "irc": {
      "groups": {
        "#public-channel": {
          "allowFrom": ["*"],
          "tools": {
            "deny": ["group:runtime", "group:fs", "gateway", "nodes", "cron", "browser"]
          }
        }
      }
    }
  }
}

This strips out the dangerous tool categories - filesystem access, runtime execution, gateway management, scheduled tasks, and browser automation. The bot can still answer questions and use its knowledge tools, but it can't do anything destructive.

Even better, you can use toolsBySender to give different access levels to different people:

{
  "toolsBySender": {
    "*": {
      "deny": ["group:runtime", "group:fs", "gateway", "nodes", "cron", "browser"]
    },
    "id:your-nick": {
      "deny": ["gateway", "nodes", "cron"]
    }
  }
}

The wildcard "*" applies to everyone by default - heavily restricted. Your own identity gets a looser policy with more tools available. The first matching policy wins, so order matters.

A note on identity matching: OpenClaw uses the id: prefix for IRC sender identities. You can match on just a nick (id:eigen) or on a full hostmask (id:[email protected]) for stronger verification. Bare nick matching without the hostmask is weaker because nicks can be impersonated if NickServ authentication isn't enforced.

NickServ Authentication

If your IRC network supports NickServ (most do), configure it:

{
  "channels": {
    "irc": {
      "nickserv": {
        "enabled": true,
        "service": "NickServ",
        "password": "your-nickserv-password"
      }
    }
  }
}

This authenticates your bot's nick on connect, preventing other users from impersonating it. If the nick isn't registered yet, you can set register: true and registerEmail: "[email protected]" for one-time registration. Disable the register flag after the nick is registered to avoid repeated registration attempts on every connect.

Environment Variables

If you prefer not to put credentials in config files (and you should prefer that), OpenClaw supports environment variables for all IRC settings:

• IRC_HOST, IRC_PORT, IRC_TLS
• IRC_NICK, IRC_USERNAME, IRC_REALNAME
• IRC_PASSWORD
• IRC_CHANNELS (comma-separated)
• IRC_NICKSERV_PASSWORD

This fits better with containerised deployments where you're pulling secrets from a vault or environment configuration rather than baking them into config files.

Troubleshooting the Common Issues

Bot connects but never replies. Check all three layers. Is the channel in your groups config? Is the sender allowed (check groupAllowFrom or per-channel allowFrom)? Is mention gating dropping the message? Enable debug logging and look for drop messages to identify which layer is blocking.

Login failures. Verify the nick is available on the IRC network. If someone else has registered it, you'll need a different nick. Check that the server password (if required) is correct.

TLS failures. Some private IRC networks use self-signed certificates. You may need to configure certificate trust settings depending on your deployment. For standard networks like Libera.Chat, TLS should work out of the box.

Why IRC for AI Agents?

I'll be honest - for most Australian businesses, IRC isn't the first channel you'd set up for an AI agent. Slack, Teams, or Discord are more common in corporate environments. But IRC has real advantages for certain use cases.

Development teams that already use IRC don't need to change their workflow. The protocol is open and well-understood, so there are no vendor lock-in concerns. Latency is minimal - IRC messages are tiny compared to the overhead of modern chat platform APIs. And for open source communities that want to provide AI-assisted support in their existing channels, IRC is the natural choice.

OpenClaw's multi-channel architecture means you can run the same agent across IRC, Slack, Discord, and other platforms simultaneously. The IRC channel is just one more endpoint. For organisations exploring AI agent deployment across multiple communication platforms, our OpenClaw managed service handles the configuration and ongoing management, so your team can focus on defining what the agent should actually do rather than wrangling config files.

If you're building AI agents and want to understand the broader landscape - which platforms make sense, how to handle security across channels, and how to structure your agent architecture - get in touch with our team. We've deployed OpenClaw across a range of channels for Australian organisations and can help you figure out the right setup for your specific situation.