是否可以考虑添加移动端通信 || Can you consider adding mobile communication?

[lisabiya]

What feature would you like to see?

是否可以考虑参考openclaw添加一个移动端通信的功能
有时候不在电脑端但是需要了解agent当前的进度或者给他下发一些新的需求
对接三方或者自建app都行。
自建app或者接入kimi app里面是最合适的
可以自定义一些功能，例如

• 文件的传输
• 语音模块的转录
• 快捷键的设计

可以很大程度增加kimi的用户粘度，形成个人工作站绑定kimi
后面也可以直接托管用户的kimi code，降低使用门槛，实现用户私有工作空间与kimi的强绑定。

Additional information

No response

---

What feature would you like to see?

Is it possible to consider adding a mobile communication function by referring to openclaw?
Sometimes you are not on the computer but you need to know the current progress of the agent or issue some new requirements to him.
You can connect to third parties or build your own app.
It is most suitable to build your own app or connect it to kimi app
Some functions can be customized, such as

• File transfer
• Transcription of speech modules
• Design of shortcut keys

It can greatly increase kimi's user viscosity and form a personal workstation bound to kimi.
You can also directly host the user's kimi code later, lowering the threshold for use and achieving strong binding between the user's private workspace and kimi.

Additional information

No response

[albertwyjoy-bit]

可以看下这个#980
集成飞书 SDK，基本上都是Kimi CLI自己开发的

---

You can take a look at this #980
Integrate Feishu SDK, which is basically developed by Kimi CLI itself

[lisabiya]

哈哈，很棒的实现，主要我的应用场景
1 是否支持session的指定，即 kimi --session abc123，因为有可能我在agent工作期间离开了，期望在移动端继续这个session上下文
2 编程方向，kimi会有授权请求，这个是否能在移动端兼容
3 您写的三方实现是否会持续更新，这样是否会耗费太多精力而没有正向收益

所以我个人觉得，这个需求，扩展来看是个很好的方向，未来应该是会有企业跟进，openlaw是个很好的例子，如果能进一步降低使用门槛，例如kimi直接托管用户工作空间，还是很有潜力的

---

Haha, great implementation, mainly for my application scenarios

1. Does it support the specification of session, that is, kimi --session abc123? Because it is possible that I left while the agent was working and I hope to continue this session context on the mobile terminal.
2. In the programming direction, Kimi will have an authorization request. Is this compatible with the mobile terminal?
3. Will the third-party implementation you wrote be continuously updated? Will this consume too much energy without any positive benefits?

So I personally think that this demand is a good direction in terms of expansion. There should be companies to follow up in the future. Openlaw is a good example. If the threshold for use can be further lowered, for example, Kimi directly hosts user workspaces, there is still great potential.

[lisabiya]

所以如果官方评估后觉得值得做，能由官方实现与维护是最好的结果🤣

---

Therefore, if the official evaluation determines that it is worth doing, it would be the best result if it can be implemented and maintained by the official🤣

[xiaoju111a]

哈哈，很棒的实现，主要我的应用场景 1 是否支持session的指定，即 kimi --session abc123，因为有可能我在agent工作期间离开了，期望在移动端继续这个session上下文 2 编程方向，kimi会有授权请求，这个是否能在移动端兼容 3 您写的三方实现是否会持续更新，这样是否会耗费太多精力而没有正向收益

所以我个人觉得，这个需求，扩展来看是个很好的方向，未来应该是会有企业跟进，openlaw是个很好的例子，如果能进一步降低使用门槛，例如kimi直接托管用户工作空间，还是很有潜力的

Haha, great implementation, mainly for my application scenarios

1. Does it support the specification of session, that is, kimi --session abc123? Because it is possible that I left while the agent was working and I hope to continue this session context on the mobile terminal.
2. In the programming direction, Kimi will have an authorization request. Is this compatible with the mobile terminal?
3. Will the third-party implementation you wrote be continuously updated? Will this consume too much energy without any positive benefits?

So I personally think that this demand is a good direction in terms of expansion. There should be companies to follow up in the future. Openlaw is a good example. If the threshold for use can be further lowered, for example, Kimi directly hosts user workspaces, there is still great potential.

kimi --session abc123这个是支持的，目前 Kimi CLI 的 session 是存储在本地文件系统中的（通常在 ~/.kimi/sessions/ 目录下）

[lisabiya]

是的，我的意思的OKbot 里面的移动端实现应该是没有支持选择某个session从而实现继续沟通的，所以要么能不能请大佬评估下是否实现下😂，或者看看官方有没有意愿🌹O(∩_∩)O

---

Yes, what I mean is that the mobile implementation in OKbot should not support selecting a session to continue communication, so you can either ask the boss to evaluate whether it can be implemented😂, or see if the official is willing🌹O(∩_∩)O

[albertwyjoy-bit]

Q： 是否支持session的指定，即 kimi --session abc123，因为有可能我在agent工作期间离开了，期望在移动端继续这个session上下文
A：支持的，因为OKbot 是基于 Kimi Code CLI 的扩展项目，在原有 CLI 交互方式上增加了移动端支持，底层的逻辑入Runtime、Agent、Session、OAuth等都是复用的，可以看成在Kimi CLI增加了新的UI适配（但逻辑更复杂点）。

Q：编程方向，kimi会有授权请求，这个是否能在移动端兼容
A：OKbot目前默认时强制SOLO模式，适配授权需要额外开发。

Q：三方实现是否会持续更新，这样是否会耗费太多精力而没有正向收益
A：现在基本上是Kimi CLI来写，但是涉及飞书移动端还得测试一下，未来模型越来越强我觉得耗费的精力会越来越小。

目前支持以下特性：

特性	说明
📱 移动端扩展	在原有 CLI 基础上增加飞书移动端交互，手机即可操控 PC
🔗 完全复用	100% 复用 Kimi CLI 的 Session 机制和 OAuth 鉴权，无需额外配置
🔄 跨端接续	支持 CLI ↔ 飞书无缝切换，任务随时随地带走
🛡️ 零冲突	可使用 python -m kimi_cli 运行，不与官方 Kimi CLI 冲突
⚡ YOLO 模式	强制开启，工具调用自动批准，无需人工确认
🔄 动态 Skills	支持运行时热更新 Skills，无需重启服务
🔌 实时通信	基于飞书 WebSocket 长连接，消息实时双向传输

跨端 Session 接续

OKbot 支持无缝切换 CLI 和飞书对话，随时随地继续之前的会话。

飞书端视角（移动端接续 Session）：

---

Q: Does it support session specification, that is, kimi --session abc123? Because it is possible that I left while the agent was working and I hope to continue this session context on the mobile terminal.
A: Yes, because OKbot is an extension project based on Kimi Code CLI. It adds mobile support to the original CLI interaction method. The underlying logic including Runtime, Agent, Session, OAuth, etc. are all reused. It can be seen as adding new UI adaptation to Kimi CLI (but the logic is more complicated).

Q: In the programming direction, Kimi will have an authorization request. Is this compatible with the mobile terminal?
A: OKbot is currently in forced SOLO mode by default, and adaptation authorization requires additional development.

Q: Will the third-party implementation be continuously updated? Will this consume too much energy without any positive benefits?
A: Now it is basically written by Kimi CLI, but it needs to be tested when it comes to Feishu mobile terminal. In the future, as the model becomes more powerful, I think the energy consumed will become smaller and smaller.

Currently the following features are supported:

Features	Description
📱 Mobile terminal extension	Add Feishu mobile terminal interaction based on the original CLI, and the mobile phone can control the PC
🔗 Full Reuse	100% reuse of Kimi CLI's Session mechanism and OAuth authentication, no additional configuration required
🔄 Cross-end connection	Support CLI ↔ Feishu seamless switching, take tasks away anytime and anywhere
🛡️ ZERO CONFLICT	Can be run with python -m kimi_cli and does not conflict with the official Kimi CLI
⚡ YOLO Mode	Forced on, tool calls are automatically approved without manual confirmation
🔄 Dynamic Skills	Supports hot update of Skills during runtime without restarting the service
🔌 Real-time communication	Based on Feishu WebSocket long connection, real-time two-way transmission of messages

Cross-end Session Continuation

OKbot supports seamless switching between CLI and Feishu conversations, allowing you to continue the previous conversation anytime, anywhere.

Feishu client perspective (mobile client continues Session):

[lisabiya]

继Claude之后，ChatGPT 也支持 移动端控制了 kimi 的移动端是否也计划支持下 kimi code

[Gingiris]

这个方向我觉得值得做，而且它不只是“多一个端”，本质上是在补 agent 使用里的一个高频断点：人离开电脑之后，任务还在跑，但上下文和控制权断了。

如果要把这件事做得既有产品价值、又有传播价值，我会建议第一版先别铺太大，而是优先把 3 个最容易形成留存的场景做扎实：

1. 任务进度回流
   先解决“我不在电脑前，但我需要知道它跑到哪了、卡在哪了、要不要我处理”。很多人真正焦虑的不是手机上不能写代码，而是离开电脑后完全失联。

2. 审批 / 接管的最短路径
   如果移动端只能看、不能在关键时刻 approve / reject / 补一句新需求，价值会打折。哪怕第一版只支持几个关键动作，也比做一个只能围观的移动端更实用。

3. session 接续认知成本要低
   用户不应该理解一堆 runtime / session 机制，理想体验应该是“我在电脑上开的任务，手机点进来就能继续看、继续管”。文档和 demo 也最好围绕这个场景讲，而不是先讲架构。

从冷启动和传播角度，这个功能其实有一个很具体的记忆点：
“Agent 在电脑上跑，我出门后还能在手机上接着管。”

这个表述会比“支持跨端通信”更容易让用户秒懂，也更适合写 release note、做首页动图或者短视频 demo。

如果后续真推进，我会建议先做一个 30 秒案例把价值讲透：
电脑上启动长任务 -> 人离开工位 -> 手机收到进度/审批提醒 -> 手机上补一句新需求 -> 回到电脑继续同一个 session。

这种 case 一旦跑顺，传播价值会比单纯讲功能列表强很多。

---

I think this direction is worth pursuing, and it is not just "one more terminal". It is essentially filling a high-frequency breakpoint in agent use: after the person leaves the computer, the task is still running, but the context and control rights are broken.

If you want to make this thing have both product value and communication value, I would suggest that the first version should not be too big, but give priority to the three scenes that are most likely to be retained:

1. Task progress reflow
   First solve the problem of "I am not in front of the computer, but I need to know where it has gone, where it is stuck, and whether I need to deal with it." What many people are really anxious about is not that they cannot write code on their mobile phones, but that they are completely disconnected after leaving the computer.

2. Shortest path to approval/takeover
   If the mobile terminal can only view and cannot approve/reject/add new requirements at critical moments, the value will be discounted. Even if the first version only supports a few key actions, it is more practical than making a mobile version that can only be watched by onlookers.

3. The cognitive cost of session connection is lower
   Users should not understand a bunch of runtime/session mechanisms. The ideal experience should be "I can continue to watch and manage the tasks I open on the computer by clicking on them on my mobile phone." It is also best to focus the documentation and demo around this scenario, rather than talking about the architecture first.

From the perspective of cold start and propagation, this function actually has a very specific memory point:
“The Agent runs on the computer, and I can continue to take care of it on my mobile phone after I go out.”

This statement will be easier for users to understand in seconds than "support cross-end communication", and is more suitable for writing release notes, making homepage animations, or short video demos.

If it really goes forward, I would suggest doing a 30-second case to explain the value thoroughly:
Start a long task on the computer -> the person leaves the workstation -> receives the progress/approval reminder on the mobile phone -> adds a new requirement on the mobile phone -> returns to the computer to continue the same session.

Once this kind of case runs smoothly, the communication value will be much stronger than simply talking about the function list.