code-review fails to run in "plan" mode

[ushkinaz]

Summary

Following recent #18 changes, the code-review extension is blocked from running when the Gemini CLI operates in "plan" mode.
Running code-review in "auto-accept edits" looks like rather strange idea. And code-review sometimes takes advantage of "edit mode" and reviews and fixes code in on run, which is extremely undesirable. So using "plan" mode is practically mandatory.

Steps to reproduce

1. Run the Gemini CLI with the code-review extension enabled in "plan" mode against a pull request.
2. Observe the command execution being blocked by policy with the error: ✕ code-review cannot be run. Blocked command: ... Reason: Blocked by policy.

Error message observed:

✕ code-review cannot be run. Blocked command: "[ "branch" = "pr-review" ] && {
      printf '
      <CONTEXT>
          **GitHub Repository**: %s
          **Pull Request Number**: %s
          **Additional User Instructions**: %s
          **Pull Review Details**: use `pull_request_read.get` tool to get the title, body, and metadata about the pull request.
      </CONTEXT>
      ' "$REPOSITORY" "$PULL_REQUEST_NUMBER" "$ADDITIONAL_CONTEXT"
  } || echo ''". Reason: Blocked by policy.

Additionally, every time that the extension is ran it asks for a permission to execute rather large command:

 Action Required                                                                                                                                                                                                                                             │
│                                                                                                                                                                                                                                                             │
│ ?  Expansion Command expansion needs shell access                                                                                                                                                                                                           │
│                                                                                                                                                                                                                                                             │
│ [ "branch" = "pr-review" ] && { printf ' <CONTEXT> **GitHub Repository**: %s **Pull Request Number**: %s **Additional User Instructions**: %s **Pull Review Details**: use `pull_request_read.get` tool to get the title, body, and metadata about the pull │
│ request. </CONTEXT> ' "$REPOSITORY" "$PULL_REQUEST_NUMBER" "$ADDITIONAL_CONTEXT" } || echo ''                                                                                                                                                               │
│ [ "branch" = "pr-review" ] && echo 'call the `pull_request_read.get_diff` tool' || echo 'run `git diff -U5 --merge-base origin/HEAD`'                                                                                                                       │
│ [ "branch" = "pr-review" ] && echo "6. **Submit the Review on GitHub** following the instruction in the <SUBMIT_REVIEW> section" || echo '6. **Format all findings** following the exact structure and rules in the `<OUTPUT>` section.'                    │
│ [ "branch" = "pr-review" ] && { printf ' <SUBMIT_REVIEW> **Review Comment Formatting** - **Line Accuracy:** Ensure suggestions perfectly align with the line numbers and indentation of the code they are intended to replace. - Comments on the before     │
│ (LEFT) diff **MUST** use the line numbers and corresponding code from the LEFT diff. - Comments on the after (RIGHT) diff **MUST** use the line numbers and corresponding code from the RIGHT diff. 1. **Create Pending Review:** Call                      │
│ `create_pending_pull_request_review`. Ignore errors like "can only have one pending review per pull request" and proceed to the next step. 2. **Add Comments and Suggestions:** For each formulated review comment, call `add_comment_to_pending_review`.   │
│ 2a. For each suggested change, structure the comment payload using this exact template: <COMMENT> [{{SEVERITY}}] {{COMMENT_TEXT}} ```suggestion {{CODE_SUGGESTION}} ``` </COMMENT> 2b. When there is no code suggestion, structure the comment payload      │
│ using this exact template: <COMMENT> [{{SEVERITY}}] {{COMMENT_TEXT}} </COMMENT> 3. **Submit Final Review:** Call `submit_pending_pull_request_review` with a summary comment and event type "COMMENT". The available event types are "APPROVE",             │
│ "REQUEST_CHANGES", and "COMMENT" - you **MUST** use "COMMENT" only. **DO NOT** use "APPROVE" or "REQUEST_CHANGES" event types. The summary comment **MUST** use this exact markdown format: ## 📋 Review Summary A brief, high-level assessment of the Pull │
│ Request's objective and quality (2-3 sentences). ## 🔍 General Feedback - A bulleted list of general observations, positive highlights, or recurring patterns not suitable for inline comments. - Keep this section concise and do not repeat details       │
│ already covered in inline comments. </SUMMARY> </SUBMIT_REVIEW> ' } || { printf ' <OUTPUT> The output **MUST** be clean, concise, and structured exactly as follows. **If no issues are found:** # Change summary: [Single sentence description of the      │
│ overall change]. No issues found. Code looks clean and ready to merge. **If issues are found:** # Change summary: [Single sentence description of the overall change]. [Optional general feedback for the entire change, e.g., unrelated change that should │
│ be in a different PR, or improved general approaches.] ## File: path/to/file/one ### L<LINE_NUMBER>: [<SEVERITY>] Single sentence summary of the issue. More details about the issue, including why it is an issue (e.g., "This could lead to a null        │
│ pointer exception"). Suggested change: ``` while (condition) { unchanged line; - remove this; + replace it with this; + and this; but keep this the same; } ``` ### L<LINE_NUMBER_2>: [MEDIUM] Summary of the next problem. More details about this         │
│ problem, including where else it occurs if applicable (e.g., "Also seen in lines L45, L67 of this file."). ## File: path/to/file/two ### L<LINE_NUMBER_3>: [HIGH] Summary of the issue in the next file. Details... </OUTPUT> ' }                           │
│                                                                                                                                                                                                                                                             │
│ Note: Command contains redirection which can be undesirable.                                                                                                                                                                                                │
│

[mctavish]

Thanks for raising this.

This is definitely not working as desired. I've cut #19 to revert the change.

[mctavish]

Rolled back; functionality should be restored. We'll take a different approach for getting PR review functionality.