[Bug]: kimi-claw bridge mode bypasses standard agent routing — bindings & dmScope ignored

Bug type

Behavior bug (incorrect output/state without crash)

Summary

kimi-claw plugin (bridge token mode) routes all inbound messages to agent:main:main session, completely bypassing OpenClaw's standard bindings routing pipeline and session.dmScope isolation logic. Other channels (Telegram/Discord/WhatsApp/Feishu) correctly respect bindings config, but kimi-claw is the sole exception.

After source-code review, the root cause is confirmed as hardcoded session key and agent ID at multiple layers inside the connector, not a configuration issue on the user side.

Environment

Steps to reproduce

Attempt 1: bindings to route to independent agent

{
  agents: {
    list: [
      { id: "main", default: true, workspace: "~/workspace" },
      { id: "kimi", workspace: "~/workspace-kimi-group" }
    ]
  },
  bindings: [
    { agentId: "kimi", match: { channel: "kimi-claw" } },
    // Also tried accountId: "*"
    { agentId: "kimi", match: { channel: "kimi-claw", accountId: "*" } }
  ]
}

Result: Gateway restarted. All kimi-claw messages still enter agent:main. agent:kimi session never created.

Attempt 2: session.dmScope isolation

{
  session: {
    dmScope: "per-channel-peer"
  }
}

Result: Both TUI (webchat) and kimi-claw share the same session key agent:main:main. Sending /new does not create a new session key for kimi-claw.

Expected behavior

1. bindings should route kimi-claw channel messages to the specified agentId
2. session.dmScope should make kimi-claw sessions independent from other channels
3. Session key should reflect actual routing path (e.g. agent:kimi:... or agent:main:kimi-claw:...)

Actual behavior

• Session key: Always agent:main:main
• Agent: Always main
• Gateway log:

  [kimi-bridge] runtime dispatch completed session_class=main

OpenClaw version

2026.4.1

Operating system

Windows 10

Install method

npm global

Model

kimi-coding/k2p5

Provider / routing chain

OpenClaw → kimi-claw plugin → bridge WS → gateway → agent:main:main

Root cause analysis (with source references)

The following code references are from the distributed build under node_modules/kimi-claw/dist/.

After inspecting the locally installed [email protected] connector, the routing bypass appears to be hardcoded at three layers inside the connector:

Layer 1: ACP Bridge Core (dist/src/acp-gateway/bridge-core.js)

handleSessionPrompt, handleSessionNew, and handleSessionLoad all construct requests with a hardcoded session key:

const s = MAIN_SESSION_KEY;   // always "agent:main:main"

const c = {
  type: "req",
  method: d,   // "agent" or "chat.send"
  params: {
    agentId: this.agentId,   // from config.gateway.agentId, default "main"
    sessionKey: s,           // always MAIN_SESSION_KEY
    ...
  }
};

The bridge WS sends agent.prompt directly to the gateway, skipping the standard channel → binding → agentId routing pipeline that Telegram/Discord/WhatsApp channels go through.

Layer 2: Session Routing (dist/src/session-routing.js)

export const resolveImSessionScope = e =>
  asString(e.roomId)
    ? { sessionClass: "room", sessionKey: buildRoomScopedSessionKey(...) }
    : { sessionClass: "main", sessionKey: MAIN_SESSION_KEY };

While buildIsolatedSessionKey exists (supports channelSegment + accountId isolation), it is never invoked. The dmScope config is completely unreferenced in this module.

Layer 3: Inbound Handlers (dist/src/channel/inbound/handlers.js)

Every inbound handler hardcodes the session ID:

function handleSessionNew(e) {
  const o = MAIN_SESSION_KEY;   // non-configurable
  n.state.upsertSession(o, t);
  n.sendResult(n.id, { sessionId: o, ... });
}

function handleSessionPrompt(e) {
  const r = MAIN_SESSION_KEY;   // non-configurable
  ...
  await dispatchRuntimeReplyWithRoute({
    runtime: i.runtime,
    preparedPrompt: d,
    replyRoute: { sessionId: r, ... },  // always main
  });
}

No binding lookup is performed anywhere in the handler chain.

Layer 4: Static RPC Fallback (dist/src/service/static-im-rpc/client.js)

const STATIC_IM_RPC_AGENT_ID = "main";

Also hardcoded as a constant.

Impact and severity

Proposed fix directions

Option A: Respect bindings in bridge-core

Before constructing agentId / sessionKey, query OpenClaw's bindings config. If a channel: "kimi-claw" binding matches, route to the specified agentId instead of default main.

Option B: Dynamic bridge.agentId / bridge.sessionKey resolver

Add optional config fields:

{
  plugins: {
    entries: {
      "kimi-claw": {
        config: {
          bridge: {
            agentId: "kimi",           // override default "main"
            sessionKeyResolver: "isolated"  // or a function
          }
        }
      }
    }
  }
}

Option C: Enable dmScope in resolveImSessionScope

Route non-room DMs through buildIsolatedSessionKey when session.dmScope is set to "per-channel-peer" or "per-peer", making kimi-claw consistent with other channels.

Workaround

Currently no known workaround. The routing is hardcoded inside the compiled connector; no user-level openclaw.json configuration can override it.

Additional information

• Other channels tested (Telegram, Discord, Feishu) correctly create separate sessions under bindings + dmScope
• The resolveImSessionScope function contains buildIsolatedSessionKey but it is dead code — never called from any production path
• gateway.agentId in kimi-claw config defaults to "main" and is only used as the bridge WS client ID, not as a routing override

Checklist

• I have searched existing issues and this is not a duplicate
• I have reviewed the distributed connector source to confirm hardcoding
• I have provided reproduction steps with exact config snippets
• I have tested with other channels to confirm this is kimi-claw-specific

Note to maintainers: This is a connector-level architectural issue, not a user misconfiguration. Happy to provide further logs or test beta builds if needed.