Skip to content

mu-review: add host-aware reciprocal cross-model review (Claude ↔ Codex) #51

Description

@huiyu
  • I searched existing issues and this has not been proposed before

What problem does this solve?

mu-review currently describes optional review by "another model", but it no longer has an executable cross-review path. The earlier implementation was specifically Claude Code → Codex CLI. Restoring that implementation unchanged would be wrong now that DevMuse supports multiple hosts:

  • under Claude Code, Codex is an independent reviewer;
  • under Codex, launching Codex again is not cross-review and can recurse or waste usage;
  • generated host adapters need different reviewer transports while preserving one canonical workflow.

The purpose of this capability is independent model-family review, not "always run Codex".

Local subscription authentication is also being confused with direct API authentication. A locally installed Codex CLI can run non-interactively with an existing ChatGPT login; a local Claude Code CLI should likewise be evaluated using its existing authenticated session. Cross-review should not require API keys merely because one CLI launches another CLI.

Proposed solution

Make cross-review host-aware and reciprocal.

Expected default routing:

Current host External reviewer
Claude Code Codex CLI
Codex Claude Code CLI
Other supported hosts A configured reviewer from a different model family, otherwise capability unavailable

Keep the high-level policy in canonical plugin/skills/mu-review/, but generate or inject host-specific invocation instructions into each adapter. Do not rely only on fragile runtime guessing when the adapter build already knows its target host.

Invocation requirements

  • Never invoke the current host as its own external reviewer.
  • Limit cross-review depth to one; a reviewer process must not start another cross-review.
  • Trigger only when:
    • the user explicitly requests cross-review; or
    • a high-risk signal is shown and the user accepts the additional usage.
  • Prefer an existing local subscription/session login when the target CLI supports it.
  • Keep API-key mode optional for CI or explicitly configured automation; do not make it the local default.
  • Do not invoke shell aliases such as cx; aliases are unreliable in non-interactive shells.
  • Support explicit, testable configuration such as reviewer binary and auth/config home overrides.
  • Construct commands with quoted argument arrays; do not use eval or interpolate untrusted text into shell programs.
  • Pin the reviewer working directory to the current project/repository.
  • Use read-only permissions and non-persistent/ephemeral sessions where supported.
  • Disable cross-project memories and unrelated user execution rules where the target CLI supports this.
  • Use a bounded timeout, a private temporary directory, cleanup traps, and validated output artifacts.
  • Never print, copy, or commit OAuth caches, API keys, or access tokens.
  • Missing CLI, expired authentication, timeout, malformed output, or provider outage must not block the primary review.

For current Codex CLI versions, evaluate codex exec review rather than restoring the old codex review/raw codex exec split. It supports native review selection together with --ephemeral, --ignore-user-config, --ignore-rules, --output-schema, and --output-last-message.

Evaluate both CLI subprocesses and local stdio MCP as transports. Prefer the smallest deterministic mechanism for a one-shot review; MCP is justified only if multi-turn reviewer dialogue materially improves the workflow.

Result handling

Normalize external findings into the existing DevMuse severity and coverage format.

  • Preserve reviewer provenance on every result.
  • Show contradictory conclusions side by side; do not silently choose one.
  • Validate structured output rather than trusting exit code 0.
  • Do not feed a huge serialized diff over stdin. Provide validated refs and allow the reviewer to inspect the repository, with an explicit strategy for very large ranges.
  • Reuse the lessons from mu-review: Codex review fails on large diffs (full-project review) #19 around large-diff failure and graceful fallback.

Source and adapter boundaries

  • plugin/skills/ remains the source of truth.
  • Do not hand-edit adapters/codex/skills/.
  • The generated Codex adapter must contain Claude-review behavior, not Codex-review behavior.
  • Claude-specific invocation must not leak into a Codex-hosted mu-review.
  • Regenerate adapters through npm run build:adapters and keep generated-drift checks passing.

What alternatives did you consider?

  1. Restore the former Claude → Codex block unchanged. Rejected because it becomes Codex → Codex under the generated Codex adapter and does not implement reciprocal cross-review.
  2. Keep cross-review Claude-only. Simpler, but conflicts with DevMuse's multi-host architecture and the semantic meaning of "another model".
  3. Call provider APIs directly. Useful for CI, but unnecessarily requires separate API billing and secret management for local users who already have authenticated subscription CLIs.
  4. Always use MCP. Useful for multi-turn orchestration, but more lifecycle and permission surface than a deterministic one-shot review may need.

Is this appropriate for core DevMuse?

Yes. mu-review is a core, generated multi-host workflow. Selecting a genuinely independent reviewer is host orchestration behavior and cannot be implemented correctly as a user-specific Claude-only command. Provider-specific command details should remain thin adapter/runner concerns.

Acceptance criteria

  • An explicit cross-review request under Claude Code invokes Codex, never Claude Code.
  • An explicit cross-review request under Codex invokes Claude Code, never Codex.
  • Other hosts either select a configured different-family reviewer or treat the capability as unavailable.
  • Cross-review depth is bounded and recursive reviewer spawning is covered by tests.
  • Local subscription/session authentication works without requiring an API key when supported by the target CLI.
  • Reviewer binary and configuration/auth home can be overridden without relying on shell aliases.
  • Commands are read-only, project-scoped, non-persistent where supported, safely quoted, and do not expose credentials.
  • CLI absence, auth failure, timeout, invalid output, and large-diff failure fall back without blocking the primary review.
  • Structured output is validated and findings retain reviewer provenance.
  • Contradictory findings are presented side by side.
  • Tests use fake reviewer binaries to assert exact arguments, environment, timeout/fallback, output validation, and recursion guards without network access.
  • npm run build:adapters, generated-drift validation, and relevant skill/platform tests pass.
  • Stale Codex cross-review scope/spec documentation is updated to reflect the implemented host-aware behavior.

Context

Observed on 2026-08-05 with:

  • Codex CLI 0.146.0
  • Claude Code 2.1.220
  • current mu-review only retaining generic optional cross-review wording
  • successful non-interactive codex exec using saved ChatGPT OAuth credentials and no API key

Related work:

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions