Configuration Review Guide for MCP Risk in Cross-Code Organizer

Most AI coding failures get blamed on the model too quickly. In real projects, the more boring cause is often configuration: a stale AGENTS file, a duplicated MCP server, a shadowed skill, a project-level setting, or a long session that loads noise before the task starts.

Cross-Code Organizer is worth saving because it turns that hidden tool state into something a developer can inspect. The current project name is CCO, not Claude Code Organizer, and the stronger article is not a hype post about productivity. It is a local audit playbook for Claude Code and Codex config.

Read CCO as a tool audit console

The README says CCO scans Claude Code memories, skills, agents, hooks, commands, plans, rules, sessions, MCP servers, and context budget. It also scans Codex CLI AGENTS files, profiles, sessions, history, shell snapshots, TOML config, MCP servers, and skills. That matters because Claude Code and Codex do not load configuration through the same rules. A generic settings viewer would flatten those differences. CCO's value is that it treats each tool as a separate adapter, then lets the reviewer switch tools from one dashboard.

Start with inventory, not cleanup

The first command should be npx @mcpware/cross-code-organizer, or from the bundled Skill, npx @mcpware/cross-code-organizer@latest $ARGUMENTS. The Skill says the dashboard opens at http://localhost:3847 or the next available port. Do not start by moving files. Start by scanning. For Claude Code, check which memories, skills, MCP servers, hooks, slash commands, and sessions appear at user, project, and ancestor scopes. For Codex, check AGENTS instructions, profiles, sessions, history, shell snapshots, config, skills, and MCP servers. The first adoption decision is whether the dashboard's inventory matches what the team thought was active.

Run the first audit in seven steps

Use a fixed sequence the first time so cleanup does not outrun evidence. Step 1: run npx @mcpware/cross-code-organizer. Step 2: pick Claude Code in the tool selector and choose the project you actually work in. Step 3: open Show Effective for skills, agents, and MCP servers. Step 4: write down every shadowed item, duplicate name, and ancestor-loaded file before editing anything. Step 5: run the MCP security scan and open each finding from the result row to the server entry. Step 6: switch to Codex and repeat the inventory for AGENTS files, profiles, config, skills, sessions, and MCP servers. Step 7: make one low-risk move or disable one MCP server, then rescan the same project and confirm the effective config changed only where expected.

Show Effective is the real review layer

The README calls out Claude Code-specific precedence: MCP servers resolve local over project over user, project agents override same-name user agents, and skills can come from personal, project, and plugin sources. That is exactly where hidden behavior comes from. Use Show Effective before deleting anything. If two items have the same name, the interesting question is not which file exists; it is which one Claude Code will load for the project in front of you. For Codex, the same discipline applies to AGENTS scope and profile config. Treat the dashboard as an explanation tool first, a mutation tool second.

The MCP scanner is triage, not proof

CCO's MCP security scanner is a strong source-backed reason to rescue the topic. The README says it connects to MCP servers, retrieves actual tool definitions, scans them with 60 detection patterns, applies 9 deobfuscation techniques, and tracks SHA256 baselines so changed tools can be marked. That is useful because tool descriptions go into the model prompt. Still, a scanner finding is not the final security decision. Use it to triage tool poisoning, prompt-injection text, unreadable obfuscation, and changed tool definitions, then inspect the server config and remove or disable only the specific server that failed review.

Context Budget catches preload waste

The Context Budget feature is not just a token counter for curiosity. The README says it breaks down always-loaded versus deferred content, expands imports, uses per-item token counts, and lets reviewers compare a 200K or 1M context window. In practice, this is a good way to find old instructions that keep entering Claude Code before the task begins. The article angle is not 'save tokens by magic.' The useful workflow is to sort by what always loads, remove duplicates, and keep project instructions small enough that the agent still has room for the actual code review.

Moving config is where risk starts

CCO can move memories, skills, and MCP server entries, delete duplicates, and undo moves or deletes. That is useful, but it is also the risky part. A move can change precedence; deleting a duplicate can remove the only copy that was actually effective; disabling an MCP server writes to Claude Code state such as ~/.claude.json. Before changing anything, export or back up the current tool state, change one item, rescan, and check the project where the item matters. Bulk operations belong after the team has tested the same action on one low-risk item.

Make one scoped change, then verify the file

A safe first change is a project-level MCP disable, because the README ties it to the same behavior as /mcp disable <name> and says the state is persisted in ~/.claude.json. Pick one MCP server with a clear security finding, open its detail row, disable it for the current project, then rescan the same project. After that, inspect the underlying file and confirm only the intended project path changed under the disabled server list. For a skill or memory move, record the source path, destination path, and item name before clicking Move. Then reopen Show Effective and check that the previous item is marked shadowed, moved, or gone for exactly the project you meant to change.

Use AI_INDEX to avoid README drift

The repository's AI_INDEX.md is unusually useful because it tells agents not to treat the index as source of truth and to verify runtime files first. It maps the CLI entry point at bin/cli.mjs, the HTTP server at src/server.mjs, the scanner at src/scanner.mjs, mover logic at src/mover.mjs, effective-mode rules at src/effective.mjs, security scanning at src/security-scanner.mjs, and MCP mode at src/mcp-server.mjs. It also names known drift: drag-and-drop is disabled in runtime even though docs and tests still mention it, version strings can be stale, and history.mjs is dormant. That is the kind of caveat a real magazine article needs. Verify source paths before claiming a feature exists.

Why a dashboard beats a scanner only after triage

A standalone MCP scanner is enough if the only question is whether a tool description contains suspicious text. CCO becomes more useful after that first flag, because the same screen can show which scope loaded the server, whether another copy shadows it, and where to move or disable it. Manual dotfile review is still better for one known file; a text editor will always beat a dashboard when the reviewer already knows the exact path. The dashboard wins when the risk is scope confusion across ~/.claude, ~/.codex, project files, and ancestor directories. That is the tradeoff: CCO adds UI and mutation risk, but it also connects finding, scope, and cleanup in one pass.

Where to use it and where to skip it

Use CCO when a repo has multiple Claude Code projects, Codex profiles, imported AGENTS files, many MCP servers, or confusing session bloat. It is also useful before a team standardizes tool config, because the dashboard can show what is already loaded instead of what people believe is loaded. Skip it for a single clean project with one AI coding tool and no MCP server sprawl. Also skip broad cleanup during an incident. During incident response, use the dashboard to identify the active config and security finding, then make the smallest manual change that restores the workflow.

Save CCO as a configuration audit playbook. It is strongest before cleanup, when the team needs to see what Claude Code and Codex actually load.

Practical takeaway

Run npx @mcpware/cross-code-organizer, scan Claude Code and Codex separately, open Show Effective for the project you care about, review MCP security findings, sort Context Budget by always-loaded items, and change only one item. After each move, delete, or MCP disable, rescan and confirm the effective config changed in the intended project. If the first rescan shows unexpected scope changes, undo that item and stop the batch.