🔍 Problem Description
CommandCode is an agentic coding CLI (cmd, cmdc on Windows) with native MCP support and a tiered AGENTS.md memory system, but it is not in Engram's agent registry. Users who want Engram with CommandCode must manually register the MCP server and hand-write the Memory Protocol into their user memory file, which is error-prone (absolute binary path, preserving existing servers/keys, idempotent re-runs).
Currently the only way is manual — no engram setup commandcode command, no Memory Protocol injection into CommandCode's user memory surface, no entry in setup help text, and no documentation. This breaks parity with the agents Engram already supports out of the box.
💡 Proposed Solution
Add commandcode as a declarative agent in agentAdapters() (same pattern as Cursor, Windsurf, Qwen, Kiro, Kilo Code). Running engram setup commandcode would:
-
Register the MCP server in the user-scope ~/.commandcode/mcp.json (user scope = private, available across all projects — the correct global surface, vs local per-project ~/.commandcode/projects/<slug>/mcp.json or version-controlled project .mcp.json). Open point, to verify during implementation: the exact stdio entry JSON CommandCode writes (see Additional Context). The implementation must confirm it via cmd mcp add --scope user + cmd mcp get and add a new mcpFormat value if the shape differs, following the serversObject / opencodeObject precedent.
-
Write the Memory Protocol as a marker-delimited block into the user-tier ~/.commandcode/AGENTS.md (markerBlock style, preserving user preferences and staying idempotent on re-run). CommandCode loads user + project + subdirectory AGENTS.md tiers cumulatively on every request, so this is the correct global instruction surface.
Example usage:
Expected output:
MCP config written + Memory Protocol block written, with next-steps guidance to verify (cmd mcp list / cmd mcp get engram)
Slug rationale: commandcode (product name), not cmd — the CLI binary is cmd on Unix but cmdc on Windows to avoid clashing with cmd.exe.
📦 Affected Area
CLI (commands, flags)
🔄 Alternatives Considered
Bespoke plugin with hooks (like Claude Code / Codex) — Rejected. No documented shell-hook surface equivalent for CommandCode setup to drive; MCP + AGENTS.md are the documented, stable surfaces and keep the adapter thin per skills/plugin-thin.
Project-scope surfaces (.mcp.json / <project>/AGENTS.md) — Rejected as the primary surface. They are per-project and meant to be committed to git; engram setup targets global user defaults, mirroring the qwen/windsurf/kiro approach.
Shelling out to cmd mcp add --scope user ... — Rejected as the install mechanism. Direct JSON injection via the registry driver preserves existing servers and top-level keys, stays testable offline, and is idempotent — consistent with every other declarative adapter. (/import from another agent is likewise manual, not one-command.)
📎 Additional Context
CommandCode official docs:
Verified so far: user-scope file location (~/.commandcode/mcp.json) and the {"mcpServers": {...}} envelope shown for the HTTP example ({"mcpServers":{"stripe":{"transport":"http","url":"https://mcp.stripe.com"}}}).
Explicitly not yet verified: the exact stdio entry JSON for a local process server. Docs only show the CLI form (cmd mcp add my-tool -- npx @my-org/mcp-server) without printing the resulting file. Before implementing, run cmd mcp add my-tool --scope user -- npx @my-org/mcp-server on a scratch machine and inspect with cmd mcp get my-tool / reading ~/.commandcode/mcp.json to confirm field names (transport? command? args? enabled?). Do not assume the existing mcpServersObject ({command, args}) shape fits.
Implementation should follow the existing declarative adapter pattern, including registry/CLI tests and documentation updates.
🔍 Problem Description
CommandCode is an agentic coding CLI (
cmd,cmdcon Windows) with native MCP support and a tieredAGENTS.mdmemory system, but it is not in Engram's agent registry. Users who want Engram with CommandCode must manually register the MCP server and hand-write the Memory Protocol into their user memory file, which is error-prone (absolute binary path, preserving existing servers/keys, idempotent re-runs).Currently the only way is manual — no
engram setup commandcodecommand, no Memory Protocol injection into CommandCode's user memory surface, no entry in setup help text, and no documentation. This breaks parity with the agents Engram already supports out of the box.💡 Proposed Solution
Add
commandcodeas a declarative agent inagentAdapters()(same pattern as Cursor, Windsurf, Qwen, Kiro, Kilo Code). Runningengram setup commandcodewould:Register the MCP server in the user-scope
~/.commandcode/mcp.json(user scope = private, available across all projects — the correct global surface, vslocalper-project~/.commandcode/projects/<slug>/mcp.jsonor version-controlled project.mcp.json). Open point, to verify during implementation: the exact stdio entry JSON CommandCode writes (see Additional Context). The implementation must confirm it viacmd mcp add --scope user+cmd mcp getand add a newmcpFormatvalue if the shape differs, following theserversObject/opencodeObjectprecedent.Write the Memory Protocol as a marker-delimited block into the user-tier
~/.commandcode/AGENTS.md(markerBlockstyle, preserving user preferences and staying idempotent on re-run). CommandCode loads user + project + subdirectoryAGENTS.mdtiers cumulatively on every request, so this is the correct global instruction surface.Example usage:
Expected output:
Slug rationale:
commandcode(product name), notcmd— the CLI binary iscmdon Unix butcmdcon Windows to avoid clashing withcmd.exe.📦 Affected Area
CLI (commands, flags)
🔄 Alternatives Considered
Bespoke plugin with hooks (like Claude Code / Codex) — Rejected. No documented shell-hook surface equivalent for CommandCode setup to drive; MCP +
AGENTS.mdare the documented, stable surfaces and keep the adapter thin perskills/plugin-thin.Project-scope surfaces (
.mcp.json/<project>/AGENTS.md) — Rejected as the primary surface. They are per-project and meant to be committed to git;engram setuptargets global user defaults, mirroring the qwen/windsurf/kiro approach.Shelling out to
cmd mcp add --scope user ...— Rejected as the install mechanism. Direct JSON injection via the registry driver preserves existing servers and top-level keys, stays testable offline, and is idempotent — consistent with every other declarative adapter. (/importfrom another agent is likewise manual, not one-command.)📎 Additional Context
CommandCode official docs:
~/.commandcode/mcp.jsonuser scope): https://commandcode.ai/docs/mcp~/.commandcode/AGENTS.md, Project<project>/AGENTS.md, Subdirectory<subdir>/AGENTS.md, all loaded cumulatively): https://commandcode.ai/docs/memory~/.commandcode/tree): https://commandcode.ai/docs/settingscmdvscmdcon Windows,cmd mcp <subcommand>): https://commandcode.ai/docs/reference/cliVerified so far: user-scope file location (
~/.commandcode/mcp.json) and the{"mcpServers": {...}}envelope shown for the HTTP example ({"mcpServers":{"stripe":{"transport":"http","url":"https://mcp.stripe.com"}}}).Explicitly not yet verified: the exact stdio entry JSON for a local process server. Docs only show the CLI form (
cmd mcp add my-tool -- npx @my-org/mcp-server) without printing the resulting file. Before implementing, runcmd mcp add my-tool --scope user -- npx @my-org/mcp-serveron a scratch machine and inspect withcmd mcp get my-tool/ reading~/.commandcode/mcp.jsonto confirm field names (transport?command?args?enabled?). Do not assume the existingmcpServersObject({command, args}) shape fits.Implementation should follow the existing declarative adapter pattern, including registry/CLI tests and documentation updates.