Hey folks,

Running OpenClaw with 3 main lanes, 6 subagent lanes, and channels across Discord, WhatsApp, Telegram, Slack. One recurring pain point: browser-based workflows completely starve all other channels.

What happens

Some of my channels trigger browser automation — multi-step web app workflows that legitimately take 5-10 minutes. These run on the main lane, same as a quick text reply.

When the agent is doing browser work for several minutes, that's 1 of 3 main slots gone. Two browser messages = 2 of 3 blocked. Three = full queue, nothing gets through.

Typical log pattern:

lane wait exceeded: lane=main waitedMs=298360 queueAhead=1
Slow listener detected: DiscordMessageListener took 416s
[lane-queue] enqueue: lane=main queueDepth=5

Queue depth 5, wait times over 4 minutes. Eventually the browser service crashes from accumulated pressure — but sessions keep retrying browser calls, holding lanes hostage until the 600s embedded run timeout.

A simple text message that needs 10 seconds sits in queue for 5+ minutes because all lanes are occupied by browser work.

Why existing options don't solve it

• More main lanes: main=4 triggers Anthropic 429 rate limits. main=3 is the sweet spot.
• Shorter timeouts: Kills legitimate multi-step browser workflows.
• Cron lane instead of channel listener: Loses real-time reactivity, and cron lane gets blocked the same way.
• Subagent lanes: Only for sub-tasks within a session. Channel messages always enter on main.

What would help

A dedicated browser lane — or more generally, per-channel lane routing. The infrastructure already supports it: setCommandLaneConcurrency and enqueueCommandInLane accept arbitrary strings, not just the CommandLane enum. The plumbing is there, just needs a config surface.

Option A — per-channel lane assignment:

{
  "agents": {
    "defaults": {
      "maxConcurrent": 3,
      "lanes": {
        "browser": { "maxConcurrent": 2 }
      }
    }
  }
}

With per-channel config to assign a lane.

Option B — auto-detect: if a session invokes the browser tool, transparently move subsequent work to a dedicated browser lane so it stops blocking text-only sessions.

Impact

Affects anyone combining browser automation with messaging channels. Browser work is inherently slow and unpredictable (page loads, retries, crashes), and right now it directly competes with fast text replies for the same limited main lane slots.

Related: #16055, #29685, #10334

Love OpenClaw — this is the one thing that keeps biting me. Thanks for considering it.