Cindy is an open-source client that aims to turn Claude Code, Codex, and other tools into a local agent capable of acting on your projects. My short verdict: it’s promising, already interesting for tinkering with dev agents, but not yet the frictionless consumer product its tagline suggests.
What is Cindy?
Cindy presents itself as an open-source AI agent that runs on your machine, with an Electron desktop app, an Expo mobile app, and shared packages. The GitHub repo I tested is the client, not the official cloud backend.
The idea is simple: instead of having one separate tool for Claude Code, another for Codex, and then scripts around them, Cindy wants to unify the experience. It brings together useful concepts: memory, skills, automations, MCP, multi-agent orchestration, a browser, local files, and messaging integrations.
In practice, the repo is a large pnpm monorepo. It also installs runtime binaries, notably Claude Code, Codex, ripgrep, and pi. That’s important, because Cindy doesn’t reinvent everything. It assembles existing agent building blocks inside a local interface and runtime.
| Tested item | Result |
|---|---|
| Repo | makecindy/cindy, commit 6238a82c |
| Stack | Node 22, pnpm 10, Electron, React, Expo |
| Launched product | Dev desktop client and embedded Codex runtime |
| LLM | Local OpenAI-compatible proxy, model gpt-5.5 for the successful test |
| License | Apache 2.0 |
Installing Cindy
The documentation calls for Node 22, pnpm 10, and Git LFS. I cloned the repo, initialized the public cindy-protocol submodule, then kicked off the install.
git clone https://github.com/makecindy/cindy.git /tmp/cindy
cd /tmp/cindy
git submodule update --init --recursive cindy-protocol
git lfs pull
pnpm install
First honest point: this is not a small install. The monorepo is heavy, and the binaries downloaded during postinstall are substantial. In my container, /tmp was limited to 512 MB. So I kept the clone in /tmp as planned, then copied the checkout into a larger temporary space to install and run the product.
Second point: I hit an install bug on the pi runtime. The script tried to extract a .tar.gz archive with a tar invocation that didn’t pass the gzip option in that environment. I patched the temporary working copy to finish the install. After that, Cindy properly downloaded and verified the Claude Code, Codex, ripgrep, and pi runtimes.
Using Cindy
I tested two paths, since Cindy is both a desktop app and a wrapper around agent runtimes.
First, I launched the Electron desktop app in development mode, with an isolated data sandbox. As instructed, I exported the LLM proxy variables before launching:
export OPENAI_BASE_URL=http://172.17.0.1:8790/v1
export OPENAI_API_KEY=sk-proxy
export OPENAI_API_BASE=http://172.17.0.1:8790/v1
export OPENROUTER_BASE_URL=http://172.17.0.1:8790/v1
export OPENROUTER_API_KEY=sk-proxy
The Vite and Electron build actually starts. I watched the main, preload, and worker bundles compile, the Electron UI launch, TapDB remain disabled in dev, and then the renderer load. Running as Docker root, you have to bypass the Electron sandbox with --no-sandbox, which is not a production posture, but it’s standard in this kind of test container.
The desktop result is mixed: the UI starts, but the renderer eventually crashed on a Vite dynamic module error after a few minutes. So I wouldn’t sell the source-based desktop path as smooth for an average user on containerized Linux.
Next, I tested the concrete use case I actually cared about: can the agent runtime shipped with Cindy modify a small project and validate the result?
I created a deliberately vulnerable tiny JavaScript service: an isAllowed(ip) function that only blocks 127.*, while the test demands rejecting the private ranges 10/8, 172.16/12, and 192.168/16 as well. Then I ran the Codex bundled by Cindy with the OpenAI-compatible proxy.
apps/codex-bin/linux-x64/codex exec \
--dangerously-bypass-approvals-and-sandbox \
--skip-git-repo-check \
--cd /tmp/cindy-usecase \
-m gpt-5.5 \
"Use shell commands to inspect and edit files. Fix service.js so private IPv4 ranges 10/8, 172.16/12 and 192.168/16 are denied, then run node service.test.js."
The first attempt with the normal sandbox failed because of bubblewrap and the container’s unprivileged namespaces. That’s an environment limitation, but it matters for a DevOps freelancer: an agent that depends on a system sandbox should fail cleanly, or offer a clear strategy.
In bypass mode, isolated in my container, Codex did the job. It read service.js, read service.test.js, modified the file, then ran node service.test.js. The final test came back with:
tests ok
The final file produced by the agent was simple and correct:
function isAllowed(ip) {
const parts = ip.split('.').map(Number);
const [a, b] = parts;
return !(
a === 10 ||
(a === 172 && b >= 16 && b <= 31) ||
(a === 192 && b === 168)
);
}
module.exports = { isAllowed };
What I like about Cindy
What I like most is the pragmatic ambition. Cindy doesn’t just promise yet another chat. The project genuinely tries to connect already-known agents to local files, sessions, tools, crons, and workflows.
I also like that the repo is auditable. For a security and DevOps profile, that’s essential. Provider keys are treated as local secrets, binaries are downloaded with SHA verification, and TapDB telemetry is disabled in dev.
Finally, the Codex runtime shipped in the repo actually produced something in my test. Not a marketing reply, not just a successful launch. It modified a file and made a test pass.
Cindy’s limitations
The main limitation is complexity. Installing Cindy from source requires a precise environment, a lot of dependencies, heavy binaries, and a bit of patience.
The second limitation is the separation between the open-source client and the full service. The public repo doesn’t contain the backend. For some features, you need a Cindy cloud account or you have to accept staying in a more limited local mode.
The third limitation is operational: the Codex sandbox didn’t work in my container without a bypass, due to namespace restrictions. In prod, I want a sandbox. In Docker testing, I accepted the workaround because the environment was already isolated. This is not a general recommendation.
Should you adopt Cindy?
My verdict: worth trying if you’re building or evaluating dev agent workflows. Worth adopting only if you’re ready to invest time in the environment, the providers, and the sandbox constraints.
For a security or DevOps freelancer, Cindy is interesting as a local orchestration lab. For a non-technical user who just wants to click and delegate, I’d recommend waiting for a stable distributed release or using the official service instead.
Does it actually work? Yes, on the Codex runtime, I got a modification verified by a test. No, not yet as a fully smooth source-based desktop experience in my environment.
FAQ
Is Cindy free?
The open-source client is under the Apache 2.0 license. Some features may depend on the official Cindy service, your Claude Code or Codex subscriptions, or your own API keys.
Can you use Cindy without a cloud account?
The README mentions a Skip Sign-In mode for local agents, with server features unavailable. In my test, I mostly validated the dev desktop launch and the local Codex runtime.
Is Cindy production-ready?
Not from source code, based on my test. The project is solid and ambitious, but the install process, the sandbox, and the dev desktop still require a technical profile.