Bot bridge: mobile session management for all IM channels (conversation continuity, chat commands, per-conversation working directory) #2325

Problem

Users of the bot bridge (WeChat, Telegram, Feishu, WeCom, Discord, DingTalk, QQ, Slack) cannot tell — let alone control — where a conversation works. A common first impression on WeChat: "I can't figure out how to point a conversation at a folder. Can it work like a local session — start inside a folder and understand its context?"

Looking deeper, the gap is structural, not just the folder. The bridge today is a dumb pipe: a message goes in, a reply comes out. Everything around it is missing:

• No conversation continuity: the conversation → session mapping in bot-incoming-main.ts (${platform}:${chatId} → sessionId) is an in-memory Map. Restart Maka and every bot conversation silently starts over in a fresh session.
• No per-conversation working directory: bot sessions are created with resolveBotCreateTarget() → { cwd: await projectRoot.current() } — the project last selected on the desktop, shared by every conversation on every channel. There is no way to bind a conversation to a folder, or even to see which folder it works in.
• No management commands: only a bare restart/help keyword. No way to list conversations, start a new one, stop a running turn, or check status. (/stop doesn't exist at all.)
• Hardcoded explore permissions: bot sessions are forced to permissionMode: 'explore', so the agent cannot take write actions from any IM channel.

The issue is not "how to pick a folder" — it's that IM conversations are not a session-management surface. Local sessions get a project picker, a sidebar, model selection, and permission prompts; a bot conversation gets none of that. Compare OpenClaw's Control UI and Hermes' chat commands: both expose conversation management (resume, new, stop, status, working directory, approvals) over IM.

Desired outcome

Turn the bot bridge into a mobile session-management surface, uniform across all connected channels, with the local session machinery as the single implementation:

• Conversation continuity (P0) — persist the conversationKey → sessionId mapping (Hermes sessions.json / PawWork SessionPointers / OpenClaw SQLite are the reference shapes). A conversation resumes its session across restarts, and any directory/model attributes survive with it.
• Chat command framework (P0) — /new (fresh session), /sessions (list/resume), /stop (interrupt the running turn), /status (current session, working directory, model). Implemented once in the platform-agnostic bot layer (bot-incoming-main.ts), so every channel — WeChat, Telegram, Feishu, WeCom, Discord, DingTalk, QQ, Slack — inherits it.
• Per-conversation working directory (P0) — the directory is a session attribute, exactly like a local session: chosen at creation (defaulting to the configurable default working directory, see Add a configurable default working directory for sessions without a specific project #2322), changeable from a desktop-side conversation management entry (folder picker), visible in /status and in the sidebar grouping. The bridge only passes the directory through at session creation — it does not implement any folder logic of its own.
• Permission fix + in-chat approval (P0) — bot sessions follow the global default permission mode (auto/bypass) instead of being forced to explore. In auto mode, permission requests render as chat text and are answered by keywords (PawWork's blocker pattern: 是/好/允许/同意). Native buttons (Hermes send_exec_approval) are a later iteration, on channels that support them.
• Later directions — inbound media enrichment (image → vision, voice → STT; both Hermes and OpenClaw have reference implementations). Model selection is deliberately out of scope (covered by subagent capability).

Alternatives or workarounds

No workaround today. We compared three open-source bridges:

Conclusions:

1. Keep the bridge thin — adapters normalize I/O only; sessions, directories, commands, and permissions live in the core (all three projects agree).
2. Persist the conversation mapping with a deterministic key — restart recovery becomes free.
3. Bind the directory at session creation and persist it as a session attribute — never resolve it per message, and never build a separate bot-side directory model. Maka's existing seam (resolveBotCreateTarget) is the single place to extend.
4. Caveats are per-channel: PawWork's missing directory param silently parked every IM session in ~/PawWork. WeChat iLink has no server push (replies echo context_token) and one credential = one poller (409) — commands must work as replies to inbound messages; other channels bring their own constraints (e.g. Telegram's single-getUpdates consumer).