Most coding-agent workflows assume you’re at a terminal.

I wanted the opposite: operate coding agents from messaging, with OpenClaw as the control layer, while keeping the workflow reliable enough for real engineering.

This post is the exact setup I use locally.

Why this model works

You keep one operator interface (chat) and swap execution agents as needed: Codex for implementation speed, Claude for planning and structured reasoning, Gemini for an alternate review perspective. Your command style doesn’t change. Only the agent prefix does.

Remote coding, not just chat commands

The practical shift here is remote operation. You can start, monitor, and steer coding runs from your phone, handle triage and review loops through text or voice, and keep work moving while away from terminal access, as long as control paths stay explicit.

That last point is why command discipline matters: remote workflows need clear status, cancel, reset, and recovery behavior. During a commute I can run next, status, or review. Between meetings I can assign a scoped implementation step. After a merge I can run a quick follow-up check without opening a full dev environment.

In action

OpenClaw coding-agent control from Telegram

From chat, I route tasks with a codex:, claude:, or gemini: prefix, and control run state with status, cancel, reset, and next. I won’t re-explain the shorthand and modifiers here; that lives in two earlier posts: Notation System for LLM Prompts and Personal Command Language for AI. The one rule worth repeating: each command returns Sent -> Result -> State -> Next, so updates stay consistent and easy to track from a small screen.

Setup

This setup uses a local OpenClaw installation, ACP support, and a connected messaging channel.

OpenClaw handles orchestration: the chat interface, routing, and lifecycle control. The ACP runtime is the execution path for the coding agents, and in this local setup ACPX is the bridge that runs and persists sessions for agents such as Codex and Claude. Chat surfaces differ in thread and session behavior, so a deterministic session-naming fallback helps. This split keeps command usage stable while execution backends vary.

1) Install and onboard

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

2) Verify runtime

openclaw gateway status
openclaw status
openclaw doctor

3) Configure model auth

openclaw models auth add
openclaw models status

4) Secure messaging access

openclaw pairing list
openclaw pairing approve

This is enough to start driving agents from chat.

What to expect in real usage

On the good path you send claude: next with details, the agent checks issues and context, and you get one recommendation with rationale.

The failure mode that catches people is execution context. Sometimes the agent’s network or permission context differs from the host’s. The symptom: an agent can run gh commands syntactically but fails to reach api.github.com in its own execution context, while host gh works fine.

When that happens, verify host health (openclaw status), check gh auth status, and retry the agent task once. If it’s still blocked, fetch the data from the host and pass it to the agent as input. The key is to treat this as an execution-context issue, not a prompt issue. No amount of rewording the prompt fixes a blocked network path.

Multi-agent coordination

Once you run more than one agent, coordination matters more than model quality. Keep one active implementation task per agent, mark explicit ownership (a claimed issue or in-progress marker), and use isolated branches or worktrees for parallel tracks. Keep review and implementation as separate turns. This prevents collisions, duplicate edits, and corrupted context.

Final take

For messaging-driven coding, operational consistency matters more than prompt style. OpenClaw gives you a consistent command protocol, multi-agent routing, observable run states, and quick interrupt and recovery paths. That combination is what makes chat a usable control interface for day-to-day development.

Further reading