Foreign IDE MCP Configs Should Stay Read-Only in APX

One of the easiest ways to make agent tooling messy is to let one runtime rewrite every other tool's MCP files.

That is exactly what APX should avoid.

APC gives a project one portable place for shared agent context. For MCP, that shared place is .apc/mcps.json. APX is the daily-use runtime and tooling layer on top of APC, so it has a different job: read what exists, merge what matters, and write only to the scopes it actually owns.

That is why APX's MCP model is healthier when foreign IDE configs stay read-only.

The ownership boundary matters

APX already has three writeable MCP scopes with clear semantics:

• shared for repo-owned entries in .apc/mcps.json
• runtime for project-local machine state in ~/.apx/projects/<id>/mcps.json
• global for machine-wide state in ~/.apx/mcps.json

Those three scopes map cleanly to the APC/APX split.

APC owns the portable, reviewable part. A team can commit safe MCP definitions such as filesystem access, a public GitHub server, or other non-secret project tools. APX owns the local runtime part, where personal tokens, machine-specific endpoints, and experiments belong.

Now compare that with files created by other tools: .mcp.json, .cursor/mcp.json, .vscode/mcp.json, .roo/mcp.json, or .gemini/settings.json.

Those files may be useful context for APX to discover, list, and inspect. But they are not APX's contract. If APX starts rewriting them, it becomes a config migration tool for every IDE on your machine. That creates hidden side effects, surprising diffs, and the constant risk of breaking another tool's assumptions.

What APX should do instead

The better model is simple:

1. Discover foreign MCP configs.
2. Surface them in apx mcp list and apx mcp check with their source labels.
3. Keep them read-only.
4. Write only to APX-owned scopes.

This makes APX additive instead of invasive.

Imagine a repo with a committed .apc/mcps.json entry for a shared filesystem server. One developer also has a local Cursor MCP config for a private Linear setup. Another has a Claude .mcp.json entry pointing at a machine-specific Postgres bridge.

APX can read all of that and show the merged picture. It can explain priority, conflicts, and active tools for the current project. But if someone wants to change the project contract, they should edit the APC-owned shared scope. If they want to add a secret or a local endpoint, they should use APX runtime scope.

That division keeps the mental model clean:

• APC says what the project can safely share.
• APX says what this machine can safely run today.
• Foreign tools keep owning their own private config formats.

Why this helps in practice

The immediate benefit is trust.

When a runtime reads other files but does not mutate them, users can inspect the system without worrying that a harmless audit command will rewrite their setup. apx mcp check becomes a debugging tool, not a migration event.

The second benefit is portability. APC stays small and explicit because only truly shared MCP definitions belong in .apc/mcps.json. You do not end up smuggling personal secrets or editor-specific tweaks into repo context just because one runtime tried to normalize everything.

The third benefit is less churn. No noisy commits. No accidental token leaks. No mystery changes after opening a different interface.

That is the deeper APC/APX pattern in miniature: APC should define the portable contract, while APX should make daily execution practical without claiming ownership over every adjacent file.

If a tool can read foreign configs and still refuse to rewrite them, it usually means the boundaries are in the right place.

Comments

[Alex Shev]

Read-only is the sane default for foreign IDE configs. A project context tool can observe and explain external settings, but writing into another tool’s config crosses an ownership boundary that should require a very explicit handoff.