CodeArts在jetbrains插件在2026.2中无法使用

在原来的对话里面，继续问答，没有反应了，但是新开的会话就能继续回复

晚上正常确认需求后让它开始编码就出去了，等回来一看并没有开始任务。输入框输入任何命令都没有反应，切换为自定义的DEEPSEEK同样没有反应，关闭软件重启软件依然无法使用。有人遇到同样的问题吗？

问题1.大模型没有kimi；问题2.终端调试的报错ERR不能复制问题

cid:link_0  上图为示例，下图为实例：这23个没有一个是mcp工具

VS code插件重复登录一直转圈，没有任何提示 

VS code插件有个问题：正在运行中的智能体，会突然的出现登录页，登录成功后才能继续进行。出现的时机为：会话进行到需求分析阶段，分析完成后等待输入新的指令时，过了不到半小时就出现登录。（此没有多次复现，所以不一定是必现的）

我自己发布的心愿墙，我都找不到了，不知道是审核通过了，还是没审核通过

从上一次更新后出现的，一直没有解决

下面是我提的两个码道心愿墙，我看到 支持glm5.2标准1m上下文的码道心愿墙也挺好的，快去点点支持，码道心愿墙:https://codearts.huaweicloud.com/portal/wish-wall?locale=zh-cn

cli在ubuntu下（客户端mobaxterm），不支持拷贝粘贴。ctrl+shift+c/v都不行，鼠标右键也不行。

消息排队模式消失问题反馈一、问题描述现象：在 CodeArts 对话界面中，当大模型正在执行任务（工具调用、代码生成等）时，用户再次发送消息的行为发生了变化：之前：新消息进入排队，待当前任务完成后依次处理现在：新消息立即发送，并中断（打断）正在执行的任务影响：长任务（多文件重构、全量测试、E2E 验证等）被用户中途追加的指令意外打断，需重新下达，严重影响开发效率与体验。二、环境信息项 值产品 华为云码道 CodeArts Agent当前版本 Vscode_26_7_2-1_0_0-1131718139432704版本;成时间 2026-08-07 03:09操作系统 Windows Server 2016+模型 GLM-5.2（huaweicloud-maas）配置目录 C:\Users\Administrator.codeartsdoer三、本地调查证据3.1 版本升级时间线（配置目录保留的三份 server_config）版本 构建号 生成时间Vscode_26_6_1 1122368600706432 2026-08-02 02:38Vscode_26_7_0 1129949886701568 2026-08-04 22:17Vscode_26_7_2（当前） 1131718139432704 2026-08-07 03:09排队行为消失发生在 8月4日 → 8月7日 的升级窗口（26_7_0 → 26_7_2）。3.2 内核来源配置文件 codearts_cli.json 与 ai-ide/codeagent.json 均声明 “$schema”: “https://opencode.ai/config.json”，说明 CodeArts Agent 基于 opencode 内核，消息调度策略由内核控制。3.3 运行时日志证据在 cli-data/log/ 的 kernel 日志中：每个工具调用的上下文均携带 abort:{} 字段，例如：codectx={sessionID:“ses_…”, abort:{}, messageID:“msg_…”, callID:“call_…”}这是 AbortController 机制——为每个正在执行的工具调用挂了可中断句柄。当用户发送新消息时，内核触发 abort 中断当前执行流，立即处理新消息。未检索到本地"消息排队"的运行时痕迹：搜索 message.queued | enqueue message | pending user message | 排队 | 入队 等关键词，均无本地消息队列相关记录。3.4 本地配置无调度开关已逐一读取 codearts_cli.json、cli-data/settings.json、ai-ide/codeagent.json 三个配置文件，均未发现控制消息调度策略（排队 vs 中断）的配置项。四、原因推断（供参考）⚠️ 以下为基于本地证据的推断，未对比旧版本内核行为，请贵团队核实。CodeArts Agent 内核（基于 opencode）在 26_7_0 → 26_7_2 升级中，将消息调度策略从"新消息入队等待当前任务完成"改为"新消息立即发送 + AbortController 中断当前任务"。该策略属内核编译期行为，无运行时配置开关，本地无法回退。五、期望行为希望恢复排队模式，或提供可选策略：优先方案：提供配置开关（如 messageQueue: “queue” | “interrupt”），让用户选择排队或中断模式次选方案：默认恢复排队模式（新消息入队，待当前任务完成后依次处理）补充建议：可同时支持，中断模式+排队模式，中断模式在 UI 上增加二次确认（“发送将中断当前任务，是否继续？”），避免误触

让CodeArt中的GLM5.2检查代码，给我删了整个代码库，几万行代码，一行都不剩，欲哭无泪，有赔偿么？？ 简直要崩溃！！谁来救救我！！！ 

现在排队好慢啊，什么情况，昨天还没问题

自带的终端有时候排版有问题