[mfrna]

Add ZCode as a STABLE, detected client surface with a three-layer integration: MCP server registration in the nested mcp.servers object, durable instructions, and the codebase-memory skill.

Schema (agent_clients.h):
New CBM_AGENT_CLIENT_ZCODE enum value, positioned before COUNT.

Profile (agent_clients.c):

• stability: CBM_AGENT_STABLE (auto-detected, auto-installed)
• capabilities: MCP | INSTRUCTIONS | SKILL. No HOOK: config-file hooks require a global hooks.enabled opt-in that the installer must not flip on the user's behalf, and no documented context-output consumption contract exists. No AGENT: subagents are plugin/UI-managed with no documented user-scope config-file custom-agent directory; the surface is not approximated (same fail-closed treatment as Cursor).
• detection: ~/.zcode marker, the resolved config file, or the zcode command
• resolve_path: ~/.zcode/cli/config.json (documented user config; the same-scope .agents/mcp.json fallback is read-only and never written)
• json section: mcp.servers — the registry's first two-level section path. agent_json_section() becomes agent_json_section_path() returning (path, depth), agent_json_find_entry() walks nested sections, and the ownership-preserving editor already supported multi-level object paths.
• canonical entry: explicit "type": "stdio" because ZCode's strict schema silently drops servers carrying unknown keys

Install/uninstall (cli.c):

• install_zcode_durable_context: managed block in ~/.zcode/AGENTS.md plus skill at ~/.zcode/skills/codebase-memory/SKILL.md
• uninstall_zcode_durable_context removes both
• Wired into install_agent_client_registry and uninstall_agent_client_registry

Contracts (main.c, README.md, pkg/npm/README.md, docs/llms.txt, docs/index.html): 45 -> 46 surfaces, 39 -> 40 detected; ZCode added to the matrix, help list, and landing-page lists.

Test coverage:

• test_agent_clients.c: zcode in stable_ids (20 entries) and the capabilities array, the documented resolve path, ~/.zcode marker detection, a json_schemas case, nested foreign-entry preservation, and a dedicated lifecycle test (fresh nested-path creation, idempotent reinstall, sibling-server preservation on install and removal, canonical-only removal, foreign rejection byte-identically)
• test_cli.c: required_agents updated to 46; all 45/39 doc contracts updated

Verified: scripts/build.sh passes; scripts/test.sh --suites agent_clients (39 passed) and --suites cli (353 passed); scripts/security-audit.sh passes; end-to-end install/uninstall round-trip checked in an isolated HOME (sibling MCP servers preserved both ways). The full lint leg could not run locally (clang-tidy, cppcheck, clang-format not installed on this machine); the change compiles clean under -Wall -Wextra -Werror and adds no system()/popen()/fork()/network calls.

Written with the ZCode AI coding agent on behalf of Mohamed Nasr.

What does this PR do?

Checklist

• Every commit is signed off (git commit -s) — required, CI rejects
  unsigned commits (DCO, see CONTRIBUTING.md)
• Tests pass locally (make -f Makefile.cbm test)
• Lint passes (make -f Makefile.cbm lint-ci)
• New behavior is covered by a test (reproduce-first for bug fixes)

Closes #2565

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[DeusData]

Hi @mfrna, welcome, and thank you for your first contribution here, and for following up on #2565 with the product link, the MCP docs and your ZCode version. This is careful work: it follows the existing client registry closely, keeps the MCP entry ownership-safe (only our own unchanged entry is ever replaced or removed, and a foreign or edited one is left byte-identical), withholds hooks and subagents instead of approximating them, and ships a lifecycle test for the nested mcp.servers path. CI is green as well.

Adding a new client is a product decision on our side, so a maintainer will confirm that before we merge. In the meantime, two questions about ZCode itself would help us a lot:

1. The code comment in the resolve path says ZCode reads the shared .agents/mcp.json fallback only when ~/.zcode/cli/config.json has no servers. If that is right, a user who keeps their servers only in that shared file would stop seeing them in ZCode once install adds our entry to config.json. Could you confirm the exact fallback path and how ZCode behaves there? If it does work that way, we would like the installer to leave config.json alone in that case and print the manual step instead.
2. On your ZCode 3.16.3 install, could you confirm that after running install, ZCode lists codebase-memory-mcp with its tools, and that it picks up ~/.zcode/AGENTS.md and the skill under ~/.zcode/skills? A pointer to the docs section for those two paths would be plenty.

One heads-up so it does not surprise you: another open PR (#2483) also adds a client and claims the 46th slot, so whichever lands second needs its counts moved to 47 and 41. If that ends up being this one, we are happy to do the renumbering for you with maintainer edits. Thanks again for the thorough work!