CloudCLI UI 如何给 Claude 会话设置定时发送的消息并确认它按时触发-开发者社区

CloudCLI UI 如何给 Claude 会话设置定时发送的消息并确认它按时触发

【免费下载链接】claudecodeuiUse Claude Code, OpenCode, Cursor CLI, and Codex on mobile and web with CloudCLI (aka Claude Code UI). CloudCLI is a free open source webui/GUI that helps you manage your Claude Code session and projects remotely.项目地址: https://gitcode.com/GitHub_Trending/cl/claudecodeui

场景是：你已经有一个 CloudCLI（Claude Code UI）里的 Claude Code 会话，想把一条消息留给它、让它在稍后指定时间自动发出并执行，而不是现在立即发送。CloudCLI 内置了 scheduled messages 功能：在聊天输入框上直接指定发送时间，服务端把消息存入数据库，到点后由服务端定时器为这个会话发起一次聊天回合——不需要浏览器开着，也不需要你再手动操作。

本文的主路径是纯 UI 操作，另附服务端轮询机制说明和 REST 接口核对方式，用于确认消息确实按时触发。

准备条件

一个已运行的 CloudCLI 服务端。自托管方式（见 docs/README.md 的 Quick Start）要求 Node.js v22+，然后执行：

npx @cloudcli-ai/cloudcli

或全局安装后使用：

npm install -g @cloudcli-ai/cloudcli cloudcli

启动后打开http://localhost:3001，进入某个已存在的会话。调度接口会校验sessionId，指向不存在的会话会返回 404（SESSION_NOT_FOUND），所以目标会话必须是 CloudCLI 已经发现的会话。

在聊天输入框上调度一条消息

打开目标会话，在底部输入框里输入要稍后发送的消息内容，不要点发送。
点击发送按钮旁边的时钟图标按钮。该按钮的 aria-label 是 “Schedule this message”（见 ScheduleMessagePopover.tsx）。
弹出菜单标题为 “Send later”，提供四档快捷时间：In 15 minutes、In an hour、In 8 hours、Tomorrow；每档会显示按当前时间换算后的具体时刻。
也可以在下方 “Or pick a time” 处用datetime-local控件挑选精确到分钟的时间，然后点击Schedule确认。

时间选择时由浏览器按本地时区解析成一个绝对时刻再提交，服务端存的是这一个明确的时间点——之后你换到另一台设备或另一个时区，到点触发不会跟着漂移（这一点在 ScheduleMessagePopover.tsx 的注释和 scheduled-messages.service.ts 中都有说明）。

判断调度是否成功

成功后有两个可见结果：

输入框被清空。调度成功等价于一次“发送”，消息已经离开输入框（见 ChatInterface.tsx 中handleScheduleMessage的处理）。
输入框上方出现一条 “Scheduled for <时间>” 的待发送卡片。这张卡片由 ScheduledMessageList.tsx 渲染，只展示pending和failed两种状态的消息。

调度时当前输入框里选择的模型、effort、permissionMode 会作为options一起存入，到点触发时原样带回去（{ model, effort, permissionMode }，见 ChatInterface.tsx；测试用例 scheduled-messages.test.ts 中 “the composer settings it was scheduled with travel with it” 覆盖了这一点）。

如果只是想确认服务端已收到，可以用 REST 接口核对（接口定义见 scheduled-messages.routes.ts）：

GET /api/scheduled-messages?sessionId=<sessionId>— 返回该会话的全部调度消息，数组中每条含id、sessionId、content、scheduledFor、status、failureReason等字段；
GET /api/scheduled-messages（不带参数）— 返回当前用户名下所有pending消息。

这些路由挂载在需要登录鉴权的路径下（server/index.ts 中app.use('/api/scheduled-messages', authenticateToken, ...)），请求要带浏览器会话同一套凭据；前端统一以Authorization: Bearer <token>附带，见 api.ts。响应外层是{ success: true, data: [...] }，前端读取的就是data数组。

到点后发生了什么

确认“按时触发”之前，先了解服务端的触发机制（scheduled-message-dispatcher.service.ts）：

服务端以30 秒为周期轮询数据库（POLL_INTERVAL_MS = 30_000），找出所有到期的pending消息；
到期消息在同一条数据库事务里被“认领”为sent，再逐个执行，因此重叠的轮询不会把同一条消息发两次；
触发不依赖浏览器：调度消息发起的 run 以connection: null运行，即使没有任何浏览器连着这个会话也会照常执行（01-websocket-transport.md 中明确提到 “a scheduled message firing with no browser attached”）；
如果到点时该会话正好有一个进行中的 run，进行中的 run 会被中断（interruptActiveRun: true），定时消息按预定时间落地，而不是被记成“没发——会话忙”；
如果到点时服务端没在运行，消息不会丢：定时表在数据库里，服务恢复后的第一次轮询会把错过的消息补发。

验证消息确实按时发出

看会话记录。过了选定时间（加上至多 30 秒的轮询间隔）后，该会话的 transcript 中应出现这条消息作为用户消息，并跟随模型的回复；你不需要开着这个标签页，重新打开会话即可看到已执行的记录。
查状态字段。用上面的GET /api/scheduled-messages?sessionId=<sessionId>查看status：正常流程是pending→sent。
失败会显式留痕。若触发时 run 未能启动（例如会话已删除、provider 不可用）或启动后失败，服务端不会静默丢弃，而是把状态改为failed并写入failure_reason（截断到 500 字符）；此时输入框上方会出现一条 “Not sent — <原因>” 的红色卡片，点 × 可关闭（关闭走同一取消接口，状态变为cancelled）。
取消待发消息。在 “Scheduled for …” 卡片上点 ×，即调用DELETE /api/scheduled-messages/<id>。已发出（sent）的消息不允许再取消，会返回 409（SCHEDULED_MESSAGE_NOT_PENDING）；已取消的消息到点不会再发（对应测试 “a cancelled message never fires”）。

限制与边界

以下约束来自服务端校验与实现，调度前值得注意：

消息内容必须非空，且不超过 100,000 字符（否则 400：CONTENT_REQUIRED/CONTENT_TOO_LONG）；
scheduledFor必须是可解析的时间戳，且距当前不超过365 天（否则 400：SCHEDULE_TOO_FAR_AHEAD）；
时长按分钟粒度选择（快捷项为 15 分钟/1 小时/8 小时/明天，自定义项为分钟级选择器），而服务端 30 秒轮询一次，所以实际发出时刻会在选定时间之后至多约半分钟内；
触发会中断该会话上正在进行的 run——如果你希望某个长任务不被打断，避开它的运行时间窗来设时间。