I manage the unofficial build at https://github.com/aaddrick/claude-desktop-debian
Debian is in the name, but scope has grown to all backends, compositors, etc.
The main reason must companies don't publish Linux electron apps is fragmentation. If you're doing anything more than rendering a webpage as an app, it starts to get complicated. I've got a bank of VM's setup for testing, and I still need it up.
Can confirm. At a past company we worked hard to release a Linux desktop client for our customers who wanted it, even though the number was small.
It turns into compatibility hell very fast. You think you can target a couple recent Ubuntu releases and everything will be good, but then you’re getting peppered with complaints from people using distributions you’ve never heard of because some part of the app isn’t working right. So your engineers spend a half day installing that in a VM and debugging it, but the problem is in upstream somewhere. The number of tickets with Linux issues keeps growing and each one is taking more time to debug, all for a number of customers that is so small you can’t justify doing it.
But those customers are angry. And vocal. They’re posting all over Twitter, Hacker News, and Reddit about how your company’s software is garbage, without mentioning that they’re running an unknown distribution on a 13 year old ThinkPad.
This even impacts open source projects. Several popular OSS Electron apps don’t work on many popular distros unless you set some command line workarounds, and even then it’s flakey. The open source projects get a pass because it’s open source, but if your company releases something you might be picking up a lot of angry, vocal customers that you didn’t want.
A lot of that is keyboard shortcuts for push-to-talk. Easy right?
X11 is mostly fine, but the world is moving into Wayland. Wayland doesn't have shortcuts native and relies on xdg-desktop-portal, which in turn relies on each backend to implement it's own version.
COSMIC from the Pop!OS team's xdg-desktop-cosmic doesn't support GlobalShortcuts yet (might now, haven't checked in a bit). So XWayland for them.
Tray icons? GNOME doesn't have a tray out of the box, but there's an extension. There's no standard for whether it's light mode or dark mode across distros and when you map out the options, no api's indicate whether the tray is light or dark while in light/dark mode. At some point you have to just accept it's not always perfect or patch in an override.
There are companies that do this right. But it often requires a hire. Too many companies think they can just yolo it because Linux isn’t a serious OS or whatever and then are surprised when it doesn’t work out well.
"Tony Stark can do it in a cave! With rocks!"
Much easier to create a vm testing swarm of 100 disitributions with llms
I dunno why this is always so difficult.
But they do? Companies don’t publish anything BUT electron apps. If desktop Linux gets anything from outside of FOSS, it’s electron. See Spotify, discord, slack, vscode… list goes on. I don’t think a for profit company has provided a GTK or qt app for Linux in the last 20 years.
I applaud your efforts but this is a supposed trillion dollar company with a product that probably has thousands of electron apps in its training set. They should be paying you.
The comment was that the Electron apps aren’t being released for Linux even when they exist because Linux is so much harder to support, even in Electron.
If they don’t have resources (or desire) to keep the Electron app working on all the Linux distros then they definitely won’t have the resources to write a completely separate GTK app for the few Linux users.
After going through this process to get codex installed on Linux I'm honestly baffled why OpenAI doesn't have an official port. Though I haven't tested every part of the app, everything works as intended, even got computer use working without any issues.
Swipe keyboards on mobile are awful, but I can't break that habit.
Also, I can't break the swipe keyboard habit either. It's the worst, but still better than the alternatives. Someday I hope physical keyboard makes a return (but I"m not holding my breath)
It's great that I can ship one item for all platforms, but Flatpack doesn't solve the compatibility discovery problem for me.
More context in my reply to the comment linked here :https://news.ycombinator.com/item?id=48434436#48435661
The issue is folks expect this to be at a higher level, so when libc or GTK or Qt etc. have breaking changes, all your apps using the old versions fail. This is a legitimate pain point with traditional distros.. I don't want to sound like I'm downplaying it.
However, this is basically solved by flatpak (and others like it, eg snap) which contain _all_ these dependencies in the package. Layering (ala containers) is used for deduplication so you don't have 20 copies of a given GTK version.
While MacOS provides the windowing toolkit etc. at the OS level, it's otherwise similar to how a .app file works. Installers aren't dropping dynamic libraries and resource files all over your disk, the app is "self-contained."
There’s still a cost to testing, support, planning, etc even if coding is now “free”
Lame, I know, but you have to entertain yourself sometimes when the only thing anybody talks about here is ruddy spicy autocorrect and self-inflicted job destruction.
Glad someone else sees this as well in this crappy website
Supports linux :)
Here, fixed it for you.
"It'll make software easy and replace all software jobs!"
"Sorry, a Linux client is too hard and too much work!"
I no longer know if this is a real person who is simping for Anthropic and will be ultimately enslaved by Anthropic or if this is an Anthropic ad to have "proof" for the high demand of their services.
Perplexity are devleoping Comet as an AI-powered browser. I wonder if anybody will take the OS leap.
There is already way too much slop.
Did you just tell me to go fuck myself ?
There's also the cross conversation memory search, which uses a different conversation dataset (the Claude Web / Claude.AI conversations) than Claude Code does. I'm not even sure Claude Code does cross conversation search?
The Desktop interface also presents Markdown as formatted text and presents artifacts (especially interactive ones) better than the CLI can.
All that said - I actually use the CLI for nearly everything (even on Windows). Rather than use Claude Desktop for daily "routines" that are capped at 15 total cron-jobs and use extra usage credits, I think I'll continue building my own minimal harness and move my routines to models from other providers.
I also haven't touched routines, but I use cc to write automation tasks that will integrate a model when I need an inference layer. Which I also did before routines..
Have people actually been using routines effectively?
It (Claude Code) does, I discovered it by accident recently, having never used daily routines before. Haven't touched Claude Desktop at all, outside of playing with it for 30 mins or so months ago.
TLDR: I used Claude Code to build a command that scrapes job postings from a few employers I am interested in (it is a bit more complicated than that, but that's the gist). At the end CC asked me "do you want me to re-run it daily?" I said yes, and it generated a daily routine and gave me a URL to my anthropic account page where I can see all my daily routines.
There, it says that I am currently using up 1 out of 15 "free" daily routines that come with my personal subscription, and I would have to pay extra if I want to have more than 15 active at a time (I assume by switching to per-token pricing for anything beyond 15, but not sure).
This is one of the first things I “fixed” with skills and hooks. I index every conversation in SQLite and have a skill which knows what to do when I ask it to search the index. I had to avoid the word memory because it’s too tied up in other parts of the context. It even indexes across my different machines. I set this up because I have terrible context discipline. I’ll go off on a tangent in one context and start planning and sometimes implementing something based on that thread which really deserves its own context. Afterward I can create the new context and move relevant bits to it, but I’d lose that initial starting conversation which inherently has more data than the summary in the new context.
I also use a few different related contexts. One where I’m building a game engine in zig and another talking about game ideas. There’s a lot of back and forth going on there which needs some shared context. I solve this with a combination of Claude.md references and that searchable session index.
Everything I do with scheduled tasks are just wired up with systemd and simple scripts. No LLM in the critical execution path. Again a skill tells CC how I manage those scheduled things so I just have to say something like “run this every day at midnight” and CC has reliably taken care of the rest.
2. Scheduled tasks that run locally ( https://support.claude.com/en/articles/13854387-schedule-rec... ) importantly different from Claude Code routines
3. Multiple projects/isolated memories in the same folder
4. Better UI
What do people do with these? I don't use Claude but when I did I couldn't think of anything useful to do with the routines. I'm probably not being imaginative enough.
They all have pros and cons. Pick the one that suits you best. Then you're also agent harness flexible (I use opencode).
Sandboxing a GUI is typically more operational overhead than sandboxing a cli (mounting compositor sockets, GPU access, etc).
Casual mode [3]: > Your home directory is mounted as a copy-on-write overlay. The jailed process sees your real files, but writes go to $HOME/.jai/default.changes instead of modifying originals, except in the directory where you ran jai. Your current working directory grants full read/write access to code in the jail (unless suppressed with -D). So files deleted there are really gone. /tmp and /var/tmp are private. The rest of the filesystem is read-only.
Strict mode [4]: > The process runs as the unprivileged jai system user, not as you. Home directory is an empty private directory at $HOME/.jai/<name>.home. Granted directories (via -d or cwd) are exposed with id-mapped mounts — files look like they are owned by jai inside the jail. Because the process has a different UID, it cannot read files outside your home directory that are only accessible to your user — this is where confidentiality comes from.
Bare mode [5]: > Home directory is an empty private directory, like strict mode. But the process runs as your user, not as jai. This means it cannot provide confidentiality — the process can still read any file accessible to your UID outside the home directory.
I've always ran my stuff in casual so far just so my whole computer doesn't get rimraffed :P. but I'm thinking of switching to just strict mode, but haven't really vibe coded in a while so I haven't tried it yet.
[1]: https://jai.scs.stanford.edu/
[2]: https://jai.scs.stanford.edu/modes.html
[3]: https://jai.scs.stanford.edu/modes.html#casual-mode
My reply to the comment below outlines the shape of the problem.
Nothing I can't do myself (and generally I do keep an eye on that sort of thing), but it did catch a holiday for my foreign team members that seemed to have gone unnoticed, and remarked about a status mismatch between Jira and source control that made the dashboard misrepresent progress. It's not much, but it's an extra little check that works quite well.
Another trick I'm experimenting with is having Claude rebase my open PRs waiting for review every day, and auto-solving conflicts when they arise. I don't trust it enough to let it push code to the repository, but I think I have the prompt set up in such a way that I might soon start using it.
I've gotten good results using it at work for keeping track of expense receipts. I dump them into an "Inbox" folder and Claude will OCR them, convert any images to PDF, rename, and move them into year/month/date folders and classify them (cost centers, based on a mapping and examples I gave it). This runs daily, checking the Inbox directory for new items.
My next step is getting it to pull them from my email automatically for me as well, or from a specific alias so when I take a pic of a receipt on the go I can just email it and have Claude rename and organize it for me, then it all gets sent off to AP at the end of the month.
Non technical knowledge workers have all kinds of little admin tasks like that which Cowork can do for them, where previously they lacked the skills or will to just learn some python and script it themselves.
Haven’t set it up because I’m horrified by the thought of it reading my mail. Doubly so if it decides to do anything other than telling me if I missed something important.
Have you considered that maybe their code is just bad?
If your app is open source, I say just build & test on one of the major distros and let the community port it to others. If its closed source, well, good luck. But if what the parent said is true, that you now collect a bunch of very vocal pissed off customers because you didn't support their favorite distro, then its just not worth it at the current marketshare that desktop Linux has.
There's also the challenge of you just can't make any assumptions about what may be present or not on someone's Linux machine, even with the major distros.
Global shortcuts definitely a pain point with Wayland but the portals are making progress.
While GNOME tray lovers and haters both exist, only one of those two groups is liable to submit an issue against my repo looking for help getting icons working correctly.
The lack of desktop UI affordances in the leading "user-friendly" Linux distribution should be seen as a five-alarm fire by anyone interested in promoting wider Linux acceptance on the desktop. There are reasons why Linux can't get past low single-digit adoption no matter how badly Apple and Microsoft screw their users, and I'm sure the half-assed desktop UI is one of them.
Made comment about flatpack below the comment above.
These angry customers are a symptom of having more customers; in this direction (compatibility) companies shouldn't be KPI'ing on angry customers.
It is very legitimate that high compatibility means more very obscure, low value, high cost, bug reports that are hard to classify as such. And my gosh, I hate working with rude ticket writers.
No, it's a symptom of having more of a very specific type of customer who is more demanding and difficult to please than your other customers.
When you don't officially support Linux, the Linux users are not surprised. It's normal for them. They find other ways to use the product.
When you do announce Linux support, you open Pandora's box of complaints. They're extra angry that you claim Linux support but it doesn't work perfectly on their unique combination of laptop, distro, display protocol, and window manager.
You gained a small number of happy customers, but picked up a disproportionately large number of angry, vocal customers in the process.
Flatpak serves a need, there are plenty of users who like it and there are probably even more who just use it without thinking much about it. Personally, I like it for a few reasons: - Being able to install something dependency-heavy with just one package - Sandboxing - Getting a newer package than what my distro provides - Being able to update apps independently of the rest of the OS - Being able to easily install apps that my distro doesn't provide
The people who hate it, especially without giving a reason, are largely irrelevant when flatpak is filling a need for so many other people. Design for the people who are using and who like your product. Make adjustments based on their feedback. Ignore the people who just make noise.