Codebase Tour: CLI → Gateway → Agent
This is a top-down tour. The goal isn’t to read every file—it’s to build a reliable mental map so you can follow the call chain.
The 6 questions to keep in your head
- Where does the CLI start (entry + command dispatch)?
- What is the Gateway “control plane” (connect/auth/method calls/subscriptions)?
- How do channels deliver inbound messages (shared envelope)?
- How does routing pick an
agentIdandsessionKey(and keep groups isolated)? - How does a reply get produced (agent loop: run → attempt → streaming)?
- How are tools executed safely (sandbox + tool policy + approvals)?
One-line end-to-end flow
Channel inbound → Gateway normalizes + routes → enqueue by sessionKey (lane) → trigger the agent runtime → stream a reply → (optionally) run tools → deliver back to the same channel.
Start with these docs (in order):
Two planes in the Gateway
Control plane
- Client
connects - Calls methods (e.g.
chat.send) - Subscribes to event streams (chat/agent/presence/tick)
See:
Data plane
chat.sendstarts a run (non-blocking ACK); results arrive via streamed eventslogs.tailpowers Control UI log tailing
Routing + isolation (why conversations don’t leak)
Routing aims for:
- Deterministic delivery (reply goes back to the same channel)
- Isolation (groups/channels get separate session keys)
Key concept: inbound message → resolve agentId/sessionKey → enqueue on lane: session:<key> to preserve ordering.
See:
Tool execution: why there are three layers
OpenClaw separates risk into:
- Sandbox (where it runs)
- Tool policy (what it’s allowed to do)
- Approvals (when a human is required)
See:
The fastest practical way to learn
- Run a chat once (
openclaw dashboard/ Control UI). - Tail logs:
openclaw logs --follow, note the runId from achat.send. - Read: TypeBox → session tool → agent loop → queue.
- When stuck, use: logging / troubleshooting / security docs.