README: lead with in-process execution as the architectural differentiator #6

Closed
opened 2026-05-23 20:53:53 +00:00 by coilysiren · 0 comments
Owner

Originally filed by @coilysiren on 2026-05-13T14:20:08Z - https://github.com/coilysiren/cli-mcp/issues/36

The README today lists in-process execution as one bullet under "Projection": "invokes root.Run(ctx, argv) in-process, captures stdout / stderr via cmd.Writer."

That bullet is the whole point. The closest prior art (njayp/ophis) spawns the CLI as a subprocess. That single choice is why:

  • cli-mcp composes with cli-guard for free. The guard's audit/validation runs in the same process as the Action, so MCP tool calls inherit the same audit row a human CLI invocation would.
  • cli-mcp doesn't need a DefaultEnv PATH-capture hack. Tools run in the calling process's environment.
  • cli-mcp doesn't need exit-code plumbing. urfave's error return is the truth.
  • cli-mcp's dual-mode is one process, not "binary spawning itself."

This is not reproducible by adding features to ophis. It's an architectural inversion, and it's the reason cli-mcp exists as a separate project rather than a urfave port of ophis.

Proposal: rewrite the lede of the README to put this front and center. Bullet list of "what one process buys you," explicit comparison to subprocess-based bridges (no need to name names if that feels rude, but the contrast is the marketing).

Pair with a section in docs/FEATURES.md that makes the same point at the design-doc level.

_Originally filed by @coilysiren on 2026-05-13T14:20:08Z - [https://github.com/coilysiren/cli-mcp/issues/36](https://github.com/coilysiren/cli-mcp/issues/36)_ The README today lists in-process execution as one bullet under "Projection": *"invokes `root.Run(ctx, argv)` in-process, captures stdout / stderr via `cmd.Writer`."* That bullet is the whole point. The closest prior art ([njayp/ophis](https://github.com/njayp/ophis)) spawns the CLI as a subprocess. That single choice is why: - cli-mcp composes with [cli-guard](https://github.com/coilysiren/cli-guard) for free. The guard's audit/validation runs in the same process as the Action, so MCP tool calls inherit the same audit row a human CLI invocation would. - cli-mcp doesn't need a `DefaultEnv` PATH-capture hack. Tools run in the calling process's environment. - cli-mcp doesn't need exit-code plumbing. urfave's `error` return is the truth. - cli-mcp's dual-mode is one process, not "binary spawning itself." This is not reproducible by adding features to ophis. It's an architectural inversion, and it's the reason cli-mcp exists as a separate project rather than a urfave port of ophis. Proposal: rewrite the lede of the README to put this front and center. Bullet list of "what one process buys you," explicit comparison to subprocess-based bridges (no need to name names if that feels rude, but the contrast is the marketing). Pair with a section in `docs/FEATURES.md` that makes the same point at the design-doc level.
coilysiren 2026-06-17 08:24:07 +00:00
Commenting is not possible because the repository is archived.
No milestone
No project
No assignees
1 participant
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
coilysiren/cli-mcp#6
No description provided.