[BUG] - 不确定任务的后台请求

[fjqingyou]

提交前确认

• 我已经阅读了 README 常见问题
• 我已经升级到最新版本后复现过这个问题
• 我已经搜索过现有 issues，确认没有重复问题
• 我已经隐藏截图和日志中的 API Key、Token、Cookie 等敏感信息

问题描述

运行环境

• 使用方式: 桌面端 / CLI / 其他:
• 操作系统: Windows / macOS / Linux: macOS
• 系统版本: 例如 Windows 11 23H2 / macOS 15.4: macOS 14.2
• 桌面端版本: 例如 v0.1.8（设置页 -> 关于 中可查看）:0.3.1
• 安装来源: GitHub Release / 源码本地构建 / 其他: GitHub Release
• Bun 版本（CLI 问题填写，bun --version）:1.3.13
• Node 版本（CLI 问题填写，node --version）:v24.15.0

Provider / 模型配置

• API 提供商: 例如 Anthropic 官方 / OpenRouter / MiniMax / Kimi / Ollama:
• Base URL:
• 使用的模型:
• 相关配置截图:

复现步骤

1.同时存在多个项目文件夹
2.每个项目文件夹下都有若干个对话，有些对话甚至是没手动点击停止按钮（例如电脑崩溃重启）
3.重新启动桌面端，关闭所有对话选项卡，退出桌面端，再次重新打开桌面端并在任意项目文件夹下新建一个会话但是不进行任何输入。
4.预期本次启动没发起任何对话。不会发起任何 AI 大模型请求。但是实际上后台偷偷在努力干活，甚至因为项目太多，历史任务太多，完全没法知道是哪个任务在偷偷努力（毕竟穷举太麻烦）

是否稳定复现: 是 / 否 / 不确定 在我本机是稳定复现

错误信息与日志

在此粘贴错误信息和日志

截图或录屏

补充信息

我们知道，有些任务情景下，有可能甚至会自动24/7 干活的会更好。
但是，有需要处于一种可感知，能明确知道哪些任务在干活的好。
例如在实际活跃的任务列表中的任务名称左侧新增一个转圈动画表示该任务正在忙碌，我们就能知道实际是哪个任务在努力了

---

@dosubot

[dosubot]

感谢你提交这个问题！这确实是一个值得关注的行为。

根据代码分析，桌面端在启动时存在多个自动触发后台请求的机制：

1. Prewarm 会话初始化 — 当会话标签页变为活跃时，应用会自动发送 prewarm_session 消息来预热 CLI 子进程 [1]，这会在用户发送任何消息之前就启动后台处理 [2]。

2. 自动加载历史消息 — 连接到会话时会自动从持久化存储加载所有消息 [3]。

3. 持续轮询 — 侧边栏每 30 秒自动刷新会话列表，窗口获焦时也会触发刷新 [4]。对于有未完成任务的会话，还会以每 1000ms 的频率轮询任务状态 [5]。

4. 中断会话恢复 — PR fix: resume interrupted desktop turns after cli restart #468 引入了「CLI 重启后恢复中断的对话轮次」的逻辑 [6]，这可能是导致你观察到的"偷偷干活"的关键原因——之前未正常停止的会话在重启后可能会被自动恢复执行。

你提到的在活跃任务旁增加转圈动画的建议非常合理，目前在代码中没有找到类似的已有提案。这个可视化反馈确实能帮助用户感知哪些任务正在消耗 API 配额。

作为临时缓解措施，你可以尝试在重启桌面端前手动停止所有进行中的会话，避免它们在下次启动时被自动恢复。

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.