Would official Linux desktop support be considered?

[finettt]

Hi! I came across the community Linux build in #8411 and wondered if official Linux support is something the team might consider. I'd be happy to help with an x64 build (e.g. CI job + AppImage/.deb). CONTRIBUTING.md says external PRs aren't being accepted at the moment. Is that still the case? I won't open a PR unless you're open to it.

[PerryLink]

你问的三件事我逐条回答（含一处需要更正的前提）

1. "官方是否会考虑 Linux 桌面支持"

我不能代表官方回答排期。⇒ 但可以给你两条可核实的事实，它们决定了这件事的形态：

• 桌面端是 Electron 应用（捆绑 Electron + 内置运行时）⇒ Linux 打包在技术上是常规工作（AppImage/.deb + CI 产物），不存在"做不到"的问题；
• 非桌面路径今天已可用：Linux 上可跑 Web/Headless 形态（这正是社区 Linux 构建 #8411 所走的路）。

⇒ 建议把问题改成："官方是否有计划把桌面壳纳入 CI 产出一个 Linux 构建？"——这样问有确定答案，而"会不会支持"只能得到"看排期"。

2. ⚠️ 关于 CONTRIBUTING.md："不接受外部 PR"仍然成立

你写"CONTRIBUTING.md says external PRs aren't being accepted at the moment. Is that still the case?"⇒ 按我核到的现状：仍然成立（该仓库的 Issues 也是关闭的，反馈走 Discussions）。⇒ 所以"我提一个 CI + AppImage/.deb 的 PR"这条路目前走不通。

3. ⇒ 但你愿意帮忙的方式依然存在（建议这样提）

既然不能提 PR，可执行的贡献形态是：

1. 在 Discussions 里给出可复现的构建方案（CI 步骤、依赖、产物形态），维护者可直接采纳；
2. 把社区构建（#8411）作为可行性证据引用——它证明这条路可行，比空谈需求有力得多；
3. 若社区构建已可用，先让需求方用起来（用户量是排期的依据之一）。

⇒ 建议把这条帖改写成"可行性 + 现成方案 + 社区证据"，而不是"是否支持"。

4. 一条边界

我确认的是**"不接受外部 PR"这一现状与桌面端为 Electron、非桌面路径可跑**这两点。官方排期我无从得知——这一句请以维护者回复为准。

[slyyr]

Technically, Linux desktop support should be possible if the desktop application is already based on Electron.

The more important question is whether the project wants to officially maintain Linux builds. I'd check the current contribution policy before preparing a PR, since the repository may not currently accept external PRs.

If external PRs aren't accepted, providing a reproducible build/CI proposal through Discussions would probably be the better route.

If this helped, please mark the answer as accepted so it can help others too.

[dahch]

Following the suggestion to share a reproducible build proposal here: see the discussion describes a linux-x64 target for apps/desktop (rpm + AppImage via electron-builder) as a small patch on top of 0.2.1-rc.2, including what I tested and what I didn't.

lock.json already had linux-x64 runtime entries, so the main blocker I found was sharp segfaulting under Electron's Node mode, worked around by running the Host under the bundled Node on Linux. No PR from my side, per CONTRIBUTING.md. I'm only offering it as a reference.

[jjaksic]

I found unofficial Linux desktop releases here: https://github.com/yaoyingkeji/deepseek-harness/releases

It would be great if official releases were available, and it wouldn't cost much to add them. Everybody uses Linux.

[Ruivalim]

+1 for official Linux support. Adding a data point that might make a first step cheap to accept: on current master (0.2.2-alpha.3), pnpm run dev:desktop and start:desktop only fail on Linux because apps/desktop/scripts/desktop-build-paths.mjs hardcodes mac-arm64, mac-x64 and win-x64. The primary-runtime lock.json already pins the linux-x64 and linux-arm64 archives.

I kept the change to that and nothing more: Ruivalim@9026af9de0

• resolveDesktopBuildTarget accepts linux-x64 and linux-arm64, so development launches work.
• Packaging, signing, retention and publication go through a new resolveDesktopReleaseTarget, which still rejects Linux. No installer, no update channel, no CI change.
• Specs and the packaging README (en/zh) are updated; typecheck and lint pass.

Tested on CachyOS x64 under Wayland: the shell starts, the Host comes up and the main UI loads. linux-arm64 is not tested.

Since this doesn't commit you to shipping Linux builds, it could be a low-risk way to let Linux contributors run the desktop shell from source, with packaging (e.g. #10197) as a separate decision.