DEEIX Chat 的 macOS、Windows 和 Linux 客户端。它运行与浏览器相同的界面，也可以启动随应用内置的服务器，让所有内容留在本机。

下载与安装#

桌面端需要单独安装，不由你的 DEEIX Chat 部署提供。

也可以使用下载页，按平台自动选择安装包。

1. 打开项目的 GitHub Releases 页面：https://github.com/DEEIX-AI/DEEIX-Chat/releases。
2. 下载对应平台的安装包。
3. 安装并启动 DEEIX Chat。
4. 首次启动时，在设置页选择要使用的服务器。

配置了签名密钥的发布版本会带有签名。未签名的安装包也能使用，但 macOS 会要求你在系统设置 → 隐私与安全性中允许打开，Windows 会显示 SmartScreen 提示。

首次启动：选择服务器#

首次启动时，窗口会显示设置页，提供两个按钮：

连接远程服务器：

1. 点击连接服务器。
2. 在服务器地址中填写完整地址，例如 https://chat.example.com。
3. 点击连接。检测期间按钮显示检测中…。
4. 只有服务器返回正常后才会保存地址。客户端会先请求 /healthz，因此输入错误不会在重启后继续生效。
5. 点击返回回到两个选项。

如果该服务器已在其他标签页打开，客户端会切换到那个标签页，而不是重复打开。

如果之后的启动无法拉起已配置的服务器（例如本地 sidecar 启动失败），标签页会提示无法连接已配置的服务器并回到设置页，方便你换一个地址。

使用本地模式#

在本机使用让应用自身运行一套完整的 DEEIX Chat，无需部署服务器。

• 随应用内置的 Go 服务器以 sidecar 进程启动，监听随机的 127.0.0.1 端口，不向你的网络暴露任何内容。
• 数据存放在 SQLite 和应用数据目录下的本地文件中。密钥按该安装实例生成。
• 你会成为唯一的用户——一个无密码所有者。壳会读取 sidecar 只向标准输出打印一次的一次性授权；授权单次有效、两分钟后过期，并在网页看到它之前就被消费。
• refresh token 保存在系统钥匙串的 refresh-token:local 条目下。
• 本地模式没有登录页，因此登出等同于离开服务器：标签页丢弃凭据并返回设置页。
• 最后一个本地标签页关闭时，sidecar 随之停止。

本地模式使用与服务端部署相同的服务端代码和安全策略，适合个人使用和评估。团队或长期运行的实例请连接 PostgreSQL + Redis 部署。

在标签页中使用多个服务器#

每个标签页只绑定一个服务器，并运行一份独立的 Web 应用。会话、缓存和流式连接不在标签页之间共享，因此可以同时打开一个本地实例和一个或多个远程部署。

绑定过服务器的标签页会在下次启动时恢复。标签页标题在本地模式下显示本机，连接远程服务器时显示服务器主机名，尚未绑定时显示新标签页。

主题、字号等界面偏好只存一份，并在所有标签页之间共享，因为它们跟随的是你，而不是某个服务器。

登录与凭据#

远程服务器支持与浏览器一致的登录方式：密码、两步验证和 OAuth/OIDC 身份源。

桌面端把长期有效的 refresh token 放在系统钥匙串里，而不是 HttpOnly Cookie。网页没有任何途径把它读回去。

页面只在登录时把 refresh token 交给壳一次。之后它只能请壳刷新会话、在本机登录或清除会话。关闭标签页会丢弃该会话，切换服务器会删除上一条钥匙串记录。

使用第三方身份源登录#

Webview 无法接收身份源重定向，因此桌面端采用 RFC 8252 回环流程：

1. 壳在 127.0.0.1 上绑定一个临时端口，并把 http://127.0.0.1:<port>/oauth/callback 作为回调地址交给 Web 应用。
2. Web 应用使用客户端 ID com.deeix.chat.desktop 启动身份源桥接。
3. 身份源的授权页面在你的系统浏览器中打开，复用已有的身份源会话。
4. 身份源重定向到服务端回调。服务端签发一次性 DEEIX 授权，并把浏览器重定向到回环地址。
5. 壳返回一个“可以关闭此标签页”的页面，并把回调交给 Web 应用，由它用 PKCE verifier 兑换授权。

监听最多等待 10 分钟。

服务端需要设置 PUBLIC_API_BASE_URL，并为每个身份源注册实例回调。桌面端不需要自定义 URL scheme，也不需要在身份源白名单中增加条目。回调格式见配置。

托盘#

应用常驻系统托盘，因此窗口关闭后，通知和更新仍然能找到你。

• 左键点击托盘图标可显示并聚焦窗口。
• 托盘菜单提供 Show DEEIX Chat（显示窗口）和 Quit（退出）。Quit 会退出应用，包括本地 sidecar。

更新与发布通道#

应用在启动时以及每四小时检查一次更新。未确认前不会下载任何内容。

1. 有新版本时，提示显示新版本 {version} 可用，并提供更新按钮。
2. 点击更新，提示变为正在下载更新…。
3. 下载完成后，提示显示已安装 {version}，并提供重新启动按钮。
4. 点击重新启动，应用重启进入新版本。

下载或安装失败时，提示显示更新失败：{message}。每次更新在安装前都会用 tauri.conf.json 中的公钥验证签名。

正式版安装不会收到预发布版本。Beta 安装会持续收到 Beta；要回到正式版，安装一个正式版即可。两个通道使用同一把签名密钥。

从源码构建#

桌面壳位于 apps/desktop，加载的是服务端也在使用的同一份静态构建产物（apps/web/out），因此产品界面没有单独的桌面构建。

前置条件：Rust 工具链、Tauri 2 的平台依赖（Linux 上的 WebKitGTK、Windows 上的 WebView2、macOS 上的 Xcode 命令行工具），以及在仓库根目录执行 pnpm install。

make desktop          # 以开发模式运行桌面端make build-desktop    # 本地构建，只产出 .app，放宽 LTOmake release-desktop  # 发布构建，存在签名密钥时自动签名

make dev 会同时启动 API 和 Web 应用，但不启动桌面壳；桌面壳用 make desktop。构建产物位于 apps/desktop/src-tauri/target/release/bundle/。

构建完成不等于可以发布。macOS 包需要公证，Windows 包需要代码签名。签名密钥只存在于 CI secrets 中。

常见问题#

相关#

• 快速开始
• 配置
• 架构
• 平台矩阵
• 通用