Claude Code SDK #39：Desktop Code tab 全解——Session × Diff × Preview，把 Claude Code 变成桌面开发工作台 (2026)

如果你已经会用 claude 终端命令，Desktop 的 Code tab 第一眼可能显得「多了一层壳」。这个判断只对了一半。

真正的变化在于：它把一个 Agent 写代码过程拆成可见、可审、可并行的工作台。你不再只盯着一串终端输出，而是在同一个窗口里看会话、Diff、Preview、Terminal、文件编辑器、PR 状态和后台任务。官方文档把 Code tab 定位成 Claude Desktop 里的软件开发入口，并明确每个 Code 会话都有独立的聊天历史、项目文件夹和代码变更。1

这篇聊 Desktop Code tab。不是「怎么下载安装」，而是它把 Claude Code 的哪些能力重新组合了，以及 AI 开发者该怎么判断：什么时候用 Desktop，什么时候继续留在 CLI。

1. Desktop 的核心对象不是窗口，是 session

在 Code tab 里，一个 conversation 就是一个 session。每个 session 都有自己的上下文、项目目录和变更集，侧边栏负责列出这些 session，方便你同时跑多个任务。1

这点比界面漂亮更关键。

终端 CLI 里，你通常用多个 terminal、多个 worktree、多个命令窗口来隔离任务。Desktop 把这个隔离关系显式化：新建一个 session，就是给一项开发任务开一个独立工作区。文档还说明，在 Git 仓库中，每个 session 会使用 Git worktrees 创建隔离副本，让一个 session 的改动不会在提交前影响另一个 session。1

如果你经常同时让 Claude 做「修登录 bug」「升级依赖」「补单测」「解释一段老代码」，这就是 Desktop 的第一个价值：它帮你把并行任务从脑子里搬到侧边栏里。

2. 启动任务前，先选四个边界

Desktop 在发送第一条 prompt 前，要求你配置四件事：运行环境、项目文件夹、模型、权限模式。1

这四个选项决定了 Claude 这次到底站在哪里、能看什么、能改什么、能走多远。

启动项	你实际在决定什么	适合怎么选
Environment	Claude 在本机、Anthropic 云端，还是你的 SSH 机器上跑	小改动选 Local；长任务选 Remote；代码和依赖只在服务器上时选 SSH
Project folder	这次 session 的代码边界	尽量选具体 repo 或子项目，不要一上来选过大的父目录
Model	本轮推理和编码能力	复杂重构、架构判断用更强模型；小修小补可换轻量模型
Permission mode	Claude 改文件、跑命令前要不要问你	新项目先用 Ask permissions 或 Plan mode；熟悉仓库后再提高自动化程度

这里有个容易被忽略的点：Desktop 不是把所有 CLI 参数搬成按钮。它只把交互开发常用的边界变成 GUI。那些面向脚本的能力，比如 --print 和 --output-format，Desktop 明确没有对应功能，因为 Desktop 是交互式工作台，不是自动化执行入口。1

所以别把 Desktop 当成 CLI 的替代品。它更像 Claude Code 的驾驶舱。

3. 权限模式：把「信任」拆成可调档位

Desktop 支持 Ask permissions、Auto accept edits、Plan mode、Auto、Bypass permissions 等模式。文档对每种模式的边界说得很清楚：Ask permissions 会在编辑文件或运行命令前询问；Auto accept edits 会自动接受文件编辑和常见文件系统命令，但运行其他终端命令仍会询问；Plan mode 先探索并给计划，不直接改源码；Bypass permissions 接近 CLI 里的 --dangerously-skip-permissions，适合沙箱或 VM。1

我建议把它理解成「任务风险旋钮」，而不是「越自动越高级」。

新仓库、不熟悉的生产系统、权限规则还没配好：先用 Plan mode。
明确的小范围改动，比如重命名组件、补类型、修 lint：可以用 Auto accept edits。
已经在临时分支、测试齐全、环境可回滚：再考虑 Auto。
Bypass permissions 只适合你真的把环境隔离好了的场景。文档也提示它会跳过大部分权限提示，企业管理员可以禁用这个选项。1

国内开发者容易在这里犯一个错：为了省确认，直接把权限拉满。短期看少点了几次确认，长期看是把代码审查、命令执行和文件边界混在一起。Claude 写代码越强，越需要你把授权边界设清楚。

4. Diff view 是 Desktop 最值得用的审查层

Claude 改完代码后，Desktop 会显示 Diff 统计入口。点进去可以按文件查看变更，在具体行上评论，再把这些评论一次性提交给 Claude 继续修改。1

这比在终端里读 patch 更适合团队协作。你可以把反馈放在变更行上，而不是在对话里写「第三个文件第 47 行那个判断不对」。Desktop 还提供 Review code 按钮，让 Claude 对当前 diff 做一次代码审查，重点检查编译错误、明确逻辑错误、安全问题和明显 bug。文档也说得很克制：它不负责风格、格式、既有问题，或 linter 本来能抓的问题。1

这层的正确用法是：让 Claude 先写，再让 Claude 和你一起审。你仍然是最后一个合并代码的人。

5. Preview 把「能跑吗」提前到写代码过程中

Desktop 的 Preview pane 可以启动开发服务器，打开嵌入式浏览器，让 Claude 验证自己的改动。它能测试前端页面，也能验证后端服务、查看 server log，并在发现问题后继续迭代。文档还说明，默认情况下 Claude 会在每次编辑后自动验证变更；如果项目需要自定义启动命令，可以在 .claude/launch.json 里配置。1

一个典型配置长这样：

{
  "version": "0.0.1",
  "configurations": [
    {
      "name": "web",
      "runtimeExecutable": "yarn",
      "runtimeArgs": ["dev"],
      "port": 3000
    }
  ]
}

这个文件的意义不是「让 Claude 知道怎么启动项目」这么简单。它把验证路径写进 repo：端口、工作目录、启动命令、额外环境变量、遇到端口冲突时要不要自动换端口，都可以显式配置。文档提醒不要把 secrets 放进这个文件，因为它通常会随仓库提交；本地敏感变量应放到 Desktop 的 local environment editor。1

如果你在做前端、全栈应用、内部工具，Preview 是 Desktop 相比 CLI 的硬优势。终端里当然也能启动服务，但 Desktop 把「改代码 → 打开页面 → 截图/查 DOM/看报错 → 再改」变成一个连续工作流。

6. PR 监控让 Agent 进入 CI 回路

当你打开 PR 后，Desktop 会在 session 中显示 CI 状态栏。Claude Code 通过 GitHub CLI 轮询检查结果；如果开启 Auto-fix，Claude 会读取失败输出并尝试修复；如果开启 Auto-merge，所有检查通过后可以合并 PR。文档也写明，Auto-merge 依赖 GitHub 仓库本身启用了 auto-merge，合并方式是 squash。1

这件事适合用在两类任务：

依赖测试反馈的机械修复，比如类型错误、快照更新、迁移后的单测失败。
明确范围的小 PR，比如文档链接修正、配置调整、低风险重构。

不适合用在「业务逻辑还没想清楚」的 PR。CI 能证明代码通过某些检查，不能证明需求理解正确。Auto-fix 很省时间，但你仍然要看最终 diff。

7. Local、Remote、SSH：三个环境不是三个按钮

Desktop 的 Environment 选项有 Local、Remote 和 SSH。Local 跑在你的机器上；Remote 跑在 Anthropic 云端，关掉电脑后 session 仍会继续；SSH 则让 Desktop 作为界面，把 Claude Code 跑在你管理的远程机器上。1

选错环境，后面体验会很别扭。

Local 适合需要访问本机文件、浏览器登录态、已有 dev server 的任务。Remote 适合大重构、长测试、迁移这类耗时工作，也支持一个云 session 里添加多个 repo。SSH 适合代码和依赖只能在远程机器上的项目，比如云 VM、dev container、带特殊硬件或系统依赖的服务。1

这里的关键不是「云端更强」或「本地更安全」。关键是让 Claude 跑在最接近真实开发环境的地方。

8. Computer use 是最后手段，不是万能入口

Desktop 的 Computer use 可以让 Claude 打开 app、控制屏幕，像人一样操作你的机器。它适合测试移动模拟器、操作没有 CLI 的桌面工具，或处理只能通过 GUI 完成的流程。1

但文档也明确说了它的优先级：Claude 会先尝试更精确的工具。如果有 connector，用 connector；如果是 shell 命令，用 Bash；如果是浏览器任务且已配置 Chrome 扩展，用浏览器工具；都不适用时，才用 Computer use。1

这很重要。Computer use 很强，但它也是最宽、最慢、最难审计的一种操作方式。Desktop 通过 app 权限分层来限制风险：浏览器和交易平台是 view only，终端和 IDE 是 click only，其他应用才可能 full control。1

我的建议：能用 API、CLI、connector、浏览器专用工具解决的，就别让 Claude 去点屏幕。GUI 自动化应该留给那些没有更窄工具的场景。

9. Desktop 和 CLI 怎么分工

官方文档对这点说得很直接：Desktop 和 CLI 使用同一个底层引擎，可以同时在同一台机器、同一个项目上使用；二者有各自的 session history，但共享 CLAUDE.md 等项目记忆和配置。你还可以在终端 session 里运行 /desktop，把当前 CLI 会话保存后打开到桌面应用中。1

我会这样分工：

场景	更适合的入口	原因
批量脚本、CI、自动化生成、结构化输出	CLI / Agent SDK	Desktop 没有 `--print` 和 `--output-format` 这类自动化入口
视觉审查、前端验证、多会话并行、PR 反馈	Desktop	Diff、Preview、session sidebar 和 CI 状态都在同一界面
VS Code 内边写边问、选中代码后 @mention	VS Code extension	VS Code extension 能直接读取选中代码，并在 IDE 里打开多个 Claude 会话。2
从告警、runbook、wiki 一键打开任务	Deep links / CLI handler	Deep link 可以携带 repo 或 cwd 与预填 prompt，但不会自动发送，点击后仍需人工确认。3

一句话：CLI 负责可编排，Desktop 负责可观察，IDE extension 负责贴着编辑器干活。

10. 一个可落地的 Desktop 工作流

如果你准备把 Desktop 用进日常开发，可以先从这个流程开始：

在 repo 根目录补一个最小 .claude/launch.json，只配置最常用的 dev server。
新任务先开独立 session，不要把所有需求塞进一个长会话。
不熟悉的任务用 Plan mode，让 Claude 先读代码、提计划，再切到 Ask permissions 或 Auto accept edits。
每轮改动后先看 Diff，再看 Preview；不要只读 Claude 的文字总结。
打开 PR 后，让 Claude 盯 CI，但把 Auto-merge 留给低风险 PR。
需要跑很久的任务再切 Remote；需要服务器依赖的任务用 SSH。
Computer use 只给没有 CLI、API 或专用工具的流程。

到这里，Desktop 的定位就清楚了：它不是给不会用终端的人准备的低阶入口，而是把 Claude Code 从「一个会写代码的对话框」推进到「可审查的开发工作台」。

真正要练的不是按钮在哪里，而是每次任务开始前问一句：这次我希望 Claude 在哪里跑、看到哪些上下文、拥有哪些权限、用什么方式证明改动真的有效。把这四件事讲清楚，Desktop 才会比 CLI 多出真正的工程价值。

Claude Code SDK #39：Desktop Code tab 全解——Session × Diff × Preview，把 Claude Code 变成桌面开发工作台