There's no Linux download button. There is a Linux build. Here's how I checked.
I run a small independent documentation site about WorkBuddy, Tencent's AI office workbench. Most of the questions it gets come down to one thing: is there a Linux build?
Disclosure up front: WorkBuddy Central is an independent, unofficial guide, not affiliated with Tencent, OpenAI, Anthropic, or any product mentioned here. I write about the parts the official pages leave out, and I link to the official material where it is already correct.
If you open the official download page, the answer looks like no. Windows and macOS get direct installers. The Linux section names two distributions — UOS and Kylin — and points you to the system app store. There is no general .deb or .rpm button anywhere on that page. A lot of readers conclude that no Linux build exists.
I concluded that too, initially. The difference between "not linked" and "not shipped" is the reason the site exists.
What I actually checked
The desktop client checks for updates over HTTP. That means build metadata has to be reachable somewhere, whether or not a page links to it. I queried the same endpoint the client calls, with a platform parameter for the DEB build:
curl -fsS 'https://www.workbuddy.cn/v2/update?platform=workbuddy-linux-x64-deb' | python3 -m json.tool
One request, eight fields. These are the values I observed on 2026-11-10, copied as-is rather than rounded:

  • version: 5.6.2.40046327
  • productVersion: 5.6.2.40046327
  • url: https://download.codebuddy.cn/workbuddy/saas/linux-x64-deb/WorkBuddy-linux-x64-deb-5.6.2.40046327-c7b525f3.deb
  • sha256hash: 12149ad8c0cd748fd5062d8f62c7827d688d8095427ada99b1ae9e7019897523
  • timestamp: 1790769527
  • hash: empty string
  • name: empty string
  • supportsFastUpdate: false The RPM build is the same request with the platform suffix swapped. Its SHA-256 is 2e49fac166708e9716ab36dc3a7ffcf0fcea4a94591419b3654c59b67f4d392d. The DEB is roughly 410 MB, and the download responds with Server: tencent-cos — the file comes from the vendor's own object storage, not a mirror. I re-ran the DEB request on 2026-11-14 before writing this. Same version, same URL, same hash, same two empty fields, same false. Nothing had moved in four days. Three things that are easy to misread Empty hash and name are not a failed parse. They are empty strings in the response. I lost time assuming my JSON tooling had dropped something. The timestamp is the build's release time, not today. 1790769527 resolves to 2026-09-30 in local time. If you treat it as a freshness signal, you will report a two-month-old build as new. supportsFastUpdate: false is the one with practical consequences. In-app auto-update for WorkBuddy on Linux is not something to rely on. You check the endpoint yourself, or you stay on the version you installed. The checksum trap The endpoint gives you a SHA-256, and the file is served from a host under the vendor's domain. That is convenient, but notice what it does not prove: a checksum published by the same site that hosts the file says nothing about where the file came from. It proves the bytes you received match the bytes that endpoint expected, assuming the response itself is trustworthy. The only thing that closes the gap is downloading the package from the vendor endpoint and comparing it byte-for-byte against the hash you fetched independently. If the values differ, do not install the package. This sounds obvious, and it is exactly the step most one-click installers skip. One of the community Linux projects I looked at keeps both reportedSha256 and actualSha256 for this reason, and states plainly that its own checksum files cannot independently prove official identity. That same project and another one are useful as a cross-check, not as authorities. On 2026-11-10 the GitHub API reported 63 and 56 stars for them; 63 + 56 = 119, which matched a figure I had seen quoted elsewhere. That agreement is a cross-check of one day's API reading, not a claim about popularity — star counts change, neither project is affiliated with Tencent, and I do not treat either as an official source. What I will not claim I have not installed the build on every distribution. DEB and RPM are packaging formats, not compatibility guarantees. I could not verify an official arm64 endpoint, so I do not list one. I did not measure performance, user counts, or anything else I cannot reproduce from a request and a file. Where a page can verify only part of a claim, it says which part; a page that cannot be verified does not get published. I put the full notes — both hashes, the ARM limit, the download and verification steps — on WorkBuddy Linux install notes so the values live in one place with the date they were checked. When an endpoint moves or a version changes, the correction is dated on that page rather than silently overwritten. That is less satisfying than a confident answer, but it is the only kind I can reproduce.