Skip to content

Overview

CloudAEye's code review runs against your local working tree, not against a pushed branch. Your coding agent calls it after finishing a task and before you commit, so problems are caught in the editor loop rather than in CI or in review.

The unit of review is the complete change you are about to commit — new files included — compared against where your branch forked from your integrated branch (see Custom Context).

The three review passes

All three are the same tool with a different scope. Which prompts run is what changes, and so what gets found.

Pass Report types Use it
Inspect BUG_REPORT After every coding task.
Security SECURITY_REPORT, LLM_SECURITY_REPORT, AIAGENT_SECURITY_REPORT, MCP_REPORT, SECRET_REPORT When the change touches auth, untrusted input, secrets, crypto, deserialization, prompts, tool definitions or agent orchestration.
Review All of the above Before opening a significant PR.

Inspect runs no security prompts. It covers logic errors, edge cases, input validation, error handling, concurrency, code signatures, naming, clarity and syntax — and nothing from the security surface. If your change touches anything security-relevant, run the Security pass too.

The other three commands

  • Describe — a plain-markdown summary of what the change does, for a commit message or PR body. Not a review; no verdict.
  • Check Task — judges the diff against a task, a Jira ticket, a GitHub issue, or a freeform spec, and returns a per-requirement checklist.
  • Ask — answers a free-form question about the pending change against the repository's code graph. Also not a review: it answers what you asked and returns no findings.

How a review runs

Every command runs against a session — one per (tenant, repository, developer), holding the diff and any cached code context. It survives branch switches and commits, and your client drives the whole sequence for you.

sequenceDiagram
    participant Agent as Coding agent
    participant Server as CloudAEye MCP server
    Agent->>Server: POST /session  {repo, branch, head, tenant_key, user_name}
    Server-->>Agent: { session_id, target_branch, repo_full, resumed }
    Note over Agent: git merge-base origin/target_branch HEAD<br/>git diff base_sha
    Agent->>Server: POST /upload/{session_id}  (diff file + base_sha)
    Server-->>Agent: { session_id, diff_unchanged }
    Agent->>Server: MCP tool call  inspect_diff(session_id, intent, profile)
    Server-->>Agent: { verdict, findings[], profile, … }
    Agent->>Agent: Surface findings to you

Three things the diagram doesn't show:

  • The session call comes first because it names the baseline. target_branch is in its response; until then there is nothing to diff against.
  • The diff runs from the fork point, not the branch tip. No integration means no branch, so it falls back to local HEAD — reported as base_source=head.
  • One upload serves the whole turn. The diff stays on the server keyed by session_id and is never passed inline, so Inspect → Describe → Check Task reuse it. Re-uploading identical bytes is a no-op; a changed diff invalidates the cached code graph.

The client holds no state of its own — deleting .cloudaeye/ costs nothing.

Iterating

Findings are structured, so your agent can act on them. Ask it to fix specific findings and run the same command again — the session resumes automatically, and the agent notes which findings it addressed and which it deliberately left, so the next pass doesn't repeat itself.

What leaves your machine

Worth knowing before pointing this at a private repository:

  • The diff is uploaded. Each run captures git diff against the baseline and POSTs it to the review server, which stages the post-edit file contents and runs the review there. Untracked files are included — they are marked with git add --intent-to-add so they appear in the diff.
  • git add --intent-to-add is non-destructive. It records paths in the index without staging content. Undo with git reset.
  • A .cloudaeye/ scratch directory is created in your repository and gitignores itself on every run. It holds session files only: the request body, the server's response, and the diff.
  • No credential is written into your working tree. There is no per-repo config file.

Supported Coding Agents

Claude Code ships as a plugin today; Cursor and OpenAI Codex are planned. See Supported Coding Agents for the current list, or go straight to Claude Code Plugin → Setup.

Everything on this page, plus Custom Context and the Tool Reference, is the same in every client. What differs is installation and how the commands are invoked, which is what each coding agent page covers.

Any MCP client can call the tools directly against the server's HTTP and MCP surfaces — see the Tool Reference.