OpenClaw Only Chatted. Here's What I Found After 3 Hours of Debugging.

When OpenClaw stopped executing commands and only gave me instructions to run manually, I had to figure out why.

I noticed the problem during a routine task. I asked OpenClaw to create a config file for a new project. Instead of doing it, the agent responded with:

“You can create this file by running: echo 'content' > config.json”

That’s not how this works. I’ve been using OpenClaw for weeks—it’s supposed to just do these things. Read files, execute commands, write code. But right now, it was acting like a chatbot with no hands.

Every request got the same treatment. “Create a test file” got instructions to run touch. “Read my package.json” got a suggestion to use cat. “Check disk space” got df -h.

The conversational layer worked. The execution layer was gone. I spent the next three hours figuring out why.

Hour 1: The obvious checks

First assumption: The gateway is down. OpenClaw runs a local gateway that connects the agent to your filesystem and tools. If it’s not running, you get chat-only mode.

I ran:

openclaw gateway status

Output: running. Okay, not that.

Second assumption: Discord connection issue. I was using Discord as my interface. Maybe the connection was flaky?

But messages were flowing fine. I could chat, get responses, even have it analyze code I pasted. The problem wasn’t connectivity—it was capability.

Third assumption: Some kind of rate limiting. Maybe I’d hit a usage cap?

Checked my OpenAI dashboard. Plenty of quota remaining. No errors in the logs.

I restarted the gateway anyway, because that’s what you do:

openclaw gateway restart

No change. Still chat-only.

Hour 2: Digging into config

At this point, I was reading through OpenClaw’s documentation and GitHub issues. There were scattered reports of “chat-only mode” but no consistent fix. One issue mentioned tool profiles. Another mentioned agent configuration. A third suggested checking environment variables.

I started poking at the config:

openclaw config get

Everything looked normal. Discord token was set. Default model was correct. No obvious errors.

Then I checked the tools configuration specifically:

openclaw config get tools

And there it was:

{
  "profile": "messaging",
  "deny": []
}

Profile was set to messaging.

I stared at that for a full minute. I hadn’t changed it. I didn’t even know messaging was a valid profile. But there it was.

The root cause

The messaging profile is intentionally stripped down. It gives the agent chat abilities and session management—and nothing else. No filesystem access. No command execution. No tool usage.

It’s designed for environments where you want an AI assistant that can’t touch your system. Think customer support bots, shared chat interfaces, or any scenario where you want conversation without consequences.

But I was in my development environment. I needed the full tool suite.

The question was: How did it get set to messaging?

I traced back through my recent activity. I’d updated OpenClaw the day before. The update process must have reset the config to defaults, and the default for my environment was apparently messaging rather than coding.

The fix

Once I knew the problem, the fix was trivial:

openclaw config set tools.profile coding
openclaw gateway restart

I verified it worked:

openclaw status --deep

Looking for:

tools.profile: coding ✓
tools.available: ["exec", "read", "write", ...] ✓

Then I tested the full chain:

# Create
openclaw do "create a file called test.txt with hello world"

# Read
openclaw do "read test.txt"

# Execute
openclaw do "run pwd"

All three worked. The agent was back to being an agent.

Why this keeps happening

I’ve hit this twice now. Both times after updates. Here’s the pattern I’ve noticed:

Post-update reset: An OpenClaw update sometimes resets config defaults. If your environment variables or config files get regenerated, tools.profile may revert to messaging as a safe default.

Multi-environment confusion: I run OpenClaw in a few different contexts—local dev, a remote VM, occasionally a container. Each has its own state directory. It’s easy to think you’re in your “coding” environment when you’re actually connected to a “messaging” one.

Silent failure mode: The frustrating part is how quietly it fails. The agent doesn’t say “I can’t execute commands because my profile is messaging.” It just… suggests you run them yourself. The conversational layer works perfectly, so it feels like everything is fine except the agent is being weirdly passive.

My diagnostic checklist (now)

When OpenClaw “only chats” now, I run this in order:

# 1. Check the profile
openclaw config get tools

# 2. Verify gateway is reachable
openclaw gateway status

# 3. Deep status check
openclaw status --deep

What I’m looking for:

tools.profile should be coding (or at least not messaging)
Gateway should show reachable: true
Tool list should include exec, read, write

Prevention

I added this to my shell profile:

# OpenClaw sanity check
if command -v openclaw &> /dev/null; then
  PROFILE=$(openclaw config get tools.profile 2>/dev/null | tr -d '"')
  if [ "$PROFILE" = "messaging" ]; then
    echo "⚠️  WARNING: OpenClaw profile is 'messaging'—tools disabled"
  fi
fi

Now I get a warning every time I open a terminal if the profile is wrong.

The bigger lesson

This isn’t really about OpenClaw. It’s about how modern AI agents have two distinct layers: the conversational brain (LLM) and the execution environment (tools). When troubleshooting, you have to figure out which layer failed.

If responses are nonsense → LLM issue (model, context, prompt)
If responses are sensible but passive → Tool issue (profile, permissions, gateway)

“Chat only” mode is almost always the latter. The agent understands what you want; it just doesn’t have permission to act.

Three hours of debugging for a one-line fix. But now I know exactly what to check next time.

Related: