Cindy x Nowledge Mem

Cindy is an open-source local agent host. It can run Claude Code, Codex, Pi, and other harnesses while keeping one workspace, memory, skills, and tool surface continuous.

Nowledge Mem supports Cindy today through MCP and shared skills. Cindy-native transcript sync is intentionally not enabled yet because Cindy's public client does not expose a stable third-party message export, post-turn hook, or verified Ghost package install path for lossless import.

Setup

Make sure Nowledge Mem is running, then generate the Cindy MCP config from the same nmem client settings you use everywhere else:

nmem status
nmem config mcp show --host cindy

In Cindy, add a custom MCP server named nowledge-mem using the generated URL and headers. For local desktop Mem, that points to http://127.0.0.1:14242/mcp/. For Nowledge Cloud, Access Anywhere, or a self-hosted server, the generated block carries the right remote endpoint and authentication shape for your current nmem config.

If your Cindy build accepts shared Agent Skills or Agent Plugins packages, add the shared Nowledge Mem package:

https://github.com/nowledge-co/community/tree/main/nowledge-mem-agent-plugin

If that package flow is not available yet, copy the guidance from:

https://github.com/nowledge-co/community/tree/main/nowledge-mem-cindy-connector/guide.md

MCP is the required path. Skills or guide text are the behavior layer that teaches Cindy when to read Working Memory, search prior work, save durable lessons, and create handoffs.

What You Get

• Working Memory and Context Bundle through Mem MCP
• Memory search and thread search while Cindy works
• Durable memory saves for decisions, procedures, preferences, and debugging lessons
• Library and graph tools when your Mem server exposes them
• Reusable behavior guidance inside Cindy sessions
• Local or remote Mem support through the shared nmem client config

Child Runtime Capture

Cindy can run several harnesses inside one app. Treat transcript capture as belonging to the runtime that actually produced the conversation:

This keeps source_app honest. A Codex transcript launched from Cindy should still be a Codex thread. Cindy is the host; the child runtime produced the transcript.

If Cindy represents a durable persona or worker in your Mem setup, set that identity separately:

NMEM_AGENT_ID=cindy

That selects the Mem AI Identity. It does not change the transcript source.

Current Thread Sync Boundary

Cindy's public repo shows an MCP-capable app, shared skills, a Ghost plugin runtime, and local desktop session storage. Ghost can package skills, tools, and a local mcp-stdio Node worker, which is a good future native path.

Mem does not claim Cindy-native automatic thread sync until one of these becomes stable and verified:

• a Cindy message-level export schema,
• a lifecycle hook that can call nmem after a settled turn,
• a documented API for reading Cindy sessions,
• or a validated Cindy Ghost package install path for a Nowledge connector.

Until then, use handoff summaries from MCP/skills for Cindy-native work, and use child-runtime connectors for exact captured transcripts.

Troubleshooting

MCP tools do not show up. Re-run:

nmem config mcp show --host cindy

Confirm Cindy has a custom MCP server named nowledge-mem with the generated URL and headers. Remote Mem requires the authentication headers from the generated block.

nmem config mcp show --host cindy is unknown. Update the CLI from the same source you installed it:

nmem --version
python3 -m pip install --user --upgrade nmem-cli

If you use the desktop-bundled CLI, reinstall it from Nowledge Mem Settings -> Preferences -> Developer Tools.

Cindy launched Codex or Claude Code but threads are missing. Install and verify the dedicated connector inside that child tool. The Cindy MCP server gives memory tools to Cindy; it does not read Codex or Claude Code transcript files.

Sources

• Cindy GitHub repository
• Nowledge Mem Cindy connector