[Bug]: 本地 ACP 客户端未设置子进程工作目录，导致只认进程 cwd 的 Agent（如 CodeBuddy cli）在错误目录启动

[liao-zh]

Summary

能成功将codebuddy cli添加为acp，但使用时发现工作路径不对，下面是AI整理的issue建议

---

环境

平台：Windows 11，BitFun 桌面版（版本：v0.2.19-nightly.20260826）

ACP Agent：CodeBuddy Code CLI v2.140.0（npm 最新版，@tencent-ai/codebuddy-code），原生支持 --acp （https://www.codebuddy.ai/docs/zh/cli/acp）

现象

在工作区下通过菜单新建 CodeBuddy ACP 会话后，Agent 自述的工作目录是
C:\Users\<username>\AppData\Local\BitFun（即 bitfun-desktop.exe 的安装目录），而不是当前工作区，
所有相对路径操作都落在错误位置。

根因分析

两个因素叠加：

1. BitFun 本地路径未设置子进程 cwd（本次问题的主要可控点）

   src/crates/interfaces/acp/src/client/manager.rs 中 start_local_transport 通过
   create_tokio_command(...) 启动 agent，但全程没有调用 .current_dir(...)。
   agent 子进程继承 bitfun-desktop.exe 的启动目录（安装目录）。
   而 远程 SSH 路径已有对应处理（render_remote_client_command 会生成
   cd <workspace> && <command>），本地路径缺少同样的保证。

   BitFun 当前依约按 ACP 规范发送了 NewSessionRequest { cwd: <工作区> }，
   所以对遵循协议的 agent（claude-code / codex / opencode / dsh / omp 预设）一切正常；
   问题只在 agent 不读取该字段时暴露。

2. CodeBuddy 的 ACP 服务端忽略 session/new.cwd（agent 侧缺口，但无需等待其修复）

   明确传入 cwd 仍返回进程启动目录 → CodeBuddy 获取会话根目录的唯一来源是自身进程 cwd。

为什么只改 BitFun 一侧即可修复，不必等 CodeBuddy 改

• CodeBuddy 使用的唯一来源是「agent 进程自身的启动目录」。若 BitFun 在本地 spawn 时
  将子进程 current_dir 设为当前会话的工作区路径，则该来源恰好等于工作区，
  CodeBuddy 即可正确落位——agent 是否遵循协议字段不再有影响。
• 对现有内置预设零回归：claude-code/codex/opencode/dsh/omp 目前读取 session/new.cwd
  建会话；修复后请求 cwd 与进程 cwd 变为同一个值，从「两个来源仅信其一」变为「两处一致」，
  反而消除了潜在歧义（agent 内部相对路径解析、项目级配置查找、git 检测更可预测）。
• 与远程 SSH 分支对称：远端已是 cd <workspace> && ...，本次只是把同一约定补齐到本地分支。
• 符合通用客户端实践（如 Zed 以项目根目录作为 agent 扩展命令的启动目录），
  使任何「只认进程 cwd」的第三方 CLI 无需改造即可接入，提升的是对整个 ACP 生态的容错性。

建议修复

start_local_transport 增加工作区参数（start_client_connection /
open_transport_for_connection 已持有 workspace_path），spawn 前设置：

if let Some(workspace_path) = resolved_cwd {
    command.current_dir(workspace_path);
}
// workspace_path 缺失时维持现状（std::env::current_dir() 兜底）

Area

Desktop app

Reproduction or evidence

见上

Environment, if relevant

No response