What Runs on Port 19001? Your DenchClaw Workspace

If you've installed DenchClaw and opened Activity Monitor or run lsof -i :19001, you've seen it: a Node.js process listening on port 19001. That process is the OpenClaw gateway — the engine that powers everything DenchClaw does.

This post explains what's actually running on port 19001, how it works, and how to interact with it directly.

The Architecture at a Glance#

DenchClaw runs as two main processes:

1. The gateway (openclaw gateway) — runs on port 19001. This is the brains: the AI agent runtime, the API server, the session manager, the database interface, and the tool executor.

2. The frontend — served by the gateway at localhost:3100. This is the web UI you see in your browser (or Dock PWA).

The port split is intentional: 19001 is the programmatic API layer; 3100 is the human-readable UI layer. You can talk to both independently.

What the Gateway Does#

The OpenClaw gateway on port 19001 is responsible for:

Session Management#

Each conversation with the DenchClaw agent is a session — an isolated context with its own message history, agent state, and working memory. The gateway manages creating, routing, and terminating sessions.

When you open the web chat at localhost:3100, the frontend connects to ws://localhost:19001/sessions/main/stream — a WebSocket for real-time message streaming.

Tool Execution#

When the agent decides to run a tool (read a file, execute SQL, scrape a URL, send a message), it sends a tool call request to the gateway. The gateway executes it in the appropriate context and returns results.

Tools include:

• exec — run shell commands
• read / write / edit — file operations
• browser — control the Chromium browser
• web_search / web_fetch — internet access
• message — send messages on connected channels
• sessions_spawn — spawn isolated subagent sessions
• canvas — control the DenchClaw Canvas UI element

Database Access#

The gateway is the DuckDB interface. All reads and writes to workspace.duckdb go through the gateway's database layer. This ensures proper connection management (DuckDB only allows one writer at a time) and handles PIVOT view generation.

Channel Routing#

The gateway connects to all your messaging channels: Telegram, WhatsApp, Discord, Signal, iMessage, etc. When a message arrives on any channel, the gateway routes it to the appropriate agent session, executes the response, and routes the reply back.

Skill Loading#

When a session needs to use a skill, the gateway loads the SKILL.md and injects it into the agent's context. The skill directory structure is served through the gateway's file system bridge.

The HTTP API#

The gateway exposes a REST API at http://localhost:19001. You can interact with it directly:

# Check gateway health
curl http://localhost:19001/health
 
# List active sessions
curl http://localhost:19001/api/sessions
 
# Send a message to the main session
curl -X POST http://localhost:19001/api/sessions/main/message \
  -H "Content-Type: application/json" \
  -d '{"content": "How many open deals do I have?"}'
 
# Get session history
curl http://localhost:19001/api/sessions/main/history?limit=10
 
# Execute a database query
curl -X POST http://localhost:19001/api/db/query \
  -H "Content-Type: application/json" \
  -d '{"sql": "SELECT COUNT(*) FROM v_people WHERE \"Status\" = '\''Lead'\''"}'

This API is how DenchClaw Apps (window.dench bridge) communicate with the gateway. When your custom app calls dench.db.query(...), it's making a POST to the gateway's query endpoint.

WebSocket Streaming#

Agent responses stream token-by-token via WebSocket. The frontend connects to:

ws://localhost:19001/sessions/main/stream

Messages follow a simple protocol:

// Client → Gateway: send a message
{"type": "message", "content": "show me my pipeline"}
 
// Gateway → Client: streaming token
{"type": "token", "content": "Here "}
 
// Gateway → Client: tool call started
{"type": "tool_start", "name": "exec", "input": {...}}
 
// Gateway → Client: tool call complete
{"type": "tool_result", "name": "exec", "output": "..."}
 
// Gateway → Client: message complete
{"type": "done", "messageId": "msg_123"}

You can connect to this WebSocket directly from any client — build your own custom DenchClaw interface if you want.

Gateway Configuration#

The gateway is configured via the OpenClaw profile at ~/.openclaw/profiles/dench/. Key config files:

~/.openclaw/profiles/dench/
  config.yaml          ← model, channels, tool permissions
  channels/
    telegram.yaml      ← Telegram bot config
    discord.yaml       ← Discord bot config
  tools/
    exec.yaml          ← shell execution permissions

You can edit these directly or via the agent:

# View current config
openclaw config show --profile dench
 
# Restart the gateway after config changes
openclaw gateway restart --profile dench

Managing the Gateway Process#

# Check if gateway is running
openclaw gateway status
 
# Start the gateway
openclaw gateway start
 
# Stop the gateway
openclaw gateway stop
 
# Restart (picks up config changes)
openclaw gateway restart
 
# View gateway logs
openclaw gateway logs --tail 100
 
# View gateway logs live
openclaw gateway logs --follow

The gateway is designed to run as a background process. On macOS, you can configure it to start at login via launchctl — DenchClaw does this automatically on first install.

Port 19001 vs. Port 3100#

Both ports are served by the same gateway process, just at different paths:

• localhost:19001 — programmatic API (JSON, WebSocket, tool execution)
• localhost:3100 — web UI (served by the gateway's built-in static file server + reverse proxy)

The 3100 port isn't a separate process — it's a convenience alias. All requests to localhost:3100 are proxied through to the gateway's frontend serving layer on 19001.

Security Notes#

Both ports listen on localhost only — they're not accessible from other devices on your network unless you explicitly expose them.

There's no authentication by default for localhost access, since only processes running on your machine can reach localhost. If you want to expose DenchClaw over a local network (e.g., to access from your phone on Wi-Fi), configure Tailscale or add authentication:

# config.yaml
gateway:
  auth:
    enabled: true
    token: "your-secret-token"

Frequently Asked Questions#

Why does DenchClaw use port 19001 specifically?#

OpenClaw chose 19001 to avoid conflicts with common development tools (3000, 8080, 5000, etc.). The dench profile inherits this default.

Can I change the port?#

Yes. Edit config.yaml in the profile directory and restart the gateway. Also update any Telegram/Discord webhook configurations if you've set those up.

Is it safe to expose port 19001 to the internet?#

Not without authentication enabled. Add auth to the config and consider using Cloudflare Tunnel or Tailscale instead of direct port exposure.

What happens if the gateway crashes?#

OpenClaw has automatic restart logic built in. If the process crashes, launchctl (macOS) or systemd (Linux) will restart it. You can also run openclaw gateway start manually.

Can multiple DenchClaw profiles share a port?#

No. Each profile runs its own gateway on its own port. If you run multiple OpenClaw profiles, each gets a unique port.

Ready to try DenchClaw? Install in one command: npx denchclaw. Full setup guide →