Bug: Bot (Feishu/Telegram/WeCom) sessions fail with 机器人对话处理失败: runtime host rejects explore sessions without a declared mode

[ser163]

Body

Summary

When a user messages the Feishu bot, the bot always replies Maka 暂时无法处理这条消息：机器人对话处理失败 ("Maka cannot process this message: bot conversation processing failed"). The platform connection itself is healthy (the message is received over the long-connection and the error reply is delivered), but no session is ever created in the runtime database.

Environment

• App: Maka desktop (packaged macOS app, arm64), version 0.2.0 (CHANGELOG marks 0.2.0 as "Unreleased")
• Electron 43.4.1 / Node 24.18.1 / Chrome 150.0.7871.224
• Bot platform tested: Feishu (@larksuiteoapi/node-sdk websocket long-connection)
• macOS 26.6

Root cause

1. The desktop bot session adapter (dist/main/runtime-host-bot-session-adapter.js, createRuntimeHostBotSessionAdapter.createSession) creates bot sessions with:

   deps.client.createSession({
     sessionId,
     workspace: target.workspace,
     name: input.name,
     labels: [...input.labels],   // e.g. ['bot', 'feishu']
     modelTarget: { kind: 'default' },
     permissionMode: 'explore',   // ← no `mode` is passed
   });

2. The runtime host's session catalog prepareCreate (packages/runtime-host/src/server/session-catalog-coordinator.ts) added a new requirement:

   const mode = input.mode === undefined ? undefined : sessionStartModeSpec(input.mode);
   if (mode === undefined && input.permissionMode === 'explore') {
     throw new SessionOperationFailure('invalid_request', 'Session creation requires a declared mode for explore permission');
   }

   The bot adapter passes permissionMode: 'explore' but never passes mode, so every bot session creation throws.

3. The thrown message Session creation requires a declared mode for explore permission does not match any category in generalizedErrorMessage (timeout / rate-limit / 401 / 403 / 5xx / network), so the bot surfaces the generic fallback 机器人对话处理失败 — making it look like a Feishu/connection/credentials problem during debugging.

4. Desktop chat sessions are unaffected because they use permissionMode: 'ask' (from chatDefaults.permissionMode), which does not trigger the check. Only bot sessions (hardcoded to explore) hit it.

Impact

• All bot channels that create sessions with permissionMode: 'explore' cannot start conversations.
• The bot shows a healthy connection (message received, reply sent) but every conversation attempt fails with the generic error; no session appears in the runtime DB.
• SESSION_START_MODE_SPECS currently only defines deep_research, so there is no valid mode a bot could pass to satisfy the check anyway.

Suggested fix (pick one)

• A (recommended): Exempt bot-labeled sessions in prepareCreate, since bots are intentionally read-only/explore:

  if (mode === undefined && input.permissionMode === 'explore' && !(input.labels?.includes('bot'))) {

• B: Make the bot session adapter pass a declared mode (e.g., add a proper bot/explore entry to SESSION_START_MODE_SPECS and pass it in createSession).

Verified workaround

Locally patched option A into the packaged app's app.asar (runtime-host session-catalog-coordinator.js); the Feishu bot then created sessions and replied correctly. This confirms the diagnosis.

Reproduction steps

1. Configure a bot channel (e.g., Feishu app with websocket long-connection) and enable it.
2. Send a message to the bot.
3. Observe the bot replying Maka 暂时无法处理这条消息：机器人对话处理失败.
4. In the runtime DB, no session row is created for the bot conversation.

Expected behavior

Bot messages create a session and receive a normal agent reply (as they did before the mode requirement was introduced).

[ser163]

Closed: 将改用 Bug 报告表单重新提交以自动附加 bug 标签（API 创建无法打标签）。