Skip to content

feat(setup): add CommandCode CLI as supported agent #1119

Description

@eSagraAI

🔍 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:

  1. 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.

  2. 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:

engram setup commandcode

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions