Separate your Claude Desktop App by use case.

Rust and Tauri, chosen to avoid breaking anything

What CSW cares about most is not breaking the Claude data you already have. Switching accounts means swapping configuration files, so if that ever fails midway, your chat history or account sign-in could be lost. To contain that risk, the operations that could break something all live in one place: separating each environment's data, deciding where files belong, and protecting the data currently in use. All of this sits in one shared Rust component (crates/core), and both the command-line tool (csw) and the desktop app (crates/desktop) simply call into that same component. With the risky work in a single place, there is only one place to review.

On deletion paths, the directory currently in use is always excluded from what gets removed. When swapping a shared configuration file, the original is moved to a backup first, then replaced. We chose Rust because these promises can be checked automatically, by the machine, before the program even runs, at compile time. Write code that breaks a promise and it stops with an error at that stage and never reaches the step that builds the distributable. In other words, a mistake that violates a defined promise is caught before it ships. We pair this with tests and err on the side of safety.

The GUI is built with Tauri v2. It renders through WebKit, the display engine already built into macOS, so the app does not bundle a whole browser engine of its own. That keeps the distributable small: the build covering both Intel and Apple Silicon is about 7 MB as a DMG. Code signing and notarization, where Apple confirms the app's identity, also run through Tauri's standard distribution flow.

For native macOS UI, Apple's Swift and SwiftUI would be the first choice. But CSW's heart is the systems work of swapping files and settings safely, not the screens, and there is not much UI. So we prioritized being able to check that underlying logic with the compiler and tests, and chose Rust and Tauri. A different kind of app would call for a different choice.

Why this fits autonomous AI development

We develop CSW by running several AI agents at once, dividing up research, implementation, and verification. For example, one agent writes code and another reviews it critically, asking whether anything here is wrong.

At that point, arguing over personal preference settles nothing. So the basis for judgment is the compiler's type checks, the warnings from clippy, which flags how the code is written, and whether cargo test passes or fails. None of these are open to interpretation; the machine decides plainly whether each one passes or fails. That makes them a shared yardstick when agents disagree.

Rust is typed and compiled before it runs, so whether a change holds up comes back early and in fine detail. That fast, fine-grained response pairs well with a loop where an agent fixes something itself and then checks again. This is not a dismissal of other languages. It simply means we wanted to put something the machine can judge clearly, rather than personal taste, at the center of how we work.

That said, passing compilation and tests only confirms the code does what it was written to do. It does not confirm that it matches what we actually meant to build. A button might work correctly yet be placed in the wrong spot, and that kind of mismatch slips through. So we add other gates as well: rendering the screen and checking it by eye, and auditing the app and the documentation against each other in both directions.

Keeping design and writing standards as "skills"

The look and the words on this site and in the app are not decided on a whim; they follow standards we keep as text in the repository, which we call "skills." They branch out from one root file (CLAUDE.md) into a skill file per topic, so whoever, or whichever AI, does the work can return to the same standard.

Japanese typesetting, for instance, is gathered in a skill called japanese-typography-qa. Before we applied it, the top headline broke across three lines with only one or two characters left on the last, the font was too large, and the section heading below it looked bigger than the headline above. Applying the skill's rules, breaking lines at phrase boundaries and putting every text size on a single ratio, gave it the fit it has now.

The overall look is judged by skills like design-taste-frontend and minimalist-ui. This column, for example, first wrapped each of its three topics in its own box; but the more boxes there are, the busier the screen gets and the more the eye wanders over where to read. Following the skill's guidance to not box things in needlessly and to keep body text to a width the eye can follow across one line, we dropped the boxes and divide with just the thin line above. The text you are reading now is held to a width your eye can flow across.

Mismatches between the writing and the app are caught by an audit called /audit-consistency, which cross-checks the app's screens against the documentation and this landing page in both directions. Earlier, for example, the landing page said you could use several environments at the same time, while the app, to prevent settings from colliding, was built so that several Claude instances cannot be open at once. The description and the actual behavior disagreed, so we first aligned both to "one at a time." Later we worked out that a "separate everything" environment shares nothing and can run side by side safely, so we enabled concurrent windows for fully-isolated environments and brought the description back in line with the implementation.

These skills are a way to write down why we build things the way we do, so that when someone else, or another AI, picks up the work later, they can return to the same approach. They are not magic that raises quality on its own; they are the foundation for setting a standard and then staying with it.