What is mcpware/cross-code-organizer?

CCO is an MIT-licensed local dashboard that normalizes the hidden config folders of several AI coding harnesses into one view. It is useful if you have lost track of which MCP servers, memories or skills are actually loading, and overkill if you only use one tool with a handful of files.

Can I use mcpware/cross-code-organizer commercially?

Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.

Is mcpware/cross-code-organizer still maintained?

Yes. The repository last received commits 3 days ago.

What programming language is mcpware/cross-code-organizer written in?

Mainly JavaScript, according to GitHub's language statistics.

Cross-Code Organizer review: Claude Code and Codex configs

At a glance

What is it?: CCO is an MIT-licensed local dashboard that normalizes the hidden config folders of several AI coding harnesses into one view. It is useful if you have lost track of which MCP servers, memories or skills are actually loading, and overkill if you only use one tool with a handful of files.
Who is it for?: Adopt CCO if you run two or more harnesses, or one harness with enough MCP servers, skills and memories that you no longer know what loads at startup. Skip it if you have a single tool with a handful of config files, since the dashboard adds a Node.js service you would then have to keep updated.
Can I use it commercially?: Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?: Yes. The repository last received commits 3 days ago.
What is it written in?: Mainly JavaScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

Hysen Labs Editorial · September 16, 2026 · mcpware/cross-code-organizer

The problem CCO targets: invisible config across several harnesses

Every AI coding harness keeps its own state in hidden directories. The README lists what Claude Code loads (memories, skills, agents, hooks, slash commands, MCP servers, sessions, context budget) and what Codex CLI loads (AGENTS instructions, custom agents, profiles, sessions, history, shell snapshots, local memory artifacts, TOML config, MCP servers, plugins, hooks, skills). OpenCode layers JSON and JSONC config with its own agents, commands, MCP servers, plugins, tools and themes. DeepSeek Harness has profiles, layered entry files, global settings and skill roots.

The README's own framing is that each tool has its own rules: MCP servers follow precedence, agents shadow each other by name, settings merge across files, AGENTS instructions apply by directory. That is the actual problem. Not that the files are hard to open, but that the merge semantics differ per harness, and the result of the merge is what the model sees. CCO's audience is someone running two or more of these tools who wants one place to see the merged outcome, plus a security pass over MCP tool descriptions, which go straight into the model prompt.

How the adapters normalize Claude Code, Codex CLI, OpenCode and DSH

CCO does not flatten everything into one schema and pretend the harnesses are equivalent. The README says it normalizes each harness through its own adapter, without pretending that every harness has the same precedence or mutation rules. That is the design decision worth noting: the dashboard switches harnesses from a sidebar, and each adapter knows the file layout and merge order of its target.

Reads are local. According to the privacy section, CCO reads selected harness config files on your machine, naming ~/.claude/, ~/.codex/ and project-level config. Telemetry is explicit opt-in. When enabled, detailed event totals stay local under ~/.cco/, and the submitted monthly signal contains only a rotating anonymous ID, UTC month, app version and harness ID. The README states it never sends paths, names, prompts, file contents, sessions or credentials. The Dockerfile copies bin/ and src/ into a node:22-slim image and runs the CLI with --mcp, so the same code can run as an MCP server rather than a UI.

The repository also ships a research preview the README calls an Activation Scanner: a local sensor model whose hidden activations are read and used to train a probe before an untrusted capability runs. The README describes this as a different signal from scanners that rely on text, rules or classifiers. Treat that as research, not as a shipped guarantee; the README points to research/README.md and research/LIVING_PLAN.md rather than documenting a stable interface.

Installing CCO and running a first scan

The package is published on npm as @mcpware/cross-code-organizer and the bin entry is cross-code-organizer, so a global install gives you that command. The package.json requires Node.js 20 or newer per the README badge.

bash

npm install -g @mcpware/cross-code-organizer
cross-code-organizer

The first command installs the CLI. The second starts the dashboard; the README describes switching harnesses from the sidebar, so expect a local UI rather than terminal output. If you prefer to skip the global install, the repository's start script runs the same entry point from a checkout.

bash

npm start

CCO can also run as an MCP server, which is what the Dockerfile does. The package.json defines an mcp script pointing at src/mcp-server.mjs.

bash

npm run mcp

What you should see after the dashboard opens is an inventory per harness: memories, skills, agents, hooks, commands, MCP servers and sessions for Claude Code, and the equivalent sets for the other adapters. From there the README's loop is scan, find, fix: disable MCP servers per-project, find and delete duplicate memories, and move misplaced configs. The install steps above are the ones the repository documents; the README does not walk through a first-run wizard, so the initial view is the adapter output itself.

Context budget and the MCP tool-poisoning scan

Two features carry most of the project's weight. The first is context budget tracking: the README argues that duplicates, stale instructions, MCP tool schemas and inherited project files can load before you type a single word, and that a fuller context leaves less room for the task. CCO surfaces that as a per-harness view rather than a single number, which matters because the loading rules differ.

The second is the MCP security scanner, tagged in the README as a red badge and described with a concrete attack: a compromised server embeds hidden instructions in a tool description, for example telling the agent to read ~/.ssh/id_rsa and include it as a parameter. Since tool descriptions enter the model prompt, the user never sees the instruction. CCO scans for that. The honest caveat is that description scanning is a text problem, and the README itself frames the Activation Scanner preview as an attempt to add a non-text signal. If you need detection you can rely on in a hostile environment, a scanner that reads descriptions is a first filter, not a boundary. The README does not document a sandbox or an enforcement mode that blocks a server from loading.

Where CCO is the wrong tool

If you use a single harness and keep your config small, CCO is a second system to maintain. It reads the same files you could open directly, and the value comes from aggregation and comparison. With one tool, there is nothing to compare.

There is also a scoping limit. The README names Claude Code, Codex CLI, OpenCode and DeepSeek Harness, and describes the rest as future adapters. The package keywords mention Cursor, Windsurf and Aider configs, but the README's feature description does not list adapters for them, so do not assume coverage from a keyword list. If your harness is not among the four named, check the repository before installing.

A third limit is mutation. CCO edits Markdown customizations in place, disables MCP servers per-project and deletes duplicate memories. The v0.20.0 notes describe reversible exact-duplicate repair, which implies earlier versions were not reversible on that path. The README does not document a general rollback for in-place Markdown edits, so treat editing as a write operation on live config and keep your own copy first.

Alternatives and how the approach differs

The closest alternative is the harness vendors' own tooling. Claude Code and Codex CLI each expose their configuration through their own files and commands; that is authoritative by definition, because the vendor defines the precedence rules. The difference is scope: vendor tooling shows you one harness, and CCO's whole premise is the cross-harness view. If you never switch between tools, the vendor path is strictly more accurate because there is no adapter layer to drift.

A second alternative is a plain dotfiles repository with symlinks. That gives you version control and reproducibility, which CCO does not advertise. It gives you nothing for MCP tool-description inspection, context budget accounting, or knowing which agent shadows which by name. The trade-off is real in both directions: dotfiles are durable and auditable, CCO is diagnostic and interactive.

A third option is a general MCP gateway that proxies servers. That changes the runtime path, so descriptions are inspected as they pass through. CCO instead reads config on disk and reports. A gateway can enforce; a local scanner observes. Which one you want depends on whether your threat model is a careless install or an actively hostile server.

Maintenance cost, release cadence and the MIT licence

The last push to the repository was on 2026-09-13, and the repository is not archived. The most recent tagged releases listed are v0.19.3, v0.19.2 and v0.19.1, all dated 2026-04-28, while package.json carries version 0.20.0 and the README describes v0.20.0 features including Harness Doctor, an Effective Context Map, a hygiene score and OpenCode and DeepSeek Harness inventory. So the published package version is ahead of the newest tagged release in the release list. That gap is worth checking before you pin a version in a team setup.

Upgrade cost is the usual one for a local dashboard: npm install -g to move forward, and an adapter that reads harness config must track changes in those harnesses. When Claude Code or Codex CLI changes a config format, the adapter is the thing that breaks, and a stale adapter can show you a config state that no longer matches reality. The v0.19.3 notes mention handling non-ASCII paths, lossy encoded paths and symlinked directories, which is the kind of fix that shows where adapter fragility lives.

The licence is MIT, which permits commercial and private use and modification. That is a statement about the licence text, not legal advice; if you redistribute CCO inside a product, read LICENSE and PRIVACY.md yourself. The telemetry design is relevant here: opt-in, with detailed totals kept locally under ~/.cco/ and only a rotating anonymous ID, UTC month, app version and harness ID submitted. If your policy forbids any outbound signal, leave telemetry off.

Editorial conclusion

Adopt CCO if you run two or more harnesses, or one harness with enough MCP servers, skills and memories that you no longer know what loads at startup. Skip it if you have a single tool with a handful of config files, since the dashboard adds a Node.js service you would then have to keep updated. Before trusting it, verify three things: that the adapter for your harness reads the precedence rules you expect, that the MCP security scanner's findings are actionable rather than noisy, and that the duplicate-repair path is reversible in the version you install, as the v0.20.0 notes describe it.

Frequently asked questions

Which AI coding harnesses does Cross-Code Organizer support?

The README names Claude Code, Codex CLI, OpenCode and DeepSeek Harness, and describes additional harnesses as future adapters. Each is handled by its own adapter rather than a shared schema, because the README says the tools do not share precedence or mutation rules.

Does Cross-Code Organizer send my config or prompts anywhere?

The README states that CCO reads selected harness config files locally, naming ~/.claude/, ~/.codex/ and project-level config. Telemetry requires explicit opt-in, and the submitted monthly signal contains only a rotating anonymous ID, UTC month, app version and harness ID, with detailed event totals staying under ~/.cco/.

Can Cross-Code Organizer detect a poisoned MCP server?

It includes an MCP security scanner aimed at hidden instructions embedded in tool descriptions, such as a description telling the agent to read ~/.ssh/id_rsa. The README also describes an Activation Scanner as a research preview that reads a local sensor model's hidden activations, so treat that part as experimental rather than a shipped guarantee.

Official sources

Community notes