必须要有官方自己的交互式CLI/TUI，这是目前程序员的主要使用场景，越简单越好，最好跟Claude code，codex一样好用。

[aa27aa27]

如题

[haofeif]

Strong +1 for an official first-party interactive CLI/TUI. This would serve SSH, tmux, remote development, and terminal-oriented orchestration workflows where the Web UI is not suitable.

Suggested acceptance criteria:

• A persistent, attachable multi-turn mode (for example, dsh tui), not a new process per prompt.
• Streaming assistant output plus visible tool, reasoning, and subagent progress.
• Session resume/continue with stable session identifiers.
• Interactive permission prompts, cancellation, steering/follow-up input, and graceful exit.
• The same profiles, models, workspaces, tools, and sandbox policies as the Web UI.
• Reliable operation under tmux and SSH without requiring a browser or a per-session HTTP port.
• A stable machine-readable event/status channel alongside the TUI (ACP/JSON-RPC or JSON events), so external orchestrators can integrate without scraping ANSI terminal output.

The existing headless profile is useful but explicitly supports only one submitted task, while ACP is intentionally automation-only and omits interactive presentation. A first-party TUI would complement both interfaces rather than duplicate them, and would make DeepSeek Harness usable in the same terminal-first workflows as Claude Code, Codex, OpenCode, and Pi.

Integration interest from CLI Agent Orchestrator

CLI Agent Orchestrator (CAO) orchestrates heterogeneous, persistent CLI agents in tmux and currently supports providers including Claude Code, Codex CLI, GitHub Copilot CLI, Kimi CLI, Kiro CLI, OpenCode, Hermes, Cursor CLI, Antigravity, and Grok Build.

We would like to add DeepSeek Harness as a CAO provider when an official persistent CLI/TUI is available. CAO needs reliable multi-turn input, lifecycle state, final-output extraction, permission handling, cancellation, and graceful cleanup. A stable event/status contract alongside the human-facing TUI would let us integrate dsh robustly instead of depending on ANSI-screen scraping.

[wastee]

引入固定的 TUI 反而是更复杂。现在的 TUI 产品没有一个不是屎山

[haofeif]

同意，如果把固定 TUI 耦合进 Harness 核心，确实会增加复杂度。这里建议的是把 TUI 做成与 Web、ACP、headless 同级的可选 first-party profile/bundle，只消费 ctx.agents、session/event 和 approval 等服务。Agent loop、工具、存储和协议仍然保持插件化，用户可以不安装或替换这个 TUI。

对于 CLI Agent Orchestrator (CAO)，真正的机器集成契约仍应是稳定的 ACP/JSON-RPC 事件接口，而不是解析 ANSI 输出；TUI 只是供人在 SSH/tmux 中查看和交互的另一种界面。这样既不需要把 TUI 固定进核心，也能覆盖终端优先的开发工作流。

[weijiafu14]

官方第一方 TUI 这个诉求我不替官方回答。但有件事可能对 @haofeif 和 CAO 的接入评估有用：终端形态今天已经能用了，只是它来自社区而不是官方。

npm 上现成的两个：

• @deepseek-harness-tui/dsh-tui（0.9.3）
• @xmoon76/dsh-pi-tui（0.3.4）

都是 dsh plugin add 直装，跑在同一个 host 上，所以 profile、模型、工作区、工具、沙箱策略跟 Web 是同一套 —— 不是另起一个实现。

对着你那份验收清单，说一下我自己实际驱动过的部分（我在做一个兼容层，为了验证不得不把 TUI 在 tmux 里真跑了很多遍，断言读的是 $DSH_HOME/sessions/*.jsonl 里的工具结果，不是屏幕文字）：

• 持久可 attach 的多轮模式 ✅ —— 一个常驻进程，tmux 里 send-keys 连续多轮，不是每个 prompt 起一个进程。
• 流式输出 + 可见的工具进度 ✅ —— 真实模型轮次触发 MCP 工具调用，工具结果非错误地落进会话日志。
• 插件自带的全屏交互界面 ✅ —— 一个插件的管理界面（全屏 scene）在 TUI 里正常渲染并列出已连接的 server。
• /new 开新会话、会话之间隔离 ✅ —— 断言过 B 会话的标记不会漏进 A 的日志。
• tmux / SSH 下不需要浏览器、不需要每会话 HTTP 端口 ✅ —— 整个 E2E 就是这么跑的。

没验证过、以及确实没有的，说清楚免得白高兴：

• 会话 resume/continue、交互式权限弹窗、取消/中断这几条我没有在 TUI 上专门测过，不敢替它背书。
• CAO 真正需要的那条「人机界面之外的机器可读事件/状态通道」（ACP / JSON-RPC / JSON events）没有。 这是你们接入的真正卡点，不是 TUI 本身在不在。靠刮 ANSI 屏幕内容去集成是不可行的 —— 我自己写断言时就是因为屏幕文字不可靠，才改成读会话日志的。所以这一条我同意应该由官方定契约。

@wastee 说的那个顾虑我部分同意 —— 但现状是终端面已经有人做出来了，而且能用；真正缺的是官方的事件契约，那个东西不做，第三方 TUI 做得再好，外部编排器也接不进来。

（利益相关：我维护 pi2dsh，一个让 Pi 生态插件原样跑在 DSH 上的兼容层，上面这两个终端面是我的测试目标之一。这两个包不是我的。）