Cindy: A local AI agent that orchestrates Claude Code and Codex
An AI agent that puts Claude Code, Codex, and local tools on desktop and mobile, remembers workflows, and runs tasks automatically.
GitHub makecindy/cindy Updated 2026-10-25 Branch main Stars 4.1K Forks 588
TypeScript Electron Expo / React Native Claude Code Codex MCP Local AI agent pnpm monorepo

🧭 Decision Guide

Try it if you

  • You want to share agent workflows between an Electron desktop client and an Expo / React Native mobile client.
    The README section “What's in this repo” lists apps/desktop, apps/mobile, and packages/*.
  • You already use Claude Code or Codex Coding Plan and want to continue using it inside Cindy.
    The README says you can authorize an existing Claude Code / Codex Coding Plan without duplicate billing.
  • You need MCP connections to internal tools and reusable Memory, Skills, and Automation across harnesses.
    The README section “Yours to shape” lists Memory, Skills, Automation, and MCP.
  • You want to run local agents on your machine without signing in to a Cindy account.
    The README's “Skip Sign-In” mode requires no Cindy sign-in and runs local agents.

Skip it if you

  • You must self-host the backend instead of connecting to Cindy's official cloud.
    The README states that the backend service is in a separate repository and that the client connects to official cloud services by default.
  • You require analytics and online heartbeats to be fully disabled in official distribution builds.
    The README section “Privacy & telemetry” says official builds include TapDB and send an online heartbeat after sign-in.
  • Your development environment can only use pnpm v11 or a Node.js version other than 22.x.
    The README section “Prerequisites” requires Node.js 22.x and pnpm 10.x, noting that v11 is not supported.
  • You depend on a completed plugin marketplace or team distribution for Skills.
    The README marks the Plugins open marketplace and team sharing for Skills as “in the making.”

Requirements

  • Node.js 22.x
  • pnpm 10.x (v11 is not yet supported)
  • Git LFS
  • Git; pnpm install downloads claude-code, codex, and ripgrep per platform
  • Android Windows packaging fetches pinned-version, sha256-verified Android platform-tools before packaging

First step (verbatim from README)

git clone https://github.com/makecindy/cindy.git

Watch out

  • Do not treat Skip Sign-In as a local server; the README says it runs local agents and disables server-backed capabilities.
    The README's “Skip Sign-In” description.
  • Remote desktop development must explicitly choose --region=cn or --region=global instead of relying on the internal default.
    The README section “Development entry points” provides two pnpm restart:desktop:remote commands and says not to rely on the internal default.
  • Source builds can disable TapDB, but mobile must omit clientId / clientToken and desktop must remove initTapdb().
    The README section “Privacy & telemetry” describes handling in apps/mobile/src/analytics/mobileTapdb.ts and apps/desktop/src/renderer/index.tsx.
  • SkillHub uses both skillhubApiBaseUrl and cindySkillHubApiBaseUrl, and current clients do not fall back to the legacy field.
    The README section “Skill Hub migration” describes both manifest fields and current client behavior.

Alternatives

  • Claude Code:When you only need the Claude Code harness and do not need Cindy's Memory, MCP, mobile client, or multi-harness orchestration.
    README section stating “The first supported harnesses are Claude Code and Codex”
  • Codex:When you only need the Codex harness and do not need the Electron or Expo / React Native client integration.
    README section stating “The first supported harnesses are Claude Code and Codex”

Not stated in the README

  • The README does not specify the complete supported desktop and mobile OS versions.
  • The README does not provide a compatibility matrix for Claude Code, Codex, API keys, and local models.
  • The README does not provide exact pricing, quotas, or usage-deduction rules for the Cindy hosted service.
  • The README does not provide the separate backend repository address, deployment steps, or self-hosting license.
  • The README provides no performance or reliability data for Memory, Skills, or Automation on complex tasks.
  • The README does not state the exact pinned version of Android platform-tools.

💡 Deep Analysis

6
Yes I maintain both the Electron desktop client and the Expo/React Native mobile client, and can install Node.js 22.x, pnpm 10.x, and Git LFS; is this repository suitable as a contribution entry point?
For: A TypeScript contributor working on the Electron desktop app and Expo/React Native mobile app whose development machine must use fixed Node.js and pnpm versions

Yes, because the repository is a pnpm monorepo containing desktop, mobile, and shared packages, and the README defines a concrete contributor environment. The conditions are:

  • apps/desktop uses Electron, while apps/mobile uses Expo / React Native.
  • packages/* contains shared authentication, device-link, agent orchestration, and model-provider capabilities, making it suitable for cross-platform changes.
  • The environment must use Node.js 22.x and pnpm 10.x; pnpm 11 is explicitly unsupported, and Git LFS is required.
  • Remote development requires choosing cn or global according to the account region and uses official cloud services; the backend is not in this repository.
  • What's in this repo: apps/desktop — Electron desktop client
  • What's in this repo: apps/mobile — Expo / React Native mobile client
  • What's in this repo: packages/* — Shared client capabilities
  • Prerequisites: Node.js 22.x; pnpm 10.x (v11 is not yet supported); Git LFS
git lfs pull
Not stated in the README:The provided README excerpt does not list all desktop and mobile validation commands.;It does not state how closely mobile functionality matches the Electron desktop client.;It does not state whether contributors need additional cloud accounts or internal access.
Yes I want to audit and fork a TypeScript-heavy AI client, including its desktop, mobile, and device-toolchain code, and require Apache-2.0 licensing; is this repository a suitable fork base?
For: A TypeScript engineer who wants to audit and extend an open-source AI client while requiring controlled dependency sources and Apache-2.0 licensing

Yes, especially as a basis for auditing and forking the client layer; it is not a self-contained source tree for the complete Cindy service. The relevant facts are:

  • TypeScript is the main language, and the repository includes Electron desktop, Expo/React Native mobile, and shared packages.
  • The README explicitly licenses the source under Apache-2.0 and invites users to audit, fork, and extend it.
  • claude-code, codex, and ripgrep are downloaded per platform, while Android platform-tools are pinned and SHA-256 verified before Windows packaging, making supply-chain entry points inspectable.
  • The backend is not in the repository, and official endpoints and auto-updates default to Cindy infrastructure; forking the client is not equivalent to full self-hosting.
  • README quote: Source — audit, fork, extend, and contribute improvements back under Apache-2.0
  • Project data: main_language is TypeScript; license is Apache License 2.0
  • What's in this repo: apps/desktop, apps/mobile, packages/*
  • What's in this repo: tool binaries are downloaded per platform; Android platform-tools are pinned and sha256-verified
pnpm install
Not stated in the README:The README excerpt does not list the separate licenses of all third-party dependencies, model weights, and tool binaries.;It does not state which features remain independently usable after replacing official service endpoints.;It does not explain how to replace the default auto-update, SkillHub, and model-provider infrastructure.
Yes I already use Claude Code Coding Plan and Codex Coding Plan for TypeScript projects; is Cindy suitable if I want to switch between both harnesses during one task while preserving workspace, memory, and tool state?
For: A TypeScript developer who already pays for Claude Code or Codex Coding Plan and wants to switch models and agent harnesses inside real code projects

Yes, because the README explicitly lists Claude Code and Codex as the first supported agent harnesses and supports switching during a task. The relevant conditions are:

  • Models and harnesses can be mixed freely while workspace, memory, skills, and tools remain continuous.
  • One task can be planned, executed in parallel, and reviewed by different harness × model combinations.
  • Existing Claude Code / Codex Coding Plans can be authorized, with no duplicate subscription bill according to the README.
  • Other harnesses are not yet listed as supported, and permission or context behavior may differ between harnesses.
  • README quote: The first supported harnesses are Claude Code and Codex
  • README quote: Models and harnesses mix freely and can switch mid-task while your workspace, memory, skills and tools stay continuous
  • README quote: authorize the Claude Code / Codex Coding Plan you already pay for and keep using it inside Cindy — no duplicate bill
pnpm restart:desktop:remote --region=global
Not stated in the README:The README does not specify which context formats are fully interoperable when switching between Claude Code and Codex.;It does not detail all permissions, quotas, or billing boundaries of existing Coding Plans.
It depends I work on macOS or Windows with internal code and logged-in browser sessions, and cannot send my working directory directly to a third-party platform; can I skip Cindy sign-in and still use local agents?
For: A macOS or Windows developer who wants code, browser sessions, and local files to stay on the work machine while still using agent automation

It depends: Cindy can run local agents without a Cindy account, but this is not full self-hosting and server-backed capabilities are unavailable. The relevant facts are:

  • Selecting “Skip Sign-In” leaves the app in a “Not signed in” state and enables local agents.
  • Server-backed capabilities are unavailable, and the backend is in a separate repository rather than this one.
  • The README says Cindy works with real local files and logged-in apps, but the actual privacy boundary still depends on the selected model, agent, and tools.
  • Official clients connect to Cindy cloud services by default, and desktop auto-updates come from the official CDN, which may not satisfy strict isolation requirements.
  • README quote: Skip Sign-In ... to use local agents; Server-backed capabilities are unavailable
  • README quote: Cindy runs locally on your own machine, using your real files and logged-in apps
  • What's in this repo: the backend service lives in a separate repository
  • README quote: the client connects to Cindy's official cloud services by default
git clone https://github.com/makecindy/cindy.git
Not stated in the README:The README does not state whether each local agent may call an external model service.;It does not document the complete data flow for browser sessions, file contents, and tool calls in skip-sign-in mode.;It does not provide a complete self-hosted backend deployment procedure.
It depends We have internal tools and business systems and want to connect them through MCP, then run recurring agent tasks with result reporting; given that the backend is not in this repository, can we treat Cindy as a complete enterprise automation platform?
For: An engineer on a small team who needs to connect internal business systems to an agent and run recurring enterprise workflows

It depends: the client points toward MCP, Skills, and recurring automation, but this repository alone is not a complete enterprise platform and cannot replace the separate cloud backend or organizational controls. The evidence is:

  • The README lists MCP for connecting internal tools and business systems to the agent.
  • Automation supports recurring work, self-execution, and result reporting; Skills can capture reusable workflows, while team sharing is still in progress.
  • The repository is explicitly a desktop/mobile client, and the backend service lives in a separate repository.
  • Account, regional routing, permissions, auto-update, and data policies are not covered by this repository alone, so enterprise audit, approval, and rollback capabilities require separate verification.
  • Yours to shape: Automation — recurring work schedules itself, runs itself, reports back
  • Yours to shape: MCP — wire your internal tools and business systems into her reach
  • Yours to shape: handing Skills to your team is in the making
  • What's in this repo: the backend service lives in a separate repository
Not stated in the README:The README does not specify MCP authentication, permission granularity, approval for writes, or retry behavior.;It does not specify scheduling precision, concurrency limits, or retention of execution logs.;It does not document enterprise SSO, auditing, or data-residency capabilities of the separate backend.
Yes I work across Windows, macOS, or Linux and also need an agent to operate an iOS or Android phone; is Cindy suitable if I want one client to preserve workspace and device connectivity across tasks?
For: A user working across Windows, macOS, or Linux desktops and an iOS/Android phone who wants an agent to operate real devices

Yes, although cross-device behavior remains subject to platform permissions and implementation differences. The README and project data show that:

  • The project provides an Electron desktop client and an Expo / React Native mobile client, with topics covering Windows, macOS, iOS, Android, and Linux.
  • Cindy can drive a browser, computer, and phone, and can receive work from IM and schedules.
  • Shared packages include device-link and agent orchestration, supporting reuse of device connectivity and task coordination.
  • Android platform-tools are fetched at a pinned version and SHA-256 verified; however, the README does not guarantee identical background, permission, or automation behavior across systems.
  • What's in this repo: Electron desktop client; Expo / React Native mobile client
  • README quote: She can drive your browser, computer and phone, and take work from IM and schedules
  • What's in this repo: Android platform-tools binaries are fetched (pinned version, sha256-verified)
  • Project data topics: android, ios, macos, windows, react-native, electron
pnpm install
Not stated in the README:The README does not specify the exact device operations currently available on iOS and Android.;It does not document mobile background tasks, device pairing, or reconnection behavior.;It does not specify how Linux computer-control capabilities differ from Windows and macOS.

✨ Highlights

  • Claude Code and Codex can switch within one task
  • Memory, Skills, and Automation support reusable workflows
  • MCP can connect internal tools and business systems
  • It provides both Electron desktop and Expo mobile clients
  • Official client builds connect to Cindy cloud services by default
  • Apache-2.0 licensed and already has 4,106 GitHub stars

🔧 Engineering

  • The Electron desktop and Expo / React Native mobile clients share packages for agent orchestration.
  • It can work with local files and logged-in apps, and drive browsers, computers, and phones.
  • Skip Sign-In runs local agents but does not provide server-backed capabilities.
  • It supports your own API keys, Claude Code / Codex Coding Plan, or local models.

⚠️ Risks

  • The backend is outside this repository, so full cloud capabilities depend on Cindy services.
  • Server-backed capabilities are unavailable when using Skip Sign-In.
  • Official builds include TapDB and send account heartbeat data after sign-in.
  • The project requires Node.js 22.x and pnpm 10.x; pnpm v11 is not supported yet.
  • The plugin marketplace and team sharing for Skills are still in the making.

👥 For who?

  • Development teams that need to reuse Claude Code and Codex workflows across desktop and mobile.
  • Client developers working with TypeScript, Electron, or Expo / React Native.
  • Users who want MCP integrations with internal systems while retaining local file access.
  • Individual developers who accept Cindy cloud endpoints or only need local agents.