Anthropic, please ship an official Claude Desktop for Linux
github.com
github.com
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.
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)
We haven’t.
The only proprietary software I have running on my machine is electron apps, which are essentially bloated VMs. As we’ve seen from this thread, this is still apparently too great of an engineering feat for anthropic to tackle. I don’t think I’m unique in this regard.
Of course a lot of Linux users these days just live their lives through browsers. That's pretty sad.
Teams: Was electron
Steam: Valve is deeply invested in Linux, this isn't them just shipping an app. Different category.
Jetbrains: Java
Cursor: Electron
Discord: Electron
Matlab: Java
ABI compatibility doesn't matter for any of your examples.
Isn’t Steam mostly webviews though ?
> Java
Well.. It’s not that massively different from running Qt apps in Gnome, though?
> ABI compatibility
I’m sure it matters for Swing to an large extent. Of course it the problem of the people developing the UI framework rather than the end app
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."
That said, an official build would make a huge difference for enterprise adoption. Many companies have policies against unofficial packages, and the signing + update mechanism is always going to be more trustworthy when it comes from Anthropic directly.
For anyone waiting: the unofficial build is perfectly usable for personal projects. But I would love to see Anthropic prioritize this -- the Linux developer community is exactly the audience that pushes Claude the hardest.
Of course, it's impossible to know for sure what was LLM processed or not, but most of your posts are getting classified that way.
You obviously have good points to make and are welcome here! but if you'd please write text by hand which you plan to post to HN itself, we'd appreciate it. The community feels strongly about this right now.
a) be welcoming and indicate that we're OK with broken English (content and intent typically do get through), and/or
b) allow posting in languages other than English (does this even work right now?).
Above probably ahead of its time, but thought I'd just make the suggestion.
I'll be happy the day there's an official distribution and I can put the repo to rest
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.
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.
I personally think they should port it, but, the developer product does already run on Linux, in the terminal, as is the case with the majority of other dev tools.
DaVinci resolve is QT. But making a video editor performant in Electron is even harder than writing it in C++..
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.
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.
And how do you know the userbase for GP's specific product is all Flatpak users? In fact, based on their comment, it appears as though they are explicitly not, hence their vocal frustration.
Ultimately if something isn't in my distro's repository, i try to compile it from source and if that isn't available, i just use something else.
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.
I wasn't looking to anger you, just to provide a different lens in which to view the situation.
Sure, you'll still get a few complaints from ideological purists, but there's no avoiding that regardless of what you do.
Made comment about flatpack below the comment above.
Much easier to create a vm testing swarm of 100 disitributions with llms
"Tony Stark can do it in a cave! With rocks!"
I dunno why this is always so difficult.
My reply to the comment below outlines the shape of the problem.
But it has proven quite the challenge to support old Linux distros. We have tried using nix to pin deps, but this easily leads to new issues: hardcoded RPATHs leaking into binaries, glibc compatibility issues, etc.
If we instead fork the build environment and use an old Ubuntu for building our Linux app, then my life gets harder, because now I have two targets for a whole lot of internal tooling that my team maintains, and that tooling needs to be deployed to both build environments. Again, its the same shit: glibc mismatches, missing/different shared libraries, etc. Just causing problems in a different place.
There is certainly some element of skill issue at play. But I wouldn't call it easy.
I have recently been working on a C11 GTK+ based task manager where I run into this. https://github.com/hparadiz/evemon/tree/main/packaging
This is why I said bundle your libs. If you bundle ALL of your libs you can't possibly run into an issue if your install script is run as root. Unless it's an extremely eccentric non desktop oriented system at which point that's kind of on them.
If you wanna cover 99.9% of Linux you build fedora, ubuntu, debian, nixos, arch and have a tar.gz as your overflow. For each target the lowest available LTS and don't waste time on distros that aren't getting security updates. It's not reasonable to ask for binaries built against your specific 11 year old gcc.
edit wanted to add one more thing.
I'm a big believer in having your tar.gz and install script inform your deb, rpm, aur, etc. It should be basically the same exact thing as your tar.gz just done in the format those distros 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.
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.
On GNOME? Alt-tab, super overview, or click the dock icon. It's literally not any more complex than multitasking on an iPad.
A lot of us = very few people in total, apparently.
There's a reason Dash to Dock and AppIndicator are packaged by default on most Gnome distros and overwhelmingly installed on those that don't have it. Even Gnome itself has started development on a native systray, although in classic Gnome NIH fashion they either want to implement a new standard or are were even considering using the deprecated snixembed standard instead of using what 99% of Linux does :+)
(Technically they want it for pretty good reasons, but good luck forcing all Linux applications to implement yet another standard, especially the commercial applications)
All these issues can happen in any platform, Linux is just the more annoying/unpredictable one, with GNOME taking the cake for being so obtuse. There is either a carelessness from the developer or the ad-hoc nature of those "tray icon" systems is to blame.
Can you name some that act like this? In 30 years I don't think I've ever seen that behavior...
Back when I still had a need for it it was solely because some apps do not have proper support for missing tray icons (you can only fully close them via the tray icon), not because I actually like the feature.
I appreciate that GNOME tries to move on from this. Unfortunately it doesn't have the market control that Windows has, so not all app developers follow suit.
KDE Plasma allows hide selected applications from the tray and make those accessible in a popup window. The solution to this problem is not to remove the feature entirely, but actually implement it properly.
(Until Microsoft had actively started fracking it up, sometime around Windows Vista) just like a Roman citizen landing up in any town of the Empire, one would be able to effectively and consistently navigate around, using both keyboard and mouse across most Windows applications. Everything worked in a boring, predictable way. Everything used standard API that provided the whole spectrum of UI capabilities.
With Linux, unfortunately, this was never considered ideal and instead we have a zoo of different paradigms and technologies (plus intense politicking of UI development). Which means, when something happens to work as expected without excessive ServerFault/ChatGPT trawling and config/gconf/dbus wizardry, it feels like a sheer delight and an exception rather than a rule.
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.
I agree that sticking to libc is most reliable, if you can. But the experience is poor if you do that for desktop applications.
There's no singular source of truth, but there's a de facto frontier of only a few mainstream distros, as well as upstream heads for your dependencies.
It's extra work, but there are systematic workarounds to the feature drift over time and the tendancy of some open source projects to aggressively deprecate older functionality and older system compatilbilty.
You can, to an extent, automate testing on newer versions of distros to be alerted when something no longer works, and often you can do this before the official distro release date.
Unfortunately even libc is not reliable. Unless it's a static build, Glibc is often broken (with symbol version errors) when trying to run a binary compiled on one distro on another distro, or an older version of the same distro. Static binaries have other problems, though work very well if the application is self contained and isn't a GUI.
One thing that I find works very compatibly, though, is OpenGL / Vulkan binary-compatibility across distros and versions. There was a lot of work done on making libGL something you can link to or dynamically load reliably and take it from there. The OpenGL extension spaghetti is an interesting problem from then on, but that's more to do with the individual user's GPU and GPU drivers, independent of the Linux distro or even which OS it's running on.
Not if they're GPL licensed you can't. And that's a headache most commercial people do not want at all when trying to write software that's often for a marginal part of their audience anyway.
Wrong, misleading and possibly FUD. Yes you can ship GPL licensed software with your application, even a proprietary, closed source application.
You have to comply with the GPL terms, but that's easy to do for every library or auxiliary program that you'd link to or call in a Linux distro.
The GPL is designed to support this use case, with it's "mere aggregation" clause making it clear that it's allowed.
The one thing you can't do if you're shipping a closed source application is link to GPL-licensed code (unless there's an special exception clause, or it's LGPL, or it's dual-licensed to allow this). But for this type of GPL library, you can't use the Linux distro's shipped version either. So the GPL constraint makes no difference to the question of whether you can ship a frozen or fallback version with your application in lieu of the distro version.
If there's a corner case the above doesn't cover, I'm not aware of it and I've studied GPL compliance more thoroughly than most people. So I'd like to know about it :-)
cgroups v1 might be the most irritating, because it was useful and something a shipped application or service might realistically use.
That's often a great idea!
But a full time hire? The GP's post implies that wouldn't make business sense for them, as even half a day occasionally on it is too much...
>> 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.
Of course an experienced Linux release engineer can do it faster and more reliably. That's probably the cheaper option. But the business still has to decide their Linux customer or user base is large enough, or strategically worth supporting, to justify the cost however they do it.
For many businesses even fractional Linux support is not justifiable for the small number of Linux users and support requests they're unable to handle. Though I can't imagine that being the case for Anthropic!
(Hint: This is one of the things I consult on, if anyone is looking to pay for quality Linux release engineering and platform testing. I have hundreds of historical and current Linux VMs, multiple architectures old and new (esp. x86, ARM and RISC-V), some of them embedded, fairly deep knowledge of how the kernel and libraries work together, and test harnesses. Also I test some compiled applications for portability across other OSes and architectures, including Windows, MS-DOS, MacOS, BSDs, SunOS, HP-UX, etc. going all the way back to the early Unix lineage.)
Obviously this will probably fail on other distros, but I've found in the past similar groupings. Backwards compatibility is different: I expect a package a compile on Ubuntu 24 not to work on Ubuntu 22.
This is anecdotal, and in the context of rust + EGUI, so I'm not sure how applicable it is to Electron.
I recently hit a Wayland snag: It doesn't support Device Events other than mouse movement. I worked around it by changing to Window events. I could see that being annoying if this substitution weren't acceptable, but it was in this case.
:)
It’s not a great experience if only some apps on supported on your favourite Linux distro while others aren’t.
You have taken on the work the distributions do in the open source world. No upstream open source developer takes that on. Instead of getting bug reports from users, upstream developers insist bug reports are filtered by the distro maintainer first. They fix problems on their side so you never see them, and the ones that do make it through have been triaged. It's a win for everyone.
So the solution is to handle it the way they do. Choose a couple of baselines: maybe Debian Stable and Fedora. Publish packages for them, and make it plain they are only certified for those platforms. Make the rest someone else's problem: if you want it working on distro X, you package it for distro X. You've done the bulk of the work for them anyway, as most of them are either Debian or RPM based.
The key words here are "open source", right? Some problems can't be solved without cooperation with the developer.
Those problems are the ones package maintainer forwards upstream.
It's well understood common and common workflow because lots of closed source packages are distributed by distro's now. Debian distributes firmware; Ubuntu and RedHat distribute closed source drivers.
So get to grips with "upstream"! Managing upset "opinionated" and "entitled" users is par for the course anywhere. Have a look at how Veeam do it, for example.
Obviously that sort of compatibility nonsense never happens in say Windows (fairly popular OS).
Let's take a quick look at say web proxies. Proxies are quite popular in corporate environments but blow me if Windows and vendors who use it make it as hard as possible to deal with:
You might think group policy would sort it all out - lol! You have loads of elderly policies relating to IE (several versions) hanging around smelling rather fishy and mildly useful if you have older Windows hanging around. You can use GPOs to fix the following but it will be Preferences and involve a bit of ingenuity.
You have .Net Framework apps - eg AD Sync (Entra, Smentra whatever its called today). That will need you to fiddle with a specific XML file.
winhttp api? Powershell. OK you have two sets of settings here: proxy and advproxy. proxy has string properties that you set and is a bit crap and advproxy has a JSON flavour and is a bit shit. advproxy seems to ignore anything in the ignore list apart from or exclusively <local>. At least advproxy allows you to fall back on a proxy.pac file (which IE decided to call wpad.dat and who can forget an IE5 version that called it WPAD.DA?)
Picking on Linux users is disingenuous - all OSs can be customized to the point of tricky to support and besides who on earth is Twitter?
Flatpak can be set up on many/most distros.
- titlebar
- tray icon w/light and dark mode support
- global keyboard shortcut
- redraw events after resizing
Those are a subset of the many items that don't play well between various distros.
Like Ubuntu Gnome w/X11 vs Pop!OS COSMIC w/Wayland or any of the tiling window managers like hyprland.
Consistency of titlebars has been dead in every OS for decades now. This is not even a flatpak problem anyway, but I do think wayland/gnome ought to have some kind of fallback decoration. This wouldn't even be meant to solve this problem, but would be a nice gesture for situations where a dev really don't care about how the decoration functions or looks, like when opening a game window or movie player like mpv or even just having a friction-less experience when creating your first window in a new app.
> tray icon w/light and dark mode support
Flatpak and specially gnome are championing the background app portals. I have reservations on how it's not a full replacement for tray icons, but Desktop Environments are free to implement it like a tray icon.
> global keyboard shortcut
AFAIK it's a solved problem, but there is an adoption lag for DE's and apps.
> redraw events after resizing
Not sure what you mean by that? Apps resize fine in flatpak
Every problem in flatpak can be addressed. It sucks they weren't addressed sooner but I suggest you look into the efforts being made for flatpak-next. Even right now it's the closest thing we got to a unified gui experience in linux.
Honestly, it sounds like you guys need to learn to say no. Worked at an OEM and we had device divers for RHEL. If you got it working on something else, good for you. But if you wanted to open a support case, you better be able to reproduce the bug on a supported version of RHEL.
I would occasionally humor people running CentOS if I had some spare cycles, but if you were on Debian the answer was: sorry, would love to help but I can’t.
The people who can’t understand why you have a tight support matrix are the people you don’t want to get sucked into the rabbit hole with anyway.
Maybe those same people can just prefer using OpenCode. It's at least free software, particularly if that old computer is running only free software with free firmware, and OpenCode can run free models.
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
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.
flatpak!
Apparently Linus Torvalds liked AppImage too.
Unfortunately they do, instead of implementing a proper native application (don't hire web developers to do native apps).
Look at e.g. Cisco Webex, or Telegram. You can make a proper native application that just works and is not electron. A lot of people don't like electron apps, and it is more important in current economy (memory prices are too high to invest in more RAM).
I’m pretty sure that excludes Claude Desktop.
https://www.techtimes.com/articles/317463/20260531/flathub-a...
There’s still a cost to testing, support, planning, etc even if coding is now “free”
AI doesn't solve this. You need humans who can understand and verify what is being made.
Jack Dorsey wants to prove you wrong!
They can work on feature X or feature Y -- which is the better choice?
Apparently they don't think Linux support is significant. I doubt the lack of support is due to technical constraints.
1) Develop software for linux
2) Provide decent support
But I am still waiting. If everything was as the hype folks said it was, we would all be fucked already.
They all have pros and cons. Pick the one that suits you best. Then you're also agent harness flexible (I use opencode).
> [1]: Was jai written by an AI coding agent? No. While this web site was obviously made by an LLM (ChatGPT read the man page, asked some follow-up questions, and produced a prompt from which claude code built a vitepress site), jai itself was hand implemented by a Stanford computer science professor with decades of C++ and Unix/linux experience. As an experiment, the author did previously try vibe-coding a container, but the results were disastrous and repeatedly put his machine in a state that required a reboot (e.g., recursively changing the attributes of all mounts in the wrong mount namespace). The author does use coding agents to look for bugs, get feedback, and develop tests. However, rest assured that a single human understands every line of C++ in jai.
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
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.
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.
"cleanupPeriodDays": 99999
Love your idea to actually index the conversations though!
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).
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.
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.
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.
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.
Things like "this is a holiday in country X but only for people living in province Y except for in town Z" are massive pain to script. Plus, if the issue tracker and source control automation were working correctly, I wouldn't need to read the status of both to get a good understanding of the situation. Any time scripting there should probably be spent (by someone else) on fixing the problem in the first place.
When Claude eventually doubles or triples the token cost to stop hemorrhaging money, I'm going to lose these scripts and I won't be upset about it in the least. But until then, my "somewhat understanding of context" script-but-not-really setup is proving quite useful.
0 8 * * 1-5 claude -p "Fetch my unread emails from the last 24 hours, identify urgent items, and provide a bulleted summary." >> ~/desktop/daily_email_summary.txt
Now, obviously - you might want something a little more elegant; but my point was that if you already grant Claude tool access to your email, slack etc - then it should be trivial to wrap it in a script, and run that from Cron.
I wouldn't do that; I don't trust Claude code with access to my mail (nor would I trust Claude desktop - but I don't use it anyway).
But, if you do trust Claude to read your slack and email, I don't see why Claude code couldn't do this for you almost out of the box?
I cannot stand this and do not know how to start a new project/session in a new folder. Even if I select a new folder in the UI when typing the first prompt of a new session, it keeps going back to the first folder I created. For this reason alone I am thinking of going to the CLI. But if anyone has any answers, I am all ears.
Other than that, I am happy with the CLI.
> Are you a Linux user? If so, are you sick of that lovely modal we made to tell you that there’s an update you need to go manually install? IF SO, boy do I have good news for you. We’ve ported our Rust-based updater to Linux, allowing Linux to update itself just like on Windows. Additionally, we now support .rpm and .pkg.tar.zst package formats for installation.
They have more challenging clients: have to deal with screencapture, audio capture, audio routing, meanwhile supporting 3 different package repositories. You just have to accept that you should be updating your build/runtime dependencies with each version as long as they fix your underlying problems. Having a single binary that you release and works, implies that you are shipping every library your binary depends on. Windows takes care of that with winsxs, Linux asks you to do it yourself.
Like... You already use Docker and deploy to K8S... On Linux...
Why would you not want your development environment to be as close to your deployment environment as possible? Even MacOS bash commands have hiccups every so often. In my experience working with Linux developers, they seem to know the internals of the servers much better and can optimize/debug prod fast - and this understanding is only compounded with LLMs.
I'm sure many developers would be equally talented at debugging such issues if we deployed on Windows or MacOS, but virtually no one does that.
I’m open for suggestions though
It’s really not that hard.
Which desktop? Which destop version? Which libc? Which versions of the gazillion of other libs it depends on?
I can take a Total Commander version from a time when it was called "Windows Commander", compiled for Win95, and it would still run in latest updated Win11. Try that with a linux program!
(BTW, for Total Commander it works the other way too: latest Tcmd still runs in Win95.)
> Publish an official Claude Desktop build for Linux, targeting the two current Ubuntu LTS releases (and Debian) as a signed .deb via an Anthropic-operated apt repository, using the same distribution pipeline Claude Code already uses for Linux.
Also Flatpak or AppImage would make this accessible to every other distro. Alternatively you could run the deb with a Podman Toolbox.
Your point about backwards compatibility with Windows goes both ways, I have old games that I can _only_ run on Linux as they don't work on modern versions of Windows.
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
For software development use of Claude, I'd be happy if the `claude` CLI executable does everything I need, within the Linux KVM VM sandboxes I create for the work, without a desktop client. The cleaner and more trustworthy, the better.
Also, for random interactive use of Claude for asking questions, I use it from my host desktop, sandboxed within the Web browser, and I want that to be well-supported. Someone marketing/product person at an AI company will naturally want to dark-pattern push people towards a proprietary desktop client, but that's one corner of abuse potential that we can still keep in check.
For agentic automation of my host desktop things and the things they have access to... no, thank you, the state of the art is not ready for that.
(Or x forwarding over ssh, or waypipie if you only need to access a gui application, not a desktop).
Are LLMs rendering people that useless?
That's me, and that sounds weird. Mind giving stone more details so I can help get to the source of it? Or just submit an issue on the repo. Should just be one main electron process.
"It'll make software easy and replace all software jobs!"
"Sorry, a Linux client is too hard and too much work!"
The Linux desktop is fragmented and gatekept in such a manner that most people of a reasonable mind aren't going to waste tokens on it, and damned sure not going to waste software/support engineer time on it.
Note that none of these complaints are about CLI or server software. "Linux" the kernel + GNU utils + shell handle all of this just fine. The year of the Linux desktop is just never going to happen unless one desktop standard takes over and 'wins' in the short to medium term.
Now, in the longer term when tokens run cheap maybe we'll successfully have 20 different competing, incompatible Linux deskstops, but it doesn't seem likely.
Until that point expect Linux desktop to be a third class citizen.
(Some for different aspects of full stack features, some for managing specific client situations advised by the codebase and its tools!)
The CLI is not designed to be lightweight, and it’s easy to get into situations where every CLI session consumes multiple GB of memory alone - stack them up and it’s a lot!
And not all terminal GUIs handle multiple tabs well enough to see all sessions at a glance.
So on top of the plugin features, desktop is a really useful thing to have!
I imagine this is part of the impetus behind the Bun acquisition - they have a deep need to push optimization efforts towards the specific patterns that are most relevant to their use cases. (Which are probably good ones for the broader Bun userbase, to be sure, but relative prioritization is something they now have greater control over.)
I know Claude is electron now but if they made it native swift on macos then they could use this
You build it for Ubuntu , people will demand fedora. Build fedora they’ll want Arch.
This is fine for FOSS projects where the community can fork and contribute, but as a company I can imagine tons of support tickets coming from Linux users who’s particularly DE/Distro permutation isn’t working right.
Still. An App Image would be nice
And even if it were a valid point, why would eye even waste a second of your life argumenting against Linux when it's being asked to a company with a projected 1 trillion dollars IPO.
What's your stake here?
However, I do think an app image or I guess a flatpak would be nice.
We give Claude full visibility into your Linux machine, with a JS runtime over the top for building tools.
Here, fixed it for you.
Supports linux :)
Surprised me it took so much scrolling to get to this.
Like, who reads all that crap?
Perplexity are devleoping Comet as an AI-powered browser. I wonder if anybody will take the OS leap.
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.
Did you just tell me to go fuck myself ?
This won't work for all Linux users, but that doesn't have to be the bar. Making a few linux builds for the most popular distros is incrementally better than saying it's Windows/Mac only.
There is already way too much slop.