# Cindy (makecindy/cindy): an open-source AI agent client that runs on your machine

> Cindy is a pnpm monorepo for an Electron desktop app and an Expo mobile app that wrap Claude Code and Codex harnesses behind one agent. The client is Apache-2.0; the backend is not in this repository.

**makecindy/cindy** — Consider it done. The open-source AI agent that works out of the box AI Agent .

- Repository: https://github.com/makecindy/cindy
- Website: https://cindy.app
- Stars: 2,815 · Forks: 426
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/makecindy-cindy

## What Cindy solves, and who it is actually for

Most agent tooling makes you choose one harness and one model, then rebuild your context every time you switch. Cindy's pitch is the opposite: the README describes mixing harnesses and models freely, switching mid-task while workspace, memory, skills and tools stay continuous, and even having one task planned, executed in parallel, and reviewed by agents on different harness and model combinations. The first supported harnesses are Claude Code and Codex, with more being added and a native harness described as in the works.

The repository is the open-source client only. That distinction matters more than the feature list. If you want the hosted product, you sign in with a Cindy cloud account. If you want to read, fork or extend the thing that runs on your machine, this is the repository you clone. The README is explicit that the backend service lives in a separate repository and is not part of the monorepo, so anyone expecting to self-host the whole stack from this checkout will not find it here.

The intended user is a developer who already pays for a Claude Code or Codex coding plan and does not want a duplicate bill. The README lists four ways to bring models: sign in to the official Cindy service with usage deducted, authorize an existing Claude Code or Codex Coding Plan and keep using it inside Cindy, connect your own API keys, or use local models. That fourth option is the one that makes Cindy interesting to people working with sensitive codebases, since local models keep inference on the machine alongside the files.

## The monorepo layout and how the pieces connect

Cindy is organized as a pnpm workspace. The README's table names `apps/desktop` as an Electron desktop client, `apps/mobile` as an Expo / React Native mobile client, and `packages/*` as shared client capabilities covering auth, device-link, agent orchestration and model providers. The `apps/*-bin` directories hold tool binaries shipped with the desktop app, and the README states none of them are committed: claude-code, codex and ripgrep are downloaded per platform by `pnpm install`, while Android platform-tools binaries are fetched with a pinned version and sha256 verification before Windows packaging.

That download-on-install design explains the prerequisites. `package.json` sets `engines.node` to `>=22.12` and `engines.pnpm` to `>=10.7 <11`, and pins `packageManager` to `pnpm@10.33.2`. The README repeats the constraint in prose, noting that pnpm v11 is not yet supported. Supported architectures in `package.json` are win32, darwin and linux on x64 and arm64 with glibc, which tells you the desktop client is not aimed at musl-based Linux distributions.

The client talks to Cindy's official cloud services by default. Endpoint manifests live in `config/endpoint.json` and `config/endpoint.global.json`, and desktop auto-updates come from the official CDN. The README frames this as deliberate: external developers do not need to self-host a server, they sign in with their own Cindy account in a dev build and test against the official servers. There is a Skip Sign-In path on the login screen that runs local agents without a Cindy account, shown in the app as "Not signed in", but the README states server-backed capabilities are unavailable in that state. Skip Sign-In is not a connection to a local server, and the README says so directly.

## Installing the client and reaching a first running agent

Before cloning, confirm Node.js 22.x, pnpm 10.x and Git LFS are present. The README lists all three as prerequisites, and the LFS step is not optional because large assets are tracked through it. The minimal entry point from the README is four commands:

```bash
# Requires Node.js 22.x, pnpm 10.x, Git LFS
git clone https://github.com/makecindy/cindy.git
cd cindy
git lfs pull
pnpm install
```

Expect `pnpm install` to take a while and to fetch binaries. The README states that claude-code, codex and ripgrep are downloaded per platform at install time, so the command is doing more than resolving npm packages. If you are on Windows and packaging later, Android platform-tools binaries are fetched at that point with a pinned version and sha256 verification.

The README points contributors at `CONTRIBUTING.en.md` for full desktop, mobile, data-isolation and validation workflows, and that is where dependency updates and access requirements live. For development against the official servers, the README gives two region-specific entry points:

```bash
# Mainland China Cindy account
pnpm restart:desktop:remote --region=cn

# Global Cindy account
pnpm restart:desktop:remote --region=global
```

Remote development uses your own Cindy cloud account and existing login state, so existing sessions continue while you work on the client. The README warns against relying on the internal default region and says to use `cn` for Mainland China accounts and `global` for everyone else. If you would rather not sign in at all, choose Skip Sign-In on the login screen; the app then shows the account state as "Not signed in", and server-backed capabilities are unavailable.

## Where Cindy is the wrong tool

The most obvious boundary is the missing backend. This repository is the client. If your requirement is a fully self-hosted agent stack with no dependency on a vendor's cloud, the README does not offer that path, and the endpoint manifests pointing at official services make the default posture clear. Skip Sign-In exists, but it disables server-backed capabilities, so it is a reduced mode rather than a self-hosted one.

The release line is also early. The most recent tag at the time of writing is v0.1.67-beta, pushed on 2026-08-28, with v0.1.66 and v0.1.64 in the days before. A 0.1.x series with a beta at the tip is not a signal that interfaces have settled, and the README's own roadmap language supports that reading: a native harness is described as in the works, plugins and an open marketplace are marked as in the making, and handing skills to a team is likewise described as in the making. Anyone who needs those features today will be waiting.

Telemetry is another decision point. The README states that official distribution builds include TapDB usage analytics for product-level aggregate statistics, covering device, OS and app-version metadata, and associated with your account ID after sign-in. If you build from source and do not run official distribution builds, that specific arrangement does not describe your binary, but you should read the privacy section in full rather than assume. Finally, the platform matrix in `package.json` lists glibc only, so Alpine and other musl environments are outside the supported set for the desktop client.

## How Cindy differs from running Claude Code or Codex alone

The natural alternative is installing Claude Code or Codex directly and using each on its own. Those tools are single-harness by design: you pick one, and its context, memory and configuration live with it. Cindy's difference is that it treats harnesses as interchangeable backends behind one client, with shared memory, skills and tools persisting across a switch. The README's claim that one task can be planned, executed in parallel and reviewed by agents on different harness and model combinations is a direct consequence of that design, and it is the thing a single-harness setup cannot do at all.

The second difference is billing. If you already pay for a Claude Code or Codex Coding Plan, Cindy lets you authorize that plan and keep using it inside the client, which the README describes as avoiding a duplicate bill. Running the harnesses directly gives you the same plans, of course, but you lose the shared workspace and the multi-harness orchestration layer. If you do not care about either, the extra Electron app and the monorepo build are overhead.

The third difference is scope. Cindy's README says she can drive your browser, computer and phone, and take work from IM and schedules. That is a broader surface than a terminal coding agent, and it comes with a broader permission surface too. The repository's own security note is blunt: never commit credentials or authorization files to the working tree, and report issues privately through `SECURITY.en.md` rather than opening a public issue. If you are going to let an agent touch a logged-in browser and a phone, read that file before you wire up accounts.

## Maintenance, upgrade cost and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-08-28, which is recent enough that the project is being worked on. The cadence visible in the release list is fast: v0.1.64 on 2026-08-26, v0.1.66 on 2026-08-27, v0.1.67-beta on 2026-08-28. A tag every day or two during a working week means you should expect to pull often if you track `main`, and it also means pinning to a specific tag is the calmer choice for anything you depend on.

Upgrade cost is concentrated in `pnpm install`. Because the desktop tool binaries are downloaded per platform rather than committed, a fresh install or a dependency bump can pull new claude-code, codex or ripgrep builds, and the Android platform-tools fetch is pinned and sha256-verified. The `pnpm` block in `package.json` also carries a long list of overrides, including pins for `@anthropic-ai/sdk`, `zod`, `tar` and `sharp`, plus two patched dependencies: `harmonyos-sans-sc-webfont-splitted` and `react-native@0.85.3`. Those patches are applied from `dependency-patches/`, so an upstream React Native bump is not a one-line change in this repo.

Licensing is Apache-2.0 at the repository root, with a `NOTICE` file alongside it. Contributions go through pull requests into `main`, every commit needs a Developer Certificate of Origin sign-off via `git commit -s`, and a DCO check on each pull request enforces it. The README states no CLA is required. Note the split between the client and the service: the source here is Apache-2.0, but using the hosted service is governed by the pricing and service terms at cindy.app, which is a separate question from the code licence. This is not legal advice; read `LICENSE` and `NOTICE` yourself.

## Conclusion

Adopt Cindy if you already pay for a Claude Code or Codex coding plan and want a local agent that drives your real files, browser and phone without a second bill, and if you are willing to build the client from source with Node.js 22.x and pnpm 10.x. Do not adopt it if you need the backend, because the README states the service lives in a separate repository, or if you need a stable release line, since the newest tag at the time of writing is v0.1.67-beta. Verify first that Git LFS is installed and that `git lfs pull` succeeds before `pnpm install`, because the desktop tool binaries are downloaded per platform at install time and none are committed.

## FAQ

### What does the name Cindy mean in this project?

The repository does not explain the origin of the name. The README describes Cindy as an open-source AI agent that works out of the box, and the monorepo's `package.json` lists the author as XD Inc.

### How do I install the Cindy client?

Clone the repository, pull Git LFS assets, then run `pnpm install` with Node.js 22.x and pnpm 10.x present. The README states that claude-code, codex and ripgrep binaries are downloaded per platform during that install step.

### Can I use Cindy without signing in to a Cindy account?

Yes. The README says to choose Skip Sign-In on the login screen to use local agents, and the app then shows the account state as "Not signed in". Server-backed capabilities are unavailable in that state, and it is not a connection to a local server.

### Is the Cindy backend included in this repository?

No. The README states that the backend service lives in a separate repository and is not part of the monorepo. This repository is the client: the desktop and mobile apps plus their shared packages.

## Sources

- [Official documentation](https://cindy.app)
- [Official README](https://github.com/makecindy/cindy#readme)
- [Project repository](https://github.com/makecindy/cindy)
- [Release notes](https://github.com/makecindy/cindy/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/makecindy-cindy