Have something to say?

Tell us how we could make the product more useful to you.

Alma causes high CPU and max fan speed after recent Computer Use update

I’m seeing a severe fan/noise issue after recent updates related to Computer Use / Activity Recorder in Alma 0.0.792 on macOS 26.5 (Apple M1 Pro). The main hot process is Alma Helper (Renderer) (PID 99511), which peaked around 38%~46% CPU, while Alma Helper (GPU) (PID 99361) also stayed high around 14%~17% CPU. At the same time, WindowServer was consistently elevated (~33%~44% CPU), and the fan ramped up to maximum. After quitting Alma completely, Alma processes disappeared and the fan noise gradually dropped, which strongly suggests Alma is the trigger. A stack sample of the GPU process shows heavy activity in QuartzCore, IOSurface, Metal, CA::Transaction::commit(), and surface copy/commit paths; Alma also loads ScreenCaptureKit and ReplayKit. This looks like a continuous screen-capture / visual-analysis / preview-render pipeline, even when Activity Recorder appears to be turned off.

Mark Li 32 minutes ago

💡

Feature Request

全屏模式下通知弹窗干扰 & 缺少 macOS 通知开关

分类: Feature Request 内容: 问题描述 全屏使用其他应用时(如看视频、写代码、演示),Alma 的通知 toast 会弹出并打断全屏体验。而且 macOS 系统通知设置里找不到 Alma 的选项,无法通过系统级方式关闭。 原因分析 Alma 的通知是应用内 overlay/toast,不是 macOS 原生通知,所以不会出现在系统通知中心,用户无法通过 macOS 设置关闭。 建议方案 增加 general.suppressNotificationsWhenFullscreen 配置项,全屏时自动静默 或增加一个全局的「通知开关」toggle,让用户手动控制 或检测到全屏应用时,将通知改为静默写入日志而非弹窗 当前版本 v0.0.783

西瓜 5 days ago

💡

Feature Request

alma selfie take 和 alma image generate 硬编码 Google provider,忽略 image.provider 配置

描述: 复现环境:macOS,Alma 最新版,已通过 Codex OAuth 插件登录 ChatGPT 账号。 配置状态: image.provider 已设为 plugin:openai-codex-auth:openai-codex image.defaultModel 已设为 plugin:openai-codex-auth:openai-codex:gpt-image-2 gpt-image-2 已在 plugin-provider-models 中注册 Codex OAuth token 正常可用(chat 模型工作正常) Bug 表现: 执行 alma image generate "prompt" --model "plugin:openai-codex-auth:openai-codex:gpt-image-2" 时,报错 No enabled Google provider with API key found。alma selfie take 同样问题。 预期行为:image 命令应读取并遵循 image.provider 配置,使用已配好的 provider 生图。 实际行为:二进制层面硬编码了 Google provider,完全无视用户配置。 影响:已配置好 Codex OAuth 的 gpt-image-2 但完全无法通过 Alma CLI 调用生图。

Polinao Xppa 7 days ago

🐛

Bug Reports

带工具调用的流式回复在切换对话后消失或显示为空白

问题现象: 在一个包含工具调用/长输出的对话里,助手明明已经执行了操作并产生了最终回复,但聊天界面显示为空回复,或者切换到其他对话再切回来后,这条回复直接消失。 复现条件(高概率): 在当前会话里发送一个需要工具执行的请求 例如:让助手读取网页、抓取内容、查询本地技能,并整理成表格 助手开始执行工具调用,并产生较长的中间输出 在助手回复过程中,用户切换到其他对话,或者会话列表/消息列表发生刷新 再切回原对话 实际结果: 有时会看到一个“空白回复气泡” 有时中间工具过程存在,但最终正文回复不显示 有时刚才还能看到回复,切换对话后再回来,这条回复消失 重新进入会话后,消息列表中似乎没有这条最终回复,像是没有持久化成功,或被前端状态覆盖 预期结果: 助手的最终回复应该稳定显示 即使用户切换对话再回来,已生成的回复也应从服务端/本地缓存正确恢复 工具输出与最终正文应正确合并或按顺序展示,不应出现空消息气泡或消息丢失 额外线索: 问题更容易出现在“工具调用 + 长输出 + 流式回复 + 中途切换会话”组合下 从行为上看,像是: 1)前端流式消息临时状态未持久化 2)工具消息和最终 assistant 消息合并逻辑异常 3)切换会话后重新拉取消息列表时,本地临时消息被覆盖 4)最终 assistant message 已生成但未正确入库/未被前端渲染层识别 建议排查方向: assistant final message 的创建、落库、message id 绑定流程 tool message 与 final assistant message 的关联关系 会话切换时的本地状态清理/重建逻辑 websocket/stream 中断后的补拉与 reconcile 逻辑 空 content message 是否被错误渲染成正常消息气泡

Obet Sajjad 7 days ago

💡

Feature Request