Web UI 与桌面端都没有直接查看或复制当前会话 id 的入口（0.2.0-rc.2）

[YOUKNOWWHOOO]

Web UI 与桌面端都没有直接查看或复制当前会话 id 的入口（0.2.0-rc.2）

环境

• 操作系统：Windows 11 家庭版 中文版 25H2，版本 10.0.26200，内部版本 26200.8246，64 位，AMD64
• 处理器 Intel Core Ultra 5 336H（12 核），内存 31.5 GB；区域与语言 zh-CN，时区 China Standard Time
• Node.js v26.9.0，npm 12.0.2（Node 由 fnm 1.39.0 管理）；PowerShell 7.6.6
• @deepseek-ai/dsh 0.2.0-rc.2，经 npx @deepseek-ai/dsh web 启动，Web UI 监听 127.0.0.1:3080，profile 为 web，bundles 为 @deepseek-ai/dsh-base + @deepseek-ai/dsh-web-app
• 官方桌面端：DeepSeek Harness 0.2.0-rc.2，per-user 安装于 %LOCALAPPDATA%\Programs\DeepSeek Harness，自带 profile 为 desktop，默认监听 127.0.0.1:19387；观测时未运行
• 观测时间：2026-09-30（CST，UTC+8）

现象

Web UI 与官方桌面端都没有直接查看或复制当前会话 id 的入口：侧栏会话行与悬停卡只显示标题，会话头部不显示 id，设置页、命令面板与快捷键清单里没有与它相关的项，浏览器地址栏也不含它。

证据一：侧栏与悬停卡不显示、也不复制 id

dsh-client-ui-workspace/lib/client.js：

• :1121-1124 的行标题函数为 return node.blank ? t("session.new") : node.title || t("session.untitled");，即空标题回落为「未命名」，不回落为 id
• :1680 的悬停卡复制文本为 copyText: row.blank || row.title === "" ? void 0 : row.title，复制的是标题
• :1373 的工作区行复制文本是 cwd

证据二：会话头部默认不显示 id，只在边界情形下显示

• dsh-client-ui-conversation/lib/client.js:16468-16499 的头部面包屑逐段渲染标题，末段显示 summary.displayTitle；仅当 ancestry.length === 0（:16496，即该会话不在祖先链投影里）时才回落显示 sessionId（:16498 的 children: sessionId）
• summary.displayTitle 的来源 displayTitleOf（dsh-api-session-controller/lib/client.js:3052-3059）按「durable 标题 → 工作目录 basename → 原始 id」回退；本机正常会话总是有工作目录，因此第三档回落不生效

证据三：命令面板与快捷键清单里没有相关项

Host 侧斜杠命令共 6 个（compact、goal、feedback、permission、plan、export），浏览器侧 2 个（file、model）；固定快捷键仅有 fixed.move、fixed.select、fixed.dismiss。

证据四：地址栏不含会话 id

客户端代码没有向 URL 或浏览历史写入会话 id 的实现，window.location 只被读取 .origin；Web 外壳产物中 sessionId 命中 0 次。

证据五：唯一把会话 id 明文呈现给用户的界面途径是导出文件名

会话头部的「更多操作」菜单含「下载 Session 日志」（dsh-session-log-export/lib/client.js:190-229，词条 :238），下载文件名由 sessionLogZipFilename 生成（同文件 :22-24）：

function sessionLogZipFilename(sessionId) {
  return `dsh-session-${String(sessionId).replace(/[^A-Za-z0-9_-]/g, "_")}.zip`;
}

该函数只有一个调用点（同文件 :116 的 this.save(route, sessionLogZipFilename(sessionId))）。会话 id 因此确实出现在一个用户可见的位置——浏览器下载记录与磁盘上的 ZIP 文件名；但这需要先执行一次导出，且导出对话框的文案（:240-246）不提示文件名里含会话 id。本条据此不主张「界面上任何地方都拿不到会话 id」。

证据六：命令行侧存在相关能力（不构成界面入口）

• headless CLI 的 NDJSON 首行会输出会话 id：dsh-headless/lib/json-stream-BA-F3lfb.js:259-263
• 会话 id 的生成形态为 session-<uuid>：dsh-headless/lib/index.js:313

这两条是命令行侧的既有能力，不能被当作 Web UI 或桌面端的界面入口。

证据七：两端是同一份前端产物

对官方桌面端 resources/app.asar 内的同名客户端包与 CLI 侧安装树逐文件比对：3 个产物逐字节相同，5 个的差异仅限 CSS Module 类名哈希与构建时嵌入的源码路径注释；与会话 id 相关的代码行号两侧一致（渲染 sessionId 的那一行在两侧同为 :16498）。桌面端与 Web 共用同一份 Web 外壳产物（dsh-web-frontend/dist/assets/index-5SrrfWpU.js:126 的 globalThis.dshDesktopBoot）。因此上面各条对本条涉及的两个端同时成立。

对照事实：不是「从未有任何位置显示 id」

1. 会话不在列表投影时的头部回落会显示完整 id（证据二）
2. 子智能体目录行与自动化任务详情各有一条「标题为空时回落显示 id」的链路
3. @ 会话引用芯片的剪贴板文本为 @[label](dsh-session:<base64url 会话 id>)：dsh-client-ui-reference/lib/client.js:213-219
4. 会话日志导出的文件名（证据五）

前三者都需要用户先落到特定条件或先执行特定操作，且都不带「这是当前会话 id」的说明；没有一处是「查看或复制当前会话 id」的入口。

影响

1. 会话 id 是定位 $DSH_HOME/sessions/ 下该会话数据、在跨会话引用或日志里对照同一个会话的唯一稳定标识。界面上没有直接入口时，用户要取得它只能靠导出一次日志并从文件名读、或直接翻文件系统的会话目录名。
2. 依赖会话日志的排障、跨机器对照与问题反馈（例如把某次会话的现象提交给上游）都需要先说出会话 id，而这一环目前没有对应的界面入口。
3. 同一能力在命令行侧存在（证据六），界面侧不存在，两端对「怎么拿到会话 id」给出不同的答案。

未验证的部分

1. 未检索 dsh/lib/**，因此「Web 与桌面 profile 是否有列出会话 id 的命令行途径」未查证（证据六只登记了 headless CLI 的两处已知事实）。
2. 未做数据流级的间接渲染排查，不能排除某处经间接变量把会话 id 渲染到界面上。
3. 除 dsh-session-log-export 外的其它导出或分享能力未穷举。
4. 桌面端的结论全部来自安装目录与 app.asar 的只读回读，观测时桌面端未运行，没有桌面端的运行期读数。
5. 证据五的「下载记录与磁盘文件名会显示含明文 id 的文件名」依据的是文件名拼接与 <a download> 语义，未实际执行一次导出实测。

[zermello]

A direct “Copy session ID” action would be useful because the session ID is often the most precise identifier when reporting bugs or working with external tooling.

I’d put it somewhere that doesn’t add clutter to the normal conversation UI, such as the session header’s context menu or an “About session” menu.

For example:

Session menu
├── Rename
├── Copy session ID
└── Copy session path

A tooltip could also expose the ID without making it permanently visible.

If the application already has the ID internally, this should ideally be a presentation-layer change rather than introducing a second identifier.

I’d also make the copy action use the Clipboard API and provide a small confirmation such as “Session ID copied.”

For debugging, showing the ID alongside an error report would be especially useful because users could give maintainers an exact session identifier rather than relying on a title that may not be unique.

If this clears up the issue, please consider marking the answer as accepted so others who run into the same problem can find the solution more easily.

[zermello]

A direct “Copy session ID” action would be useful because the session ID is often the most precise identifier when reporting bugs or working with external tooling.

I’d put it somewhere that doesn’t add clutter to the normal conversation UI, such as the session header’s context menu or an “About session” menu.

For example:

Session menu
├── Rename
├── Copy session ID
└── Copy session path

A tooltip could also expose the ID without making it permanently visible.

If the application already has the ID internally, this should ideally be a presentation-layer change rather than introducing a second identifier.

I’d also make the copy action use the Clipboard API and provide a small confirmation such as “Session ID copied.”

For debugging, showing the ID alongside an error report would be especially useful because users could give maintainers an exact session identifier rather than relying on a title that may not be unique.

If this clears up the issue, please consider marking the answer as accepted so others who run into the same problem can find the solution more easily.

[YOUKNOWWHOOO]

Thanks for taking the time to look at this. The direction of your suggestion is reasonable, but the menu structure in your sketch does not match this codebase, one of the suggested items is not implementable as a presentation change, and the proposed action covers less than the report asks for. Line numbers below were re-read on this machine against @deepseek-ai/dsh 0.2.0-rc.2, in the npm npx checkout's @deepseek-ai scope.

The session header menu exists, but it is not the menu in your sketch, and it has no Rename. The header slot is conversation.session.header.utilities (dsh-cordis-client-runner/lib/client.js:3625). Its current occupant renders an ellipsis button (aria-label = "更多操作" / "More actions") whose menu contains exactly two items — download ("下载 Session 日志") and feedback ("反馈", only when feedback is available). See dsh-session-log-export/lib/client.js:202-211.

Rename is real, but it lives in a different menu: the sidebar session row's "..." menu, registered on the slot sidebar.workspaces.session.menu.item (dsh-cordis-client-runner/lib/client.js:5836; the entries are pin / rename / fork / archive at dsh-client-ui-workspace/lib/client.js:4331-4360). Your sketch merges the header menu and the sidebar row menu into one. Implementing it as drawn would require first adding Rename to the header — a new feature, not a copy action.

There is no "About session" menu. Searching the installed client bundles and this profile's node_modules for about.session, About session and 关于会话 returns no match.

Copy session path is only half available. If it means the session's working directory, the data is already on the client (SessionListEntry.cwd, written at dsh-api-session-controller/lib/client.js:3513). If it means the session log file path, the client cannot obtain it: logPath / generationLogPath are computed Host-side (dsh-session-persistence-jsonl/lib/types/format.d.ts:116 and :125), and the remote method set (dsh-api-session-controller/lib/types/index.d.ts:73-169) exposes no method returning a file path. That item would require a new Host-side method, so it is not the presentation-layer change your reply describes elsewhere.

One thing you were not aware of: this action is already a documented slot example. dsh-cordis-client-runner/lib/client.js:5883 — the slot documentation for sidebar.workspaces.session.menu.item — shows, as its example, registering a menu item with id: 'copy-session-id' that calls navigator.clipboard.writeText(sessionId). So the implementation path is not merely available, it is written out in the framework's own documentation. That is also why the suggestion adds nothing to this report: the report is not asking how to implement a copy action, it is reporting that the product exposes no entry at all.

The proposed action does not cover the report. The title asks for a direct entry to view or copy the current session id; a copy item covers only "copy". The body enumerates six places (sidebar row, hover card, session header, settings, command palette, address bar); the reply patches one. Those two gaps are what the report is about.

Corrections to the report itself, which I wrote.

The report says the export filename is the only UI path that shows the session id in plain text. That is too strong, and the report contradicts itself: its own evidence 2 records the header fallback that renders the bare sessionId as breadcrumb text when the session is absent from the ancestor projection (dsh-client-ui-conversation/lib/client.js:16496-16499), and displayTitleOf (dsh-api-session-controller/lib/client.js:3052-3059, called at :3506) falls back to the raw id when there is neither a title nor a cwd. The accurate statement is that there is no dedicated entry to view or copy the id — not that the export filename is the only plaintext path.

The report also attributes the trajectory raw payload to dsh-client-ui-trajectory/lib/client.js:6211-6212. Those two lines are the Overview page's "Provider" and "Model" rows; the payload block is :6449-6461. The substance holds, the attribution is wrong.

For reference, what already exists for the implementation you suggest. A clipboard helper and its feedback state are shipped: writeClipboard (dsh-client-ui-primitives/lib/index.js:4551-4574) with useCopyFeedback (:9252-9267). Note that writeClipboard falls back to document.execCommand("copy") when the Clipboard API throws (:4558-4573), so "use the Clipboard API" is the preferred path rather than the only one. And you are right that no second identifier is needed — the id is available throughout the client, e.g. dsh-api-session-controller/lib/client.js:3505.

On "marking the answer as accepted". This thread is a feature gap filed under General, not a question in Q&A. An accepted answer would not add the entry the report asks for.